[wp-trac] [WordPress Trac] #49442: Request: filter for parse_blocks() result

[WordPress Trac]

#49442: Request: filter for parse_blocks() result
---------------------------------------+---------------------
 Reporter:  dougwollison               |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  6.9
Component:  General                    |     Version:  5.0
 Severity:  normal                     |  Resolution:
 Keywords:  has-patch needs-test-info  |     Focuses:
---------------------------------------+---------------------

Comment (by justlevine):

 @dmsnell thanks so much for the feedback!

 Things are a bit hectic in my part of the world ATM so I want to reply and
 mind dump while I can to keep the conversation (finally 🥳) going. I'll be
 back to backfill the rest as soon as possible:

 > if we’re adding the filter, the current proposed docblock is under-
 helpful.

 100-thousand percent, although that really needs to come from improvements
 to WP_Block_Parser::parse(), which might be beyond the scope or might be
 enough for us to infer from pre_render_block hook 🤔. I'll dive back here
 when I can if nobody beats me to it.

 ----

 > This is the trouble in exposing the filter here: it takes thoughtful
 intention to traverse the output properly, something not required when
 using pre_render_block, render_block, render_block_data, and
 render_block_context filters.
 > [...] One more-recent development is the introduction of
 traverse_and_serialize_blocks(), which gives more direct control over the
 block tree as a filter.

 First I wanna take a quick second to talk semantics, and possibly fix an
 XY problem I inadvertently created by using caching as a test case (and
 sharing over on #45471) - apologies 😅

 - From within the function: the `parse_blocks()` function extracts data
 from a string using a specific Parser class.
 - From the function's implementation: the `parse_blocks()` function
 prepares saved block data that has been stored as a string for use -
 usually, but not always, before rendering.

 It's the latter that's the primary concern, even if borne out from DX
 issues extending WP_Block_Parser (demonstration pending 🙇). It's also why
 (to my understanding) `traverse_and_serialize_blocks()` doesn't help here,
 because it's even _more removed_ from the parse/render knot I'm hoping to
 decouple.

 <mind_dump>

 So with that in mind, by adding this's filter we're essentially proposing
 :

 1. tweaking the hook lifecycle so it's `parse_blocks` => foreach {
 `pre_render_block` -> `render_block` -> `render_block_data` ->
 `render_block_context`. (Assuming the doc-block gives some better context
 on the array shape), I don't think requires any more "thoughtful
 intention" than the current lifecycle, even if the existing project tech
 debt unfortunately forces it to act on the `array<TRenderBlockArgs>`,
 instead of the array of `$args` for a single block.
 2. Allowing for the possibility that current GB/3rd-party code that
 currently needs to:
   - use `render_block` or `render_block_data` to parse and hydrate block
 data (because they rly use *_Block_Parser* ).
   - entirely render a block to have its data be fully parsed, (and as a
 consequence, feel the need to rely on weird caching solutions to make
 getting the block data more performant.).

 Tl;dr: we need to separate the ''act'' of rendering blocks from the act of
 hydrating block-data from parsable-strings, and this is the easiest way to
 incrementally start doing that, is back+forward-compat and has a small
 enough footprint + offers immediate value, and therefore stands a
 semblance of a chance of making it into core (any other attempt to improve
 separation of concerns here will IMO either affect lifecycle or need a
 muuch bigger footprint on the codebase)

 </mind_dump>

 ----

 > @justlevine do you mind making some of these observations concrete? What
 is the over-reliance you are referring to? What are the headaches?

 This [prob the most important part] I need to come back to when I'm back
 at my desk, since it involves real code snippets and references. Promise
 to fill this in as soon as possible - but please people continue to chime
 in without me.

 <mind_dump>
 Basically I owe:

 - [ ] List of `add_filter( 'render_block_data'*` GB plugin -> core items
 that avoided WP_Block_Parser_*, as well as those that more generally are
 about parsing, not rendering vs places in the codebase we use
 `parse_blocks()` and ideally want access to that.
 - [ ] Pick a popular `extends WP_Block_Parser` and show what's required as
 a plugin to safely add your custom block attribute to support it + core
 blocks.
 - [ ] Point uses of the `render_block()` to safely get all the block data
 + performance smells / related tickets.
   - 3rd-party from headless theres the WPGraphQL + WP-Rest plugins +
 WooComm's new checkout. IIRC there were some REST APIs headed to
 core/gutenberg too that (as proposed) have no choice but to needlessly
 render too.
 - [ ] and then just grep a list of those abusing `add_filter(
 'pre_render_block', *` showing how devs currently work around this.
 </mind_dump>

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