RichText: Do not run valueToEditableHTML on every render

[ellatrix]

Description

Currently we are calling valueToEditableHTML, which creates HTML from a RichText value, on every RichText render call, while this should only every be called once on every mount, to set the initial HTML in the TinyMCE component.

I think this removes about 3.5-4% of the work done on every key press. Note that it does not only affect key presses, but renders in general. So this function will be called a lot more than needed.

How has this been tested?

Screenshots

Types of changes

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.

[ellatrix]

Slightly related: #12402.

[oandregal]

mmm, wouldn't this have the same effect than before?

This is what I see:

• the record value is created on every RichText render by the getRecord function.
• the getRecord function returns a new object every time is called.
• on every RichText render, the TinyMCE component will receive a new object reference for the record prop (although values may be the same, I haven't looked at what this function does), so it'll be re-rendered.

[oandregal]

oh, I just saw that the TinyMCE component defines a shouldComponentUpdate that always returns false. So what this PR is trying to avoid is to actually call valueToEditableHTML in every RichText render, not re-renders of the child component.

[ellatrix]

Right, valueToEditableHTML will only be called on mount there.

[oandregal]

So, my understanding is that this would reduce the time it takes RichText to execute in every render/commit phase. I've tested this by:

• Opened the Gutenberg demo.
• In the first paragraph introduced the text "Howdy. ".

These are the results in master:

These are the results in this branch:

Perhaps is difficult to observe in the GIFs, but it looks like RichText takes ~0,5ms to render in every keystroke in both master and this branch. I don't see at the moment which other tests I could do to effectively measure the reduction of the performance budget introduced by this branch.

Nevertheless, doing less work is always better! So, I think it's fine to merge this.

[oandregal]

Actually, within RichText, the more expensive part seems to be the FormatEdit component.

[ellatrix]

A new record being created? Which function exactly?

[oandregal]

I'm from mobile now.

This is from React Developer Tools' new profiler (to be found in the React tab). You can navigate every commit and components that were updated will be colored (bluish to yellow, yellow the ones that took the most time).

The getRecord method in RichText does:

getRecord(){
    const { formats, text } = this.formatToValue( this.props.value );
    const { start, end } = this.state;

    return { formats, text, start, end };
}

essentially returning a new object no matter whether formats, text, start, end values have been updated or not.

[ellatrix]

Where does the result of getRecord get compared?

[ellatrix]

Oh, I see now. Good catch.

[oandregal]

My understanding is that React does a shallow comparison of the props passed to the components to decide whether a particular component needs to be re-rendered. We have two mechanisms to avoid re-rendering: 1) always pass the same prop (in the case of arrays and objects, the same reference) or 2) hook into shouldComponentUpdate to do that process ourselves.

[oandregal]

I see some e2e test failing, but they seem unrelated (may I have heard somewhere that they're now failing for every branch due to a Travis issue?).

This works properly and the code is fine, so giving you a 👍 dependant on e2e tests passing.

[ellatrix]

@nosolosw There are two render calls on every key press. In the picture below you see one selected, one a bit further on. Removing these calls speeds up the render call significantly. Overall it has a smaller impact on the whole work per key press though.