michalczaplinski
commented
7 months ago Hi @draganescu! 👋 Thanks for opening this discussion!
I must say that I'm not quite following here what the specific problem is. Could you articulate it in a different way with some examples?
server side previews and pattern overrides are both stuck at showing placeholders for empty image blocks.
I don't understand what you mean here. What should an empty image block render other than a placeholder?
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.
I've read it a few times but I still don't understand 🙁 . What do you mean by "last action indifferent of the render callback’s soup"?
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.
Please correct me if I misunderstood. You're suggesting removing the replace_html() function from its current place and leaving the responsibility of rendering a blocks with updated attribute values (the values coming from a block binding source) to that block itself. Specifically, the block would have to use some helper to update the static block's HTML.
The problem I see with this approach is that whenever a value coming from a source changes, the value in the static block would not be updated automatically. The user would have to e.g. re-save the post. How do you think this could be overcome?
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:
''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 @ockham for awarenes.)
If a block does not get its controlled inner blocks via this function, block hooks won’t work.
Trade Offs:
Wins: