Block Bindings: Support binding to `innerBlocks`

[talldan]

Note: this issue was originally written with the idea of supporting innerBlocks bindings for pattern overrides, but the scope has been broadened to all blocks. The description has been simplified.

What problem does this address?

Some opportunities that arise from supporting bindings to innerBlocks have already been mentioned in #41073.

For pattern overrides, this would also be a hugely beneficial feature. Users could create synced patterns that have free areas for adding content. For example, imagine patterns that have particular locked design elements mixed with free written content. Pattern creators could also control the blocks that are insertable into A user would be able to control the design across every usage of that pattern.

It'd also make it possible to replace the Post Content block with a group that has innerBlocks bindings. Patterns would start to become as powerful as templates, and perhaps there's some convergence of those concepts.

What is your proposed solution?

Previously block bindings have only supported binding attributes, but if bindings could also be configured for inner blocks, the above problems could be solved.

[fabiankaegy]

I really like the idea of this. Currently, we often have to build custom block wrappers that then have an open inner blocks area. Pattern Overrides in general still have the limitation, due to it's usage of contentOnly locking, of not even allowing the addition of new list items / buttons as described in: #52018

[talldan]

Pattern Overrides in general still have the limitation, due to it's usage of contentOnly locking, of not even allowing the addition of new list items / buttons as described in: #52018

Yep, I think this is one area that makes me hesitant at the same time. I think there could still be separate solutions for blocks like list/buttons, those containers that have one supported inner block type (gallery and social links are maybe others) and aren't really freeform.

I think this might be good so that contentOnly can still be leveraged (but with additional features like adding/removing list items). That would allow creators to do things like setting a list style that can't be modified, or maybe setting the min/max number of blocks.

I would be hesitant of too many solutions for this kind of thing, but at the same time I think a freeform area in synced patterns would be quite a powerful feature.

[carlomanf]

• Interestingly, I think it means patterns start encroaching on templates, the post content block works similarly to what's described above.

Over at #37753 a good point was made about "template tag" blocks being facsimiles of generic blocks (e.g. Post Title and Site Title being facsimiles of Heading) that would be better implemented as block bindings within the generic blocks. I guess the point quoted above is the same point regarding Post Content as a facsimile of Group.

Accordingly, the solution described here could enable post content data to be a block binding source for Group, and would be a better solution to #41073 which I would be happy to close in favour of this issue.

[youknowriad]

Great idea indeed. For me this means "inner blocks" support for block bindings. It's important that the implementation of such feature is not pattern overrides specific and would allow any block bindings source to inject blocks.

[eric-michel]

This is the holy grail of hybrid template / freeform editing and is something I've been dreaming of since the block editor was introduced. I agree with @youknowriad that making InnerBlocks support bindings is the way to go, which opens the door for many other block types to activate the same functionality (including custom blocks).

[talldan]

Another good use case for this will be nesting patterns. For example you could have a section that contains a header, images and an overridden grid/columns, and within the grid/columns you could nest card patterns. That allows for pretty cool composition of patterns.

[mtias]

With the ability to now express allowedBlocks directly in the markup this makes a lot of sense. I can see serializing these as nested elements. Curious if naming the group blocks is the only thing needed to now where to allocate these if you have more than one group block.

Side note, but we need to expose allowedBlocks in the Advanced UI of the group block as well, it's a super powerful feature. The UI can be similar to the block manager.

[talldan]

I've also been thinking on the idea of composing patterns. An example use case I have in my head is a pricing table pattern. It has a 'freeform' columns block, and by default there are a few columns, and each has a pricing-table-card pattern within it showing some placeholder content (name, features, pricing).

A challenge would be that when the user appends an additional column, the new column is going to be empty whereas I think it could be populated with the pricing-table-card pattern. The user could fuss around with finding that pattern in the inserter, or duplicate the column, but I think it'd be better for the appender to insert the right content or suggest the right content for the column by default.

This use case isn't limited to only pricing tables, it's illustrative, there are plenty of situations where a pattern designer would want users to insert consistent content into columns, grids and other types of lists.

Some kind of allowedPatterns or suggestedPatterns API might work, or perhaps even allow pattern slugs in allowedBlocks. It could also be an entire category of patterns that's allowed/suggested.

This might be a few steps ahead of where we are right now, but it's good to think about how these things can be configured.