[wp-trac] [WordPress Trac] #64505: REST API: Block renderer passes incomplete block shape

[WordPress Trac]

#64505: REST API: Block renderer passes incomplete block shape
--------------------------+--------------------------
 Reporter:  dlh           |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.0
Component:  REST API      |     Version:  5.4
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------

Comment (by dmsnell):

 Alas,
 [https://github.com/WordPress/gutenberg/pull/48693#issuecomment-1452331194
 I strongly urged us not to separate the `WP_Block_Parser_Block` class out
 of the parser] because I knew it would lead to fragility and that being in
 a separate class would communicate the wrong thing. we should probably
 mark that `@private`.

 so I would suggest instead of using it that we //either// just add the
 missing property //or// propose a utility function whose purpose is
 specifically to create a block node. this could be something as basic as
 `wp_create_block( $blockType, $attrs, ...$innerContent )` and could be
 used directly.

 it makes me nervous to learn that we’ve added this class as the type of
 the block node and I think it would help us all if we separate a parser
 internal from the specified block node representation. one could argue
 that this is a philosophical point rather than a pragmatic one, but it
 will feel that way until the day we realize we accidentally coupled
 internal parser intrinsics with a funny name into one of our core and
 fundamental building blocks and we can’t escape and have to live with the
 awkwardness forever, and can never improve our parser unless we create
 `WP_Block_Parser_Real_Parser_Block` or `WP_Block_Parser_New_Block`, or
 `WP_Block_Parser_New_New_Block` as these things go.

 > an array representation simulating the output of parse_blocks

 I’d like to clear up the use of simulation here. block’s don’t really
 exist in the HTML, and the array form in PHP is the quintessential block
 type. we’ve explored creating an actual class representing this, and I
 think that would be great. the type would be best described as a
 `WP_Block_Node` to match the language in Gutenberg. a “block” is truly
 only complete in memory when linked to the block’s implementation; in PHP
 that implementation is `WP_Block`.

 but the array is the real thing. the HTML is the serialized form of it and
 therefore more of a simulation than what we are discussing in this issue.

 ----

 Thank you for bringing up this issue, it has highlighted to me that we
 should go back and make these parser classes more scary, private, and
 possibly even `@ignore` to strip them out of the documentation. They
 should probably also be final, and have scarier names, but they were never
 meant to see the light of day so the name was perhaps a little more
 relaxed than it should have been.

 You all are wonderful; and really it’s great to embrace standard types
 with built-in documentation. In this particular case though I think it is
 a ticking time bomb to use //this particular class/. I can propose a
 `WP_Block_Node` class before the week’s end if you would like that.

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