Plugins should have a chance to handle key commands before editor about draft-extend HOT 6 CLOSED

Interesting...have you checked out the mention.html example file? It does something similar to what you're describing - it handles the return and tab events and stops the editor from handling it by calling preventDefault/stopPropagation and returning true. Another thing to note is the subscription and unsubscription to key commands by the overlay on mount/unmount. Does this differ from your usecase?

from draft-extend.

It is different, I have a handleReturn in my editor which saves the text from the editor. Because of the order the handlers are called, the plugins never receive the return. See here

What I'm suggesting is to flip the || and call handleKeyCommand first

from draft-extend.

Ah, I see. In my opinion the way it currently is ordered is the most consistent and predictable. I tried to keep the same structure as the original Draft Editor. That is, for an event prop like handleReturn passed in, it has the opportunity to prevent any handling performed by the component it's being passed into. When plugins are introduced they sit between those props and the base Editor component. To preserve that same interface it would make sense that the plugin's functionality would also get overridden since it's the component being passed the handleReturn prop. Does that make sense?

I think the best way to solve the problem you're running into would be to put what you're currently passing into handleReturn into a plugin using the keyCommandListener option to handle the 'return' command. This should properly prioritize it to not override the overlay's key handling.

from draft-extend.

I see plugins as additions to the base Editor, as so they should have a chance to handle events before the main component. I think it gives more power to the plugins without removing anything from the Editor, its default behaviour remains as a fallback.

Moving the event handling from handleReturn to a keyCommandListener in a plugin would work but could easily be broken if the order in which the plugins are added is inverted. I guess I could package the plugin and Editor as a new component and use that as our base Editor component. That's probably the easiest solution for now.

from draft-extend.

I think we're referring to two different "default behaviors" - to me that means what the base Editor component would do with no passed handlers (in this case create a new line), and I see any thing passed to handleReturn in the component tree as an override of that. When looking at where those two behaviors and plugins live in the component tree, it makes sense that the overriding behavior has the same structure. That is, the base editor is a child of the plugin components, which are in turn children of the component that has your handleReturn, therefore if the plugins are overriding default behaviors of the Editor component, then the parent component of those should also override any plugin behavior.

You're totally right, inverting the order of plugins would switch the order of priority! That's an important part of having plugins being a composition of higher-order components that I've found to be pretty valuable. Like middleware in redux or express/koa, having a clear, predictable composition of handler functions to me is a feature.

from draft-extend.

Thanks for the explanation, I'm fairly new to hoc and I was looking at the problem differently. After reading your comment, I agree that it's probably better to move the code from handleReturn to a plugin.

from draft-extend.