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

[SantosGuillamot]

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.