Give marks a way of declaring that they are mutually exclusive with other marks

Do you want to request a feature or report a bug?

Feature

What’s the current behavior?

Currently there isn’t a great way to deal with marks that are mutually exclusive with other marks, and it leads to people continuously reinventing the wheel to deal with this sort of issue.

A perfect example of this is with text color. Typically people will try to implement text color as a mark, either with a mark specifically for the color or a mark that is a generic color mark that has the color in the data property (can elaborate but don’t feel like this is completely pertinent to the suggestion).

Ultimately though users still have to do something like

1. Check whether the range contains a color mark already.
2. Remove the color mark on the range where the new color mark will be applied.
3. Apply the color mark.

There are some variations to this, but it’d be nice if Slate did this automatically.

What’s the expected behavior?

We should consider adding a slate schema property for marks that indicates that 1. they belong to a certain ‘family’ of marks, and that only one mark of that ‘family’ can exist on a given leaf of text at one time.

Names pending, that might look like this:

const schema = {
   marks: {
      types: [
          { type: 'bold' },
          { type: 'color-blue', family: 'color' },         
          { type: 'color-red', family: 'color' },
          { type: 'color-green', family: 'color' },
      ],
   },
}

or also equivalent but more concise

const schema = {
   marks: {
      types: [
          { type: 'bold' },
          { type: 'color', family: 'color' }, // would be used if the data property has the color
      ],
   },
}

In the above schema examples, we could declare that the ‘color’ mark types belong to the ‘color’ family, and that there should only be one mark of the ‘color’ family applied to the text at one time. When slate detects that this condition is violated, it could then remove the old conflicting mark and apply the new one in its place at the specified range.

[cameracker]

Yeah you know, I think you’re probably right. I spent a while thinking about it and bounced it off a few other folks I work with and we couldn’t come up with anything. So the simplicity of the isUnique would be welcome.

[ianstormtaylor]

I think for this specific example of color, having the color hex in the data is the vastly preferred pattern, but there might be a case where they’d want to have different mark type names and have them associated with each other.

Do you have an example? I can’t think of how it would be different. Anything that could be represented by lots of differently-named marks could be represented by a singularly-named mark with data added.