setState() will block editor.insertText() before it.

Do you want to request a feature or report a bug?

A bug.

What’s the current behavior?

Code: ` class App extends React.Component { state = { value: initialValue, currentState:‘0’, } onChange = ({ value }) => { this.setState({ value }) } onKeyDown = (event, editor, next) => { //Insert text. editor.insertText(‘11’) //Update state. this.setState({currentState: ‘0’})

} } `

What’s the expected behavior?

It’s expected to insert text “11” when I press any key. But in fact above code only show one character that I press. After remove setState, everything is OK.

[michelmanago]

Thanks for this thread. Yes, it is worth documenting. I am new to slate and spent several days struggling to figure out what I was doing wrong. Today, after reading this thread, I realized that I really wasn’t doing anything wrong but that it was this state update issue that was interfering with my code… I now finally got my code to work with the !triggered kludge (I don’t really fully understand why this solution works, but it does so I’m glad).

To give you some background, I was trying to open a modal dialog (in React) in order to edit all the link information (link text and link Url) via a single dialog. None of my Slate commands produced any effect. In order to close the modal dialog, I updated the state of the parent component and as a consequence, all the changes made to the value of the editor were discarded…

Ian, you might want to update the link example in slatejs.org instead of relying on two window.prompt to change the text and the URL of the link. I suppose that it would make the example a little more complex if you introduced a modal dialog, but this would tremendously help newcomers like me and avoid that they struggle with this state update issue.

To explain some of the difficulties a newcomer like me might have with Slate, I tried to use some transform and apply methods that I read about in another issue. Then I figured that this was deprecated . Then, I tried to figure out how Slate worked by looking at the code from slate-editor.bonde.org. That didn’t help. The bonde code was written some other evolutions in Slate took place and Bonde relies on some change object that is now deprecated. I got errors that Slate had evolved since version 0.xxx where Editor.value.change could no longer be used and should be replaced by Editor.change. When I tried this, then I got another error that since version 0.47 Editor.change was also deprecated.

Opening a modal dialog to change the link parameters is something that many people might want to implement, so it would really help to have this state update issue documented somewhere else than in this thread. I well realize that this issue came up fairly recently (less than two months ago) but it really hurts…

Anyway, hello from Paris and Thank you for Slate. Despite the small troubles, it is a far better solution than CKEditor and the dozen other solutions that I tried before I found out about the existence of Slate…

With kind regards,

                                                     Another French user of Slate...

[jonahkagan]

I ran into a similar problem. I think the issue might be that when you call setState, it triggers a re-render. Since value is stored in the component state and passed into Editor during render, this re-render will set the editor’s value back to what was stored in the state. So any changes you made to the value via the editor’s API will be overwritten.

In other words, there’s a race condition between the editor’s onChange callback that you use to update the value from the editor to the state and React’s setState handler that renders the editor using the previous value in state.

Given this hypothesis, I tried to fix the issue by overwriting the value stored in state using the newly updated value from the editor, like this:

this.editor.wrapInline("link")
this.setState({
  triggered: !triggered,
  value: this.editor.value,
})

This resolved the issue for me. Hope it helps with your cases!

@ianstormtaylor: This might be worth documenting as a potential gotcha when controlling the editor’s value. Or maybe exploring a mitigation strategy (or even just a loud error message) when the value is changed differently via the editor’s API than via the editor’s props.