Need ability to "not continue" a mutable entity #430

[iandoe]

Sometimes, we do not want MUTABLE entities to be continued when they are on the left of
the cursor, for example when creating a LINK entity that we do not want to continue after
pressing the space key, this proposal adds a "Contiguous" setting set to true by default that
we can set to false to get the desired behavior

Please note this is a WIP and not yet ready to be merged

• Rework example for link.html
• Rewrite tests with selection states
• Figure out why exported state does not output contiguous prop

[ghost]

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file. In order for us to review and merge your code, please sign up at https://code.facebook.com/cla - and if you have received this in error or have any questions, please drop us a line at cla@fb.com. Thanks!

[ghost]

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

[iandoe]

The word contiguous might not be the best, i am open to suggestions on a better term.

[amireh]

This is great, thank you! I will test this in our editor as soon as I get the chance and perhaps help with the remaining points.

FWIW, I thought "contiguous" to be very descriptive but then I knew what kind of problem this was solving so that opinion may be skewed.

[sophiebits]

I don't think the word "contiguous" is intuitive here but am at a loss for better ideas. I wonder if it makes sense to always have entities behave like this? Not sure if there are use cases when you would want an "expand-y" entity.

[iandoe]

@spicyj I think entities like Bold and Italic for example are expected to expand as it is the most common UX so far in wysisyg editors.

[hellendag]

Well, bold and italic are handled internally as inline styles and do not require entities. There has been some previous discussion about whether they should actually be treated as distinct from decorators at all, though certainly they shouldn't require entities.

Is this not manageable by using a handleBeforeInput with the space character? If a space char should be inserted, can you manually perform the insertion, without the entity applied to the new character?

Stylistically, btw, I am strongly anti-boolean-arguments. :)

[aligon]

Are the plans to merge this pull request?

I have a use case that "non-contiguous" entities would solve. There are some other work arounds that I found in #430. For now I'll implement one of those. It'd be nice to know if this will ever be merged or not.

[flarnie]

I'd rather not add a boolean option argument, and I'm also hesitant to add any more API surface to Draft. For now going to close this, but long term we probably will consider an API redesign that takes this into account.

[javierfernandes]

Is there any other way to accomplish this since the PR was not merged ?
I'm also one of those that need this feature. For cases that you don't want the inlineStyle to be continued it is very annoying for the end user.

[thibaudcolas]

@javierfernandes see #430, there are a few examples of how to use handleBeforeInput and Modifier.insertText to implement a custom text insertion, with/without continuing styles or entities.

[javierfernandes]

Hi @thibaudcolas ! thanks for the link. I was able to implement a fix based on code from that issue. Still if feels weird, like something that would be great if supported deeply into draftjs.
For example check this screencast.

Notice that the cursor just right to the "entity+inlineStyle" range still carries the style (although once you type it won't use that style). Probably because the editor's "currentInlineStyle" still holds the style.
Any clue on how this could be improved ?
Thanks !

[thibaudcolas]

True, that's annoying! I agree it would be better if Draft.js supported this directly since this is quite a common use case, but in the past the framework has been quite slow to evolve. Hence the many workarounds in #430.

For the behavior you're showing, yes I wouldn't be surprised if the current inline style was wrong (when inline styles aren't continued), but I would also suspect that the cursor's color is handled at the browser level, and the browser simply has the selection placed inside the span that has those styles. I don't think there is a way to work around this unfortunately.

If I was to implement this, I think I would try to use the same font color everywhere to work around the issue, or replicate how Dropbox Paper allows continuing styles but doesn't do it when entering styles with Markdown-style shortcuts: