-
Notifications
You must be signed in to change notification settings - Fork 3.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Out-of-order updates with React Concurrent Mode #3334
Comments
Looking through source, it looks like Slate is using batchedUpdates within editor.onChange. I'm wondering now, if this is because react state is too slow for this high frequency update, and the value needs to be kept on a ref? |
Update: It seems like this can be somewhat mitigated by using export const SlateInput = () => {
const [value, setValue] = React.useState('');
const handleChange = val => {
+ ReactDOM.unstable_discreteUpdates(() => {
setValue(val);
+ });
};
const editor = React.useMemo(() => withReact(createEditor()), []);
return (
<Slate editor={editor} value={value} onChange={handleChange}>
<Editable placeholder="Enter some plain text..." />
</Slate>
);
}; |
For those interested, I solve this by only storing/serializing the debounced editor value by about 200ms. Update: this doesn't work either. |
@jaredpalmer do you have any learnings that can be added to core to mitigate this? I have no idea what |
I don’t know what it does either, but it seems to work better, but not perfectly if you use it. |
Looks similar to #3236. Have you experienced the autocorrect issues shown there?
What do you mean by that? If you debounce Have you tried newer experimental builds? |
@dminkovsky are you talking about react? or slate? yes, I've tried with multiple experimental builds of react. no luck. I still have not figured out how to get it to work. I really really like the new 50+ api, but looking at other options at the moment. |
@jaredpalmer I was talking about React, just because you mentioned 16.8.6 and I thought experimental builds were based on more recent versions. This past week I had to back off of concurrent mode entirely and went back to to 0.47 as well, despite also liking the 0.50 API a lot more, too. |
cc @gearaon not sure if you’re the right person, but putting this on your radar |
I was using Slate ( |
@jaredpalmer Thanks for mentioning
On the other hand, Therefore, a possible fix to the issue is to wrap const handleChange = useCallback(val => {
ReactDOM.flushSync(() => {
setValue(val);
});
}, []); or const handleChange = useCallback(val => {
ReactDOM.unstable_flushControlled(() => {
setValue(val);
});
}, []); With this change, the original issue seems no longer reproducible. BTW, you misspelled @gaearon, so I don't think he got notified about this thread. |
Yeah I didn't see it. :-) |
This seems to be working fine with the latest slate and experimental version of react https://codesandbox.io/s/slate-0604-concurrent-mode-3x30j |
Yeah, we fixed this |
Basically, we now run updates synchronously by default, and even if we're going to relax this in some future majors for some events, we'll keep that behavior for keyboard, clicks, and so on. And then if you want to opt out, |
Bug
What's the current behavior?
When using Slate with Concurrent React (via ReactDOM.createRoot) on the experimental release channel), updates (to the node list?) can occur out of order resulting in text being appended after the cursor.
https://codesandbox.io/s/slate-050-basic-x-concurrent-mode-bug-qnxqu
Slate: 0.55.3
React: Experimental, 16.8.6 with
unstable_createRoot
Browser: Chrome
OS: Mac
What's the expected behavior?
Updates stay in order no matter how fast the user types.
Suggested Solutions
It seems like this could have to do with either batchedUpdates or scheduler, but I'm not exactly sure. I don't know enough about the internals of Slate to give more detail, but worth getting ahead of this IMHO.
The text was updated successfully, but these errors were encountered: