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

Block Bindings: Should the bindings logic be moved to core functions instead of using a hook? #63014

Closed
SantosGuillamot opened this issue Jul 1, 2024 · 2 comments
Labels
[Feature] Block bindings Needs Decision Needs a decision to be actionable or relevant [Type] Question Questions about the design or development of the editor.

Comments

@SantosGuillamot
Copy link
Contributor

In this pull request, we started exploring the possibility of moving the logic to getBlockAttribues and updateBlockAttributes instead of using a hook in the Edit component.

However, after working on it, it feels we don't have enough knowledge to make a decision yet. It isn't clear when we should use the original value and when we should use the binding value.

I'm opening this to gather more information and use cases and foster the discussion.

Context

When a block attribute is connected to a source using bindings, the server will process the binding and replace the original value with the one returned by the source. For example, imagine I have a paragraph content with a "Default" value. If I connect it to a custom field, it will show the value of it, while "Default" will remain as a fallback (when the value returned by the source is undefined, for example).

With that in mind, when we want to return the "bindings" value instead of the "fallback" value. Depending on that, we might want to modify the core functions like getBlockAttributes or provide a new util to getBindingValue that can be used instead.

Use cases

I'll try to gather the different use cases we come up with to help make a more informed decision.

Use cases where we DO want the binding value in block attributes

  • Edit component attributes: We want to show the value of the binding in the editor UI, because it will show in the server.
  • Screen readers: As reported here, screen readers should announce the value of the binding, which is the one shown in the UI.
  • Plugins relying on the markup: As reported here, plugins rely on the markup to generate more HTML attributes. For that, they need to use the binding value.

Use cases where we DO NOT want the binding value in block attributes

  • Markup: We don't want to save the binding value because it could cause security problems.

As a side note:

Even if we decide to modify the core functions, there is still a technical challenge. It isn't clear how to access the block context from these functions. Block binding sources need to access the block context in order to process the value. For example, "Post meta" need to access the postId and the postType. However, accessing it from the store is tricky. We explored the possibility of syncing it with the store, but we aren't sure about that approach either.

@SantosGuillamot SantosGuillamot added [Type] Question Questions about the design or development of the editor. [Feature] Block bindings labels Jul 1, 2024
@gziolo gziolo added the Needs Decision Needs a decision to be actionable or relevant label Jul 27, 2024
@gziolo
Copy link
Member

gziolo commented Sep 20, 2024

@SantosGuillamot, should this issue get closed with a similar sentiment to your #61817 (comment)?

@SantosGuillamot
Copy link
Contributor Author

Yes, we can always reopen if considered again in the future.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block bindings Needs Decision Needs a decision to be actionable or relevant [Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

2 participants