-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Block API: Refactor the parser module in preparation for further work #15674
base: trunk
Are you sure you want to change the base?
Conversation
👋 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. |
@dmsnell, is it something we still want to work on?
Some aspects of the initial proposal should be already resolved in alternative PRs. |
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 😄 |
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.
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. |
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.