Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Site editor - what options are there for preloading content? #35942

Closed
talldan opened this issue Oct 26, 2021 · 3 comments
Closed

Site editor - what options are there for preloading content? #35942

talldan opened this issue Oct 26, 2021 · 3 comments
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") REST API Interaction Related to REST API [Type] New API New API to be used by plugin developers or package users.

Comments

@talldan
Copy link
Contributor

talldan commented Oct 26, 2021

What problem does this address?

Continues the discussion from #35746 (review)

Currently the site editor loads much of its content asynchronously. The nature of template part (and other FSE) blocks is that they each load their own content, which results in a slow first interaction for the user, visible loading states on the screen, and content moving around.

What is your proposed solution?

I've outlined one, but it's worth discussing options. Also not sure if there are prior discussions about this. I did a search, but couldn't find anything.

There are some challenges. Firstly the full content for a template in the site editor isn't known until each layer resolves. A (pseudocode) template might contain content like:

<!-- wp:template-part { "id": "header" } /-->
<!-- wp:template-part { "id": "body" } /-->
<!-- wp:template-part { "id": "footer" } /-->

We don't know what content is inside the header, body and footer until those are preloaded. Those template parts might contain other template parts, reusable blocks or other blocks that also need to be loaded, and then the whole process repeats like a preloading matryoshka.

So a preloading system would ideally have two qualities:

  • It needs to center around the blocks in content
  • It would be recursive to a particular depth. Preloaded content is checked again for any required preloading. Why only to a particular depth? A preloading system could continue recursively preloading everything, but there would be a point at which doing so would be slow because it's impossible to make such requests in parallel. Probably only 2 levels is all that's needed to preload the main structure of a template.

A potential solution could be:

  1. Some blocks like template parts have a 'preload' definition in their PHP block type. A function that receives attributes and returns information that can be used to preload data, similar to how the current preload_paths system works?
  2. When loading the editor, the blocks in the content are parsed and converted to a flattened array.
  3. The flattened array of blocks is iterated through, and where a block has a 'preload' definition, call that function to get the preloading info.
  4. Preload the required data using the accumulated preloading info.
  5. Recurse, repeat steps 1-4 n-1 times on the preloaded data (if that data contains blocks)
@talldan talldan added REST API Interaction Related to REST API [Type] New API New API to be used by plugin developers or package users. [Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") labels Oct 26, 2021
@andrea-calligaris
Copy link

Related to #15746

@youknowriad
Copy link
Contributor

Should this be considered a duplicate of #35503?

@talldan
Copy link
Contributor Author

talldan commented Feb 27, 2023

Yeah, seems fine to close it.

@talldan talldan closed this as not planned Won't fix, can't repro, duplicate, stale Feb 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Site Editor Related to the overarching Site Editor (formerly "full site editing") REST API Interaction Related to REST API [Type] New API New API to be used by plugin developers or package users.
Projects
None yet
Development

No branches or pull requests

3 participants