wp-calypso icon indicating copy to clipboard operation
wp-calypso copied to clipboard

Published 20 hours ago • verified publisher icon Automattic

Pattern Assembler: (Spike/Research) Fast preview component for pattern and site previews

Open miksansegundo opened this issue 3 years ago • 3 comments
trafficstars

The iframe previews using the endpoints block-previews/pattern and block-previews/site are slow compared to an alternative solution used in Gutenberg to inject a pattern in an iframe directly from the front-end without rendering the HTML from the server.

We wanted to give it a try to test the performance, and we seem to agree that it is not enough, meaning that the usability of the Pattern Assembler would be degraded. It affects the loading time of the pattern and site previews as it would be annoying UX if the preview keeps flashing the loading message as users modify patterns.

The other technique used in Gutenberg is much faster, and we want to pursue it. This solution is crucial for the final result but not a blocker for other tasks.

Acceptance criteria

  • will be used together or replacing the current WebPreview #66786
  • will be used in the pattern selector to render the list of patterns, one pattern at a time #66788
  • will be used in the site preview to render the Header, the Footer, and Sections selected. #66786
  • will NOT be implementing search feature in MVP / first iterations of of the pA flow

Related

Slack conversation p1661428727469409-slack-CRWCHQGUB https://github.com/Automattic/wp-calypso/issues/66589

miksansegundo avatar Aug 29 '22 06:08 miksansegundo

We should avoid relying on <WebPreview /> since it's not packaged. Might be worth looking into whether<ThemePreview /> (src) suits the requirements, or creating a new packaged component tailored for PA.

taipeicoder avatar Aug 29 '22 06:08 taipeicoder

Some more considerations about the site preview vs the patterns preview. They might not be the same because:

Site preview is much more complicated than just "list of patterns" because we have to take into account e.g. query-block post source sites... etc

My take is that the patterns and the site previews in the PA project are rendered using the theme Blank Canvas, which has no demo content. Meaning that the patterns and the content in the previews are coming from the source site dotcompatterns only. This is the way the previews work in the Gutenberg Block Inserter, and that's why we aim to copy/adapt that code into the PA project.

Screen Shot 2565-08-29 at 14 13 22

miksansegundo avatar Aug 29 '22 07:08 miksansegundo

Another option is optimizing the existing endpoints block-previews/pattern and block-previews/site for the PA project because it does not require:

  • to verticalize patterns or sites
  • to add styles based on the theme (always use Blank canvas)
  • to generate HTML (it could be pre-cached)
  • others?

miksansegundo avatar Aug 29 '22 07:08 miksansegundo

Status Update on Dec 7

What we have done

Referring to https://github.com/Automattic/wp-calypso/pull/70063, we're able to render the blocks on calypso, and

  • It's faster than before!
  • We're able to control each pattern on the large preview, e.g.: replace, reorder, delete, drag & drop, scroll to newly added pattern, show the active style, etc
  • We don't need to request the block-previews/patterns endpoint for every pattern
  • We don't need to request the block-previews/site endpoint whenever the selected patterns change

See pbxlJb-30c-p2 for more details and here is a quick demo:

https://user-images.githubusercontent.com/13596067/206114613-56b0e64f-498d-44b9-b96e-f9219c18515c.mov

Now the downside is we will generate the index-based class name when wpcom renders the pattern (e.g.: wp-container-x). As a result, we have to request the wpcom endpoint to render all patterns at once to avoid the conflicts between class name. For example, if you request the wpcom endpoint to render pattern 1 and pattern 2 respectively, they will generate the same class name, wp-container-1, but the styles will be different. If we have too many patterns, we have to consider how to improve this part (we could but the experience might be not great?)

What we still need to do

  • We need to verify how to connect with the global styles. It's possible because we tried it in the first implementation PR
  • We need to render the specified site information (e.g.: site logo) correctly. Now the rendering is based on the newly created site, so the site information might not be set, especially for the site logo. Thus, the site-related block might look weird. Here are possible ways to resolve this issue
    • Make the rendering base on the demo site, just like what we're doing now
    • Add hook to render customized site-related blocks but it's not easy for the site logo block
    • Render the default placeholder for the site logo block if the site logo is never set. But it needs to change the behavior of the Core
  • Continue above, the query block might not have any post to render either.
  • Need to support atomic site as well

arthur791004 avatar Dec 07 '22 07:12 arthur791004

Close it as we have finished the spike 🙂

Here are references:

  • pbxlJb-30c-p2
  • pbxlJb-39t-p2
  • pbxlJb-3gc-p2

arthur791004 avatar Jan 03 '23 10:01 arthur791004