WordPress.org
Get WordPress

Make WordPress Core

Changes between Initial Version and Version 1 of Ticket #60282, comment 20


Ignore:
Timestamp:
01/31/2024 04:27:18 PM (3 years ago)
Author:
andraganescu

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #60282, comment 20

    initial v1  
    1 This is a bit late in the game but I wanted to start this discussion better late than never:
    2 
    3 **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.
    4 
    5 ----
    6 
    7 
    8 **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.
    9 
    10 **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.
    11 
    12 ----
    13 
    14 
    15 **Solution:**
    16 
    17 > use the incoming power features of
    18 > block hooks and block bindings
    19 > to solve this problem.
    20 
    21 
    22 ''How?'' By nudging block developers - including core contributors - to use standard methods to access required data:
    23 
    24 - 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.
    25 
    26 
    27 - 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.
    28 
    29 
    30 - 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.)
    31 
    32 
    33 - If a block does not get its controlled inner blocks via this function, block hooks won’t work.
    34 
    35 **Trade Offs:**
    36 
    37 - block hooks and block bindings lose some of their auto-magic awesomeness.
    38 - authors will have to opt in via updating their blocks to fit the paradigm described above.
    39 
    40 **Wins:**
    41 
    42 - Data flow direction is always predictable - if I filter attributes before rendering the effect will be visible in the render.
    43 - Extension is more predictable - associations between blocks and their entities are expressed in code via using one extensible method of data retrieval.
    44 
     1I opened an issue on Github about [https://github.com/WordPress/gutenberg/issues/58510 Standardizing data access for blocks on the server] in place of my previous comment.
     2