SPT: immediately render modal with empty thumbnails

[retrofox]

Changes proposed in this Pull Request

This PR changes slightly the approach in how the thumbnails are dynamically previewed.

Although it doesn't depend strictly on WordPress/gutenberg#17242, it will improve reduce the previewing time even for all thumbnails and as well as the large preview (100ms)

Overview

The current behavior waits to get the templates parsed before to start to render and mount the components. It produces a delay when the template modal appears. In order to improve the performance and the user perception, I purpose the following more important changes in this PR:

• Disengage the parsing process from the react component, starting to process as fast as possible without waiting for the component lifecycle.

• Do not update the state with the parsed templates blocks. Update the state seems to take considerable time.

• Add a templates-parser.js which acts as a data store and global event dispatcher. It contains selectors in order to get the desired data.

• Dispatch onTemplateParse global event to communicate with the component. The event dispatcher sends all data about templates in the event object argument:

window.addEventListener( 'onTemplateParse', event => console.log ( event ) );

The event detail object contains the following fields:

• blocks: list of the parsed blocks
• count: the number of blocks
• isEmpty: true is the template doesn't have content.
• isParsing: defines if the template is being parsed or not.
• title: template title.
• slug: template slug.

Testing instructions

Apply the patch and confirm that you see the spinners in the thumbnails when the templates are being parsed.

Static vs Dynamic

Tests

Parsing One By One

time - blank: 0.005126953125ms
time - about: 46.718017578125ms
time - contact: 19.9072265625ms
time - portfolio: 28.283935546875ms
time - services: 51.375ms
time - team: 37.27197265625ms
time - blog: 29.65673828125ms
time - menu: 51.2978515625ms
time - total: 6304.18798828125ms

[matticbot]

Test live: https://calypso.live/?branch=update/spt-rendering-template-item

[obenland]

Rather then checking for blocks here, how do you feel about testing this.state.blocks in PageTemplateModal.render()?

if ( ! this.state.isOpen || isEmpty( this.state.blocks ) ) {
	return null;
}

[getdave]

I still think the component should function when the props aren't provided as expected. It makes them more resilient when moved to an alternative use case.

This doesn't preclude your change happening as well.

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[getdave]

Async rendering these is a massive win. Great workl

[obenland]

Page load times are still extremely long. Locally it takes 9s to fully load the page, including the thumbnail previews. With static thumbnails it's 3s (which is still long).

I'm afraid we'll need to do better before this is mergeable. :/

[obenland]

@youknowriad Do you happen to have any ideas how we can cut down on the time it takes to setState here?

[retrofox]

Locally it takes 9s to fully load the page,

it doesn't take that time to me. Let me paste a gif with a clock at the bottom right corner.

[retrofox]

I've measured both process. The reduce loop wich contemplates parsing all block of all templates: time:reduce: 351.2021484375ms,
and setting the state: time:set-state: 1388.221923828125ms

[retrofox]

Another thing I forgot to mention that is I'm testing this PR together with this one, reducing the delay before to start to compute the scale factor from 100ms to 0, through of the __exoperimentalScalingDelay property.

[youknowriad]

@youknowriad Do you happen to have any ideas how we can cut down on the time it takes to setState here?

I assume that's the setState that sets the block list and triggers the rendering. I fear that there's not much we can do there. things to consider maybe:

• Cut the number of blocks to render (or maybe render some and then update the list with the full list async)
• In Core an idea to explore is a "preview mode" for blocks where maybe somethings can be removed entirely, components only useful for edit like block appenders, movers, dropzones... (it needs to be measured though to avoid unnecessary complexity)

[retrofox]

Preview mode is something that worths to dive imo. We talked about this a few weeks ago.
What I've done, just for this approach, is avoiding to write the state with the parsed blocks. Going to update the PR description.

[lancewillett]

Cleaning up older pull requests as part of a GitHub scrub.

Is this change still valid? What's needed to move this along? It looks like an important performance boost. CC @retrofox

If not valid, please close with a comment. Thanks!

[github-actions]

This PR has been marked as stale due to lack of activity within the last 30 days.

[obenland]

There's a new version of SPT out now, let's close this.