[wp-trac] [WordPress Trac] #60282: Add the Block Bindings API, including the "post_meta" and "pattern" sources

[WordPress Trac]

#60282: Add the Block Bindings API, including the "post_meta" and "pattern" sources
--------------------------------------+---------------------
 Reporter:  czapla                    |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  6.5
Component:  Editor                    |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by andraganescu):

 This is a bit late in the game but I wanted to start this discussion
 better late than never:

 **Problem:** on the server there are many ways to retrieve the data you
 need for a block. This leads to various code spaghetti in block rendering
 callbacks which then later hamper block API advancements.

 ----


 **Case in point:** server side previews and pattern overrides are both
 stuck at showing placeholders for empty image blocks. Another block, the
 cover block, decides in its rendering function that a cover block
 displaying a featured image means it has an empty URL. Pretty arbitrary.
 The same goes for the featured image block which is a post showing an
 image but has no URL attribute defined.

 **Case in point:** block hooks need to add feature specific code to block
 rendering callbacks to hook into the data these blocks fetch from their
 associated entities. The way to retrieve data if the block has controlled
 inner blocks is a free for all.

 ----


 **Solution:**

 > use the incoming power features of
 > block hooks and block bindings
 > to solve this problem.


 ''How?'' By nudging block developers - including core contributors - to
 use standard methods to access required data:

 - make block bindings only update attribute values from sources and leave
 the rendering to the block rendering callback. That means let’s not do
 [https://github.com/WordPress/wordpress-develop/pull/5888/files#diff-
 c569b1ecb11a007a563788a481710b51e0cb21cd1d1885490bf9c91777842f23R297 this
 part] and instead offer a helper function for replacing markup in static
 blocks from HTML sourced attributes.


 - If a block does not use exclusively attributes to represent the data
 they render they’ll have problems with binding, because the binding will
 not happen as a last action indifferent of the render callback’s soup.


 - make block hooks filter a function like get_controlled_inner_blocks
 which the block render callback uses to get data associated with it (like
 the navigation block gets its navigation from a wp_navigation post).
 Instead of PRs like
 [https://github.com/WordPress/gutenberg/pull/57754#issuecomment-1914846569
 this one] add a singe server side way to retrieve data from entities that
 hold controlled inner blocks and filter that. (cc @bernhard-reiter for
 awarenes.)


 - If a block does not get its controlled inner blocks via this function,
 block hooks won’t work.

 **Trade Offs:**

 - block hooks and block bindings lose some of their auto-magic
 awesomeness.
 - authors will have to opt in via updating their blocks to fit the
 paradigm described above.

 **Wins:**

 - Data flow direction is always predictable - if I filter attributes
 before rendering the effect will be visible in the render.
 - Extension is more predictable - associations between blocks and their
 entities are expressed in code via using one extensible method of data
 retrieval.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60282#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform