bug
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
onChange should fire in custom elements without needing to be inside a portal / pop-up.
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-editorthen 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
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-editorthen 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