Block Bindings: rely on broader context instead of requiring direct block context #60826
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: +92 B (0%) Total Size: 1.74 MB
ℹ️ View Unchanged
|
|
This PR is interesting, should we be doing the same for the backend as well? Or maybe it's already the case? |
| @@ -12,6 +12,7 @@ import { store as editorStore } from '../store'; | |||
| export default { | |||
| name: 'core/post-meta', | |||
| label: _x( 'Post Meta', 'block bindings source' ), | |||
| usesContext: [ 'postId', 'postType' ], | |||
There was a problem hiding this comment.
Where do we add these today (to block registration). I was expecting some code to be removed in this PR no?
There was a problem hiding this comment.
We add the context to the block type registration server side, so it will have to be removed there. I'm not sure if it's needed there or also added right in time. My understanding is that it can be adjusted too to not rely on the block type, cc @SantosGuillamot #58554 (comment)
There was a problem hiding this comment.
Right now, we are updating the uses_context when a source is registered: link. We did it that way to ensure the context was available in both the server and the editor, even when the binding was added afterward.
However, with this new approach, the editor side is solved, so I'd like to revisit it because that might not be necessary anymore.
There was a problem hiding this comment.
We need to do the same for backend sources. Fetch the actual global variable of the context or something like that. then we'd be able to remove the hook. It's too bad that it's not a "named hook" so we can't really unhook it from Gutenberg and we'd need to make the change on Core.
There was a problem hiding this comment.
I've been taking a look at the server part, and I believe we could add the following logic to the bindings processing here.
if ( ! empty( $block_binding_source->uses_context ) ) {
foreach ( $block_binding_source->uses_context as $context_name ) {
if ( array_key_exists( $context_name, $this->available_context ) ) {
$this->context[ $context_name ] = $this->available_context[ $context_name ];
}
}
}If we do that, we could get rid of the old method that changes uses_context when the source is registered.
I've tested it, and it seems to work fine. And it only adds the context to the blocks with bindings.
Is that what you had in mind?
There was a problem hiding this comment.
We considered both approaches in the WordPress 6.5 release cycle. We ended up going with the approach that exposes context for every block that might need it to work with the potentially established connections with block binding sources. It was a simpler approach as we didn't have to apply any changes on the client. The downside is that there is often context exposed even when it's not needed.
As before, I think the revised approach is also viable and presents different challenges. The biggest unknown exists on the server because the whole context for the current block gets computed in the constructor of the WP_Block:
It happens inside render_block, which is during the rendering phase, so that could have a positive impact on the block registration and editor's bootstrap. On the other hand, it's going to get processed for every individual block that gets rendered on the front end. The key question is if we can have a good strategy for getting the list of registered block sources and their expected context names.
There was a problem hiding this comment.
I've created a pull request with what I had in mind to change in core: WordPress/wordpress-develop#6456
The idea is to extend the context during the bindings processing by accessing the available_context. This way, the code only runs when the block has bindings and gets the needed context. The downside would be that it doesn't run in the editor, but that part is handled by this PR in Gutenberg.
I've tested it, and it seems to work.
There was a problem hiding this comment.
This is interesting. I haven't seen this idea before:
// Add the necessary context defined by the source.
if ( ! empty( $block_binding_source->uses_context ) ) {
foreach ( $block_binding_source->uses_context as $context_name ) {
if ( array_key_exists( $context_name, $this->available_context ) ) {
$this->context[ $context_name ] = $this->available_context[ $context_name ];
}
}
}So that would only happen for existing block binding connections locally just before the moment the final values gets computer. That seems very performant.
There was a problem hiding this comment.
I tried to replicate what this PR does in the server and it's the closest thing I could think of. I also agree that it seems much more performant than the previous implementation.
There was a problem hiding this comment.
The more I think about it, the more I like it. Great teamwork with the proposed refactoring. It seems like it should be considered as progressive enhancement since the useContext is correctly set on block types on the server in WP 6.5, so any changes applied in the Gutenberg plugin won't change much which is great. In WP 6.6, when the block types aren't fed with the same useContext from the block binding sources all the time no matter if the context is consumed, then we will seamlessly move that handling to the WP_Block class. We might not even need to change anything in the back compat layer in the Gutenberg plugin.
| for ( const key of source.usesContext ) { | ||
| context[ key ] = blockContext[ key ]; | ||
| } | ||
| } |
There was a problem hiding this comment.
Worth noting that we do the exact same for blocks basically:
gutenberg/packages/block-editor/src/components/block-edit/edit.js
Lines 56 to 64 in f5ee54f
SantosGuillamot
force-pushed
the
try/block-binding-remove-block-context
branch
from
0d34203
to
800c96b
Compare
There was a problem hiding this comment.
This PR looks good to me 🙂
As discussed here, it only handles the context in the editor. It should be complemented with this other pull request in core that does the same in the server. Until that PR gets merged, everything will keep working with the downside that we extend the context whenever a source is registered, making it accessible even when the block is not using bindings.
There was a problem hiding this comment.
Good job figuring out and convincing for an alternative approach regarding the handling for the additional block context coming as a requirement from Block Binding source. More on that in #60826 (comment).
One remaining open question - not a blocker for this PR - is how we share use_context to the client so we don't have to repeat the definition it when registering handlers on the client. Basically, I'm talking about the line that @youknowriad points in https://github.com/WordPress/gutenberg/pull/60826/files#r1569275101.
What?
This PR removes the need for bound block to have the context that a binding needs. Instead we can look at the broader context. I've opted to require a binding source to declare the context it needs, just to avoid passing all context down to the callbacks (not absolutely required though). This is very similar to how a block needs to declare what context it needs.
Why?
Block bindings shouldn't have to affect the block registration, instead we can add the right context just in time.
I could see Bits work similarly: it can declare what context it needs without requiring the parent block to consume the context as well.
How?
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast