Support initially hidden inner blocks

[DAreRodz]

This PR adds support for hidden inner blocks.

It duplicates <InnerBlocks> inside a <template> tag next to the block component. During component hydration, the <template> tag is emptied.

[luisherranz]

Exciting! 😄

Any ideas to avoid sending duplicate HTML? We'd need to detect if a block has inner blocks, but they are not in the output. I'm not sure we can solve it here, though. But it'd be nice to start discussing the approach.

Astro does it in the compiler. My initial guess is that we would need to do it inside the serializer, checking if the rendered block contains <gutenberg-inner-blocks> after we render the markup of the save component.

By the way, I've just added you as a contributor.

[luisherranz]

The Code Editor is crashing:

Screen.Capture.on.2022-05-04.at.18-16-09.mov

This is the saved content:

<!-- wp:luisherranz/block-hydration-experiments -->
<gutenberg-interactive-block ...>
  <div class="wp-block-luisherranz-block-hydration-experiments">
    <h2 class="title">Block title</h2>
    <button>Show</button><button>0</button>
  </div>
  <template class="gutenberg-inner-blocks"
    ><!-- wp:paragraph -->
    <p>This is an inner paragraph</p>
    <!-- /wp:paragraph --></template
  ></gutenberg-interactive-block
>
<!-- /wp:luisherranz/block-hydration-experiments -->

It looks fine to me. I'm not sure if this is a Gutenberg bug because one hook is crashing and React is complaining that the order of hooks is wrong.

[luisherranz]

I talked too soon. This is also happening in the main branch.

[DAreRodz]

I also experienced some problems, but I assumed they came from different block renders after modifying the component. 🤔

[luisherranz]

I've debugged it, and it's because of the throw of useBlockEnvironment.

I'll open an issue to inform, but I don't think we need to fix that because it'll never make it to Gutenberg.

So, any ideas to avoid sending duplicate HTML? 🙂

EDIT: Issue opened #9

[DAreRodz]

I don't have any ideas yet, haha. 😄 I'm trying using the blocks.getSaveElement filter, defined here, but it's not working yet.

[DAreRodz]

There are some docs for that filter as well. 👀

A filter that applies to the result of a block’s save function. This filter is used to replace or extend the element, for example using wp.element.cloneElement to modify the element’s props or replace its children, or returning an entirely new element.

The filter’s callback receives an element, a block type definition object and the block attributes as arguments. It should return an element.

One weird thing I saw is that when you return just the same element you receive in that filter, inner blocks simply disappear. They are not rendered and saved anymore. 🤷

EDIT: Okay, that's actually not true. I'll take a deeper look because I experienced that previously.

[luisherranz]

This is something we shouldn't solve using filters if we ever add this to Gutenberg, so maybe it's not worth trying to solve it here David. It's good to know that <template> can be used to populate children in the frontend and it works fine in the editor as well.

I'll merge this as it is and we can solve the duplication later 🙂

[michalczaplinski]

@DAreRodz Why do we need to render this empty template here? If I comment it out, it seems that I can still render initially hidden inner blocks. 🤔

[DAreRodz]

It's simply to avoid a hydration warning. 😄

[michalczaplinski]

oh duh, thanks :)