Runaway recursion when trying to access `editor.value` in a plugin `onChange` event

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

Report a bug

What’s the current behavior?

Get a depth exception when trying to access editor.value in a plugin onChange event.

Just try to load this fiddle and it will throw errors: https://jsfiddle.net/uvkrn9ge/1/

Chrome latest Mac OSX.

Note: I did narrow this down to a change in version 4.0.2 of memoize-one. I think this error may have always been happening, it was just covered up.

[ericedem]

Ok this will be reproducible with this fiddle once a new version of slate gets published with memoize-one@4.0.2. https://jsfiddle.net/uvkrn9ge/21/

The loop is:

1. onChange() in the plugin gets called initially with the value being set.
2. editor.value is dereferenced, causing the getter in this.resolveChange to get called (mentioned in my last comment)
3. The plugins are then fed an empty Change instance into their onChange() handlers.
4. GOTO: 2

The reason why this wasn’t a problem before is that in 4.0.2, the behavior of memoize-one changed such that when you recurse in a memoized method, it doesn’t remember what the result is until after the function finishes getting called, which will never happen because the recursion never terminates. So it just keeps seeing the same value and passing the same value check because it was never set. I think this is actually the correct behavior in memoize-one as it makes sure that in recursive methods the original arguments are what g memoized.

What ends up making this even worse is that if you specify a schema in a plugin, the same schema check will also fail in before.onChange() so the change will get an operation added. This means that in the plugin onChange() you can’t short circuit if change.operations.size === 0. The workaround we had to do was to pin memoize-one@4.0.2.

I created a simple local slate example based on that fiddle and upgraded to memoize-one@4.0.2 and it does indeed break as we see in our environment. I can push that if people want to look at it.

[zhujinxuan]

@ericedem The problem of setState with componentDidUpdate is the performance. Here is a issue about it https://github.com/ianstormtaylor/slate/issues/1938

Using setState in componentDidUpdate will double the updates, significantly harm the capacity of handling large document with decorations. (Though, in current slate, we still experience a significant delay (0.3s~0.6s) when editing with large document + decoration)