Block API: Refactor the parser module in preparation for further work #15674
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dmsnell
added
[Feature] Block API
dmsnell
requested review from
ellatrix,
gziolo,
noisysocks and
youknowriad
as code owners
|
👋 Dennis! Is there any update on this PR? Is it perhaps in a state that someone can move it forward? Thanks! |
|
@hypest I haven't touched this in a long time. I would imagine it's easier to start over and recreate this to get it ready for merging (can re-use the PR and force a new branch I'm pretty occupied for a while. Are you wanting to work on it? I'd love to help if you do. |
7 tasks
|
@dmsnell, is it something we still want to work on?
Some aspects of the initial proposal should be already resolved in alternative PRs. |
gziolo
added
the
[Status] Stale
Yes! @gziolo I would love to come back to this and hopefully in the next week can come back to revive the PR.
|
Awesome, I will watch the progress 😄 |
kathrynwp
removed
the
[Status] Stale
This patch contains a mixture of small refators, mostly a combination of updating comments and explanations as well as rearranging some array iterating code to use more traditional loop control structures. While the comments should be self-explanatory, the loop control structures are refactored for a dual purpose. In framework code like this that is core to the project and often untouched, there is value in optimizing to eliminate memory allocations and reduce pressure on the garbage collector. These costs are often difficult to profile in existing tools. More imporantly, as we think about introducing an asynchronous block loading system we need to prepare to handle the semantic changes that asynchronous flow introduces. These changes are meant to smooth the transition to asynchronous code while clarifying how blocks are loaded into the editor.
dmsnell
force-pushed
the
block-api/prep-refactor-on-parser
branch
from
4979cbf to
6234074
Compare
|
Size Change: +105 B (0%) Total Size: 1.28 MB
ℹ️ View Unchanged
|
|
Doing some repository cleanup today, I was wondering if this PR is still relevant and worth keeping open? |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
@youknowriad it would take some updating but I still find value in it because the parser still IMO lacks some clarifying vocabulary. I was curious how much it bumps into the work that @jsnajdr recently did. |
|
The one part of the diff that looks familar to me are the changes to My block lazy loading experiment does very similar changes here: I don't immediately understand the changes in I also see a plenty of jsdoc changes and new jsdoc documentation. It could be valuable to extract these new docs and land them. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
This patch contains a mixture of small refators, mostly a combination of
updating comments and explanations as well as rearranging some array
iterating code to use more traditional loop control structures.
While the comments should be self-explanatory, the loop control
structures are refactored for a dual purpose. In framework code like
this that is core to the project and often untouched, there is value in
optimizing to eliminate memory allocations and reduce pressure on the
garbage collector. These costs are often difficult to profile in
existing tools. More imporantly, as we think about introducing an
asynchronous block loading system we need to prepare to handle the
semantic changes that asynchronous flow introduces.
These changes are meant to smooth the transition to asynchronous code
while clarifying how blocks are loaded into the editor.
Why
It would be helpful to be able to load blocks asynchronously and defer
the loading of deprecation code and heavier block implementation code.
Right now that's not possible given that the block loading system is
fully synchronous.
This is the start of several changes that would be necessary to support
asynchronous loading, and this exists as a small piece of that which is
designed to be minimal in order to be easy to review.
Testing
Since the changes in this PR impact fundamental data flow in the editor
the testing suites should catch most notable bugs. Please audit the code
and look for ways that subtle bugs could creep in, how the refactor may
not be true to the code it replaced.