[wp-trac] [WordPress Trac] #63740: Block Bindings: Allow blocks to declare attributes as bindable

[WordPress Trac]

#63740: Block Bindings: Allow blocks to declare attributes as bindable
-----------------------------+-----------------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  General          |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 There's currently a hard-wired list of blocks and attributes that can be
 used with Block Bindings (i.e. bound to a Block Bindings source). That
 list is defined [https://github.com/WordPress/wordpress-
 develop/blob/7be47cfb4f1b01af3cf6317a2a512f1722031715/src/wp-includes
 /class-wp-block.php#L283-L288 here] for the server side, and
 [https://github.com/WordPress/gutenberg/blob/491d0ac0334352eda456d285415b331eb2072856/packages
 /block-editor/src/utils/block-bindings.js#L14-L19 here] for the client
 side.

 There is currently no way for a third-party block to have itself and any
 of its attributes added to that list. It's even impossible for additional
 Core blocks -- developed inside the Gutenberg plugin -- to add themselves
 to that list on the server side, as there's no extensibility mechanism.
 Instead, if a Core block wants to mark one of its attributes as bindable,
 it has to provide a fallback mechanism to manually set the attribute to
 the value provided by the Block Bindings source, as seen e.g.
 [https://github.com/WordPress/gutenberg/pull/70585/files#diff-
 599951e5a5c3cf5383ba5ebdd009140b51c0c42bff0af304de81001374a245a1R31-R39
 here].

 This impedes development and adoption of Block Bindings-compatible blocks.
 To solve this problem, there should be an extensibility mechanism that
 allows to add block attributes to the aforementioned list(s). One obvious
 solution would be to make the list filterable. However, it's arguable that
 it should be possible that a block simply declares any number of its
 attributes as bindable upon block registration; after all, it should be up
 to the block to decide.

 This could be done at `block.json` level, inside the block attributes
 definition. One option would be to add a boolean property (e.g.
 `bindable`) to each attribute (with a `false` default); or, as was pointed
 out to me by @santosguillamot and @cbravobernal, by using the existing
 `role` property: If its value is `content`, then assume that the attribute
 is bindable.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63740>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform