Consider mobx

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

infrastructure change

What’s the current behavior?

Slate uses immutable internally to improve editor performance.

When a render happens, Slate compares nodes for reference equality and skip the re-render if they are the same.

There are two issues with this (1) as the document gets bigger there are more objects that need to be compared on each render so performance can become an issue in a big document even if the change is small (2) there are cases where data outside the Immutable document effects the render. These need to be handled on a property by property basis in shouldComponentUpdate and is a cause for easy to miss bugs in custom Slate code where the outside value changes but the editor isn’t re-rendered.

What’s the proposed behavior?

So I’m posting this because I’ve been thinking about this for a while. I understand this would be a huge change and would be hard to do anytime soon if ever. Mostly, I just wanted to start a dialog even if it’s short lived so I can move on from thinking about this.

Mobx basically works in reverse. When you update the data structure, mobx is already tied to the right components to do the renders. In other words, it doesn’t need to traverse the entire document tree in order to update the right component. This should solve the performance problem as documents get larger.

Furthermore, as long as any other render dependency values are mobx values, we don’t have to worry about updating the shouldComponentUpdate logic. This removes that problem case which seems to show up regularly in Issues.

Practically speaking, two things of note:

• According to bundlephobia mobx is a little smaller than ImmutableJS so if there is a switch done at some point the total size should be about the same
• As render dependencies get more complex or the document gets larger, mobx because more and more performant and simpler to manage on a relative basis

[ianstormtaylor]

Hey folks, I’m going to close this in favor of https://github.com/ianstormtaylor/slate/issues/2345 now. I don’t think we’d end up using MobX, as React seems to be moving away from monolithic state management in general (which I’m in favor of). But the idea of being able to use plain JavaScript constructs is incredibly appealing for other reasons. I’d love if you could add your thoughts there. Thanks!

[thesunny]

Performance graphically illustrated:

Below is the way Slate works now. We changed one of the values from 1 to 2 and each | represents a comparison and the o represents no change and x represents a change.

1111111111111111111111111111111111111211
||||||||||||||||||||||||||||||||||||||||
oooooooooooooooooooooooooooooooooooooxoo
1111111111111111111111111111111111111111

With MobX we make one comparison

1111111111111111111111111111111111111211
                                     |
                                     x
1111111111111111111111111111111111111111