-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 Bindings: Bootstrap server sources earlier #66058
Conversation
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. |
Size Change: -224 B (-0.01%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
Tests are failing, it seems that now requires to not set a label here: gutenberg/packages/e2e-tests/plugins/block-bindings/index.js Lines 20 to 26 in fe88860
|
That makes sense. I just pushed a commit to change that. |
@@ -1705,42 +1697,6 @@ describe( 'blocks', () => { | |||
'Block bindings source "core/test-source" is already registered.' | |||
); | |||
} ); | |||
|
|||
it( 'should correctly merge properties when bootstrap happens after registration', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this should be allowed or not now that server sources get bootstrapped sooner in the process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now that we force the server to register the source sooner than the client, only the client could override the server, not the other way around.
Flaky tests detected in 447d4ce. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/11323836523
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This sounds like a very reasonable direction as we should land these changes during beta phase for WP 6.7. Can we add additional validation for the registration to detect that the server registration is limited to the name, label, and context. When there is something else it means it the registration on the client and can happen only once?
For the context, the values from the server and the client get merged together. What's the expected behavior for the label? Which one takes precedence?
IMO, the client one should take precedence, as it will be registered after the server.
That's a good one. If getValues, setValues, canUserEdit or getFieldsList is already available, it means it was previously registered on the client, and we can avoid that re-registrastion. |
Previously, we were only checking Regarding the
To be honest, any option is fine for me, so I can implement whatever you think it's better 🙂 |
The label is something that needs to be properly documented. The approach taken is less important to me. It has to be predictable and covered with a unit test that prevents regression. |
I agree. For me it is a matter of defining what is "predictable" for users. The unit test already exists, it just need to be adapted if the current behavior changes. By the way, I run the tests locally with this core branch which includes the necessary code in core, and everything seems to pass as well. |
I made the necessary changes in the WordPress core. We should be able to land these changes, too. |
Okay, I'm merging this one as well. We can create a follow-up if we decide to change how the label is managed. |
There was a conflict while trying to cherry-pick the commit to the wp/6.7 branch. Please resolve the conflict manually and create a PR to the wp/6.7 branch. PRs to wp/6.7 are similar to PRs to trunk, but you should base your PR on the wp/6.7 branch instead of trunk.
|
@SantosGuillamot Looks like this didn't cherry pick cleanly. Would you be able to take point on getting to merged to the |
Sure! I'll take care of that. Thanks for pointing it out. |
* Remove bindings bootstrap functions * Remove bootstrap calls * Remove old filter * Adapt unit tests * Add compat filter in Gutenberg * Only run script if not already registered * Remove extra label in test * Remove unit test * Add backport changelog * Return warning if any client-only prop is defined Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: ryanwelcher <[email protected]>
I've started working on it here. |
* Remove bindings bootstrap functions * Remove bootstrap calls * Remove old filter * Adapt unit tests * Add compat filter in Gutenberg * Only run script if not already registered * Remove extra label in test * Remove unit test * Add backport changelog * Return warning if any client-only prop is defined Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: ryanwelcher <[email protected]>
* Remove bindings bootstrap functions * Remove bootstrap calls * Remove old filter * Adapt unit tests * Add compat filter in Gutenberg * Only run script if not already registered * Remove extra label in test * Remove unit test * Add backport changelog * Return warning if any client-only prop is defined Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: ryanwelcher <[email protected]>
* Remove bindings bootstrap functions * Remove bootstrap calls * Remove old filter * Adapt unit tests * Add compat filter in Gutenberg * Only run script if not already registered * Remove extra label in test * Remove unit test * Add backport changelog * Return warning if any client-only prop is defined Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: ryanwelcher <[email protected]> Co-authored-by: SantosGuillamot <[email protected]>
The manual cherry-pick has been merged: #66167. I've changed the label to "Backported". Please let me know if anything else is needed. |
* Remove bindings bootstrap functions * Remove bootstrap calls * Remove old filter * Adapt unit tests * Add compat filter in Gutenberg * Only run script if not already registered * Remove extra label in test * Remove unit test * Add backport changelog * Return warning if any client-only prop is defined Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: ryanwelcher <[email protected]>
What?
Fixes #66031
In this pull request, I'm proposing removing the existing way of bootstrapping the sources defined in the server and do it directly in core with an inline script.
Why?
In the current implementation, bootstrapping happens in
initializeEditor
, which happens after dom ready. This means that when a external source is registered in the server and in the client, the bootstrap happens too late, causing unexpected behaviors.How?
I removed the existing logic and added a filter to add an inline script registering the server sources. This will be replicated in core.
Testing Instructions
e2e should pass.
The issue reported here should be fixed.