Reduce number of component updates

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

Bug

What’s the current behavior?

Render time is slow.

In the HugeDocument example, a keypress event takes ~300ms (CPU slowed down 6x)

Compare that to the exact same document, but without updates propagated through react. It’s <100ms:

Proposal:

(Re)introduce selective rendering logic.

As I understand it, here’s the current flow:

1. key event
2. add OT to the queue
3. flush the OT queue
4. update the component via setState
5. react updates DOM (EXPENSIVE)
6. reset scroll & selection range via cDU (EXPENSIVE)

Here’s an improved flow:

1. key event
2. add OT to the queue. Each OT that has a behavior that is different than the native DOM content editable behavior sets a 1-way pushUpdate flag
3. flush the OT queue
4. update the component via setState
5. use shouldComponentUpdate = () => value.get(pushUpdate)
6. If update, do steps 5 & 6 above

Key notes:

• An enhanced solution is to delay flushing the OT queue until it’s required (eg a request to serialize), similar to what immutable-js does. I’m ruling this out of scope to keep it simple.
• This is a blocker for Android support #1935.

[isubasti]

@ianstormtaylor I think the performance of keypress described on this issue was due to the example site was using the dev version of react which has been solved by https://github.com/ianstormtaylor/slate/pull/1939 . The current performance of keypress with production build is now ~40ms instead of ~300ms. Also tested production build of https://github.com/ianstormtaylor/slate/pull/1975 with memoization on slate react seems to reduce it down even further to ~20ms.

[mattkrick]

maybe, but that just forces the user to end up writing and managing incredibly complex diffing logic themselves

perhaps i didn’t make this clear. the onus is on the plugin author. if they don’t want to write that logic, that’s fine. The performance is no worse than it is today.

Feel free to open new issues with specific actionable items for which parts of rendering are slow and could be avoided.

I listed the exact bottlenecks in the original comment:

1. react updates DOM (EXPENSIVE)
2. reset scroll & selection range via cDU (EXPENSIVE)

I’ve detailed out a plan to avoid those bottlenecks without the need for a breaking change. I don’t know what else I can do.