Slate: onChange event not firing

Created on 14 Jan 2020  路  8Comments  路  Source: ianstormtaylor/slate

Do you want to request a _feature_ or report a _bug_?

bug

What's the current behavior?

Inputs and other tags inside custom elements can only be changed if they are within a portal.
onKeyDown fires correctly, but onChange never fires. Others on the slack channel have also come across this bug, and state the only solution is placing the custom element within a portal.

CodeSandbox: https://codesandbox.io/s/slate-reproductions-wcko1

<input
    onChange={() => console.log('this never fires')}
    onKeyDown={() => console.log('but this works')}
/>

Slate: 0.57.1
Browser: Chrome
OS: Mac

What's the expected behavior?

onChange should fire in custom elements without needing to be inside a portal / pop-up.

Most helpful comment

Hey this is quite the hack but if you wrap your input inside a div and give it the attribute data-slate-editor then the onChange handler should call. This fools Slate into thinking that the input is outside the editor so your input will work as normal. The issue I just created #3425 is more or less regarding the same thing, but my case was with CodeMirror which has a textarea whose onInput never fires. From what I can tell with some experimenting the culprit seems to be the Editable component that steals focus from inputs/textareas as you type. I would really like to get this resolved but in the meantime this hack seems to work nicely

All 8 comments

Hey this is quite the hack but if you wrap your input inside a div and give it the attribute data-slate-editor then the onChange handler should call. This fools Slate into thinking that the input is outside the editor so your input will work as normal. The issue I just created #3425 is more or less regarding the same thing, but my case was with CodeMirror which has a textarea whose onInput never fires. From what I can tell with some experimenting the culprit seems to be the Editable component that steals focus from inputs/textareas as you type. I would really like to get this resolved but in the meantime this hack seems to work nicely

Can confirm @Francesco-Lanciana fix works

not sure if the problem I encountered is the same, but IIRC I fixed the problem by just wrapping my component (the one who was rendering the input element) inside a <span {...attributes}>

Hey this is quite the hack but if you wrap your input inside a div and give it the attribute data-slate-editor then the onChange handler should call. This fools Slate into thinking that the input is outside the editor so your input will work as normal. The issue I just created #3425 is more or less regarding the same thing, but my case was with CodeMirror which has a textarea whose onInput never fires. From what I can tell with some experimenting the culprit seems to be the Editable component that steals focus from inputs/textareas as you type. I would really like to get this resolved but in the meantime this hack seems to work nicely

ugly, but it works馃槹馃槀

Thanks for the work around!

It works in one way but it breaks jumping with the arrow keys over the custom element.

@alfechner yep I definitely hit that wall hard haha. In my case (implementing a code editor inside Slate) I needed to essentially emulate the arrow keys in code which is complex. Unfortunately having thought about it a bit I can't see any way for this not to be the case since Slate can't really know what component is being rendered in an isolated node, or how it will utilise the arrow keys. It could maybe provide some helper functions though to make it easier to hand over control from slate to the component and vice versa.

@Francesco-Lanciana hm I don't quite understand. You mean that the onChange event of input elements is not triggered is a design problem?

Closing, I think this is fixed in https://github.com/ianstormtaylor/slate/pull/3436

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JSH3R0 picture JSH3R0  路  3Comments

AlexeiAndreev picture AlexeiAndreev  路  3Comments

gorillatron picture gorillatron  路  3Comments

ianstormtaylor picture ianstormtaylor  路  3Comments

adrianclay picture adrianclay  路  3Comments