Draft-js: Expected Editor Behavior Question

[thesunny]

I'm finding a bunch of editor behavior which is not as one would expect from your typical editor (e.g. Microsoft Word or Google Drive). I've been fixing these as I go along in order to give my user's a better experience.

A few examples:

• If I hit enter at the end of a header block, the next line should be a paragraph or unstyled. This is how a standard word processor works.
• If I start a line with a * and hit space, it converts it to an unordered-list-item
• If I start a line with a 1. and hit space, it converts it to an unordered-list-item
• If i hit enter on a blank unordered-list-item it reverts to a paragraph or unstyled

Especially the header issue feels like it's just broken currently.

My question is, is the goal of the core draft-js to make it work like a standard word processor? It feels like there are bits and pieces already designed to do this like the onTab handlers in RichUtils. These are packaged in the core project.

If the answer to this is yes, I can submit these changes back to the project. Just wanted to clarify what the expectation is for what will go into the project.

[hellendag]

The goal of core Draft.js is not to behave like a standard word processor, but to provide the basic pieces to allow developers to create desired editor behavior.

RichUtils is provided for convenience with a handful of functions that we are using internally, but is certainly not required to create rich editing behavior. Clients are welcome to define any utilities and behavior they like. If, for a given use case, RichUtils only becomes a basket of example functions on which to base more specialized behavior, that's perfectly fine.

There is a spectrum of features and behavior that users expect from rich text editors. Some features (undo/redo, key commands, cut/copy/paste) are integral, while some features (i.e. return/backspace quirks regarding block type) can be less standard and more specialized to individual editors. There is a balance, and ideally the framework provides the integral pieces without being too prescriptive about the specialized pieces.

In cases like * and 1., I'm not sure it is the framework's responsibility to have an opinion about how that should be handled -- that feels a little more specialized to me.

All of that said, I could be wrong about some standard editor behaviors. If there is an argument to be made that all editors share behavior patterns that are not currently built into Draft, then I'm open to accommodating those features in RichUtils or otherwise. :)

[thesunny]

Thanks for the clarification,

The * and 1. definitely feel more opinionated. Maybe best made available as an external plugin.

On the other hand, hitting enter at the end of a header block reverting to a paragraph style block feels like any good editor will do that. Word, Google Drive and Pages on OSX all have this behavior.

I guess that's still an opinion but it might be nice to have a pre-built handler for that like the one for onTab. Users can opt in to this standard.

If interested, I can probably put a PR for it.

[remko]

I implemented all the mentioned behaviors above as well, but I also feel more comfortable if Draft would keep magic behavior out of core as much as possible.

Going from H to unstyled sounds pretty common (FB Notes does it as well), but on the other hand, now the semantics of 'return' in a block are simple: split the block in 2. I hesitated asking for a configuration option for deciding what to do with an 'empty block split'/'return at end of block' to solve the H1 problem, and it could probably also work with lists unindent, but not sure if this would make it too complicated.

It sounds like it would be nice to be able to have infrastructure to put these behaviors into separate plugins though, so we can cherry pick behaviors (e.g. Editor allows you to provide a list of 'plugins' that can hook into the various on* events). Not sure how well such a chain of independent behaviors would work in practice, before they start interfering with each other.

[thesunny]

Just to clarify, I wasn't suggesting a configuration or to have core handle it by default but to offer a method in RichUtils similar to the onTab (which also isn't attached by default).

Not pushing for this but just clarifying what the suggestion was.

I like the idea of plugins, especially since some of these behaviors feel like they should be wrapped together. For example, all the list handling behaviors could be wrapped into a single plugin instead of trying to attach handlers for different events. Would be nice if a plugin could take some configuration as well.

[dmr]

What is the status on this feature?

For our use case copy and paste from Microsoft Word ist a common task. Draft.js does not handle this very well right now --> Are there any plugins oder anything like this available to provide this functionality?
Not the whole .docx standard but Bullet point lists and base formatting.

Thanks for bringing this topic up @thesunny

[remko]

I was planning on submitting a RichUtils PR soonishly for issue 1 and 4 (on the basis that this is common behavior in other editors), but was waiting on #264 to make this easier (which is now integrated).

2 and 3 are probably implemented in many of the Draft-based projects and/or plugins, so you can have a look there. Copy/paste issues from Word sound like a different issue than this one, though. (this issue is about direct keyboard input).

[dmr]

Cool, thank you for the quick reply

[mitermayer]

Closing this thread for now, but if there is still interest in this discussion please feel free to reopen/comment or create a new issue around it.