Synced Pattern Override for nested patterns

[ziomoiz]

What problem does this address?

I create a Synced Pattern consisting (for example) of Heading and Paragraph - both with an override capability:

Next I want to create a Synced Pattern composed of three of the previously created patterns:

The goal is to allow for text content changes while maintaining consistency in spacing between blocks, padding, etc.
Problem is, that currently the original Synced Patterns loses its override capability when nested in a new collective Synced Pattern.

What is your proposed solution?

Possibility to enable override functionality for nested patterns would be a great extension of the Synced Pattern Overrides feature, significantly simplifying the creation of consistent layouts across the entire site.
Currently, this must be worked around using unsynchronized patterns, which introduces the risk of inconsistencies and mistakes.

[talldan]

There's some background to this in #58541 and the related issue #58291.

I think everyone discussing it there agreed that it'd be a powerful feature to nest patterns in this way, but it introduces some considerable complexity (both in the gutenberg codebase and in terms of the UI for users) and raises a lot of questions.

One of the biggest question marks is how editing the 'original' pattern works when you have nested child patterns. There are three options that I can think of:

1. How it works currently, you can only set overrides when working with an instance of a child pattern directly whether nested in another pattern or not. If you nest a child pattern, from the outer pattern the child is locked. It's worth considering that sometimes this might be what users want.
2. When you 'Edit original' of a parent pattern, any child pattern original content is also then editable. This would mean that child pattern instances suddenly work differently in the context of editing a parent pattern, which might be quite confusing for users.
3. Patterns can be nested, and overrides are editable at every level. This means that when you insert a pattern that has child patterns within it (that have overrides), those overrides are editable from that instance. Also when you 'Edit original' of that parent pattern, the overrides of the child patterns would have to be editable there too (otherwise it creates a big inconsistency with how overrides work). It perhaps makes sense, as this allows customization of the placeholder values. It implies some kind of cascade of overrides, which could be quite a thing to manage, both for a user and in the code! It's especially complex when you have multiple nesting levels. It's also worth considering the performance implications.

In terms of data management, the override values for inner blocks are stored in the attribute value of the pattern block, with the block names used as keys to identify the block that the attributes belong to. When there are child patterns with overrides, the values would have to bubble up to the parent. If you have more than one instance of the same type of pattern as a child, the names would collide, so there would need to be a way to namespace the child patterns (e.g. also giving them a name and perhaps marking the pattern as an override itself).

Anyway, that helps explain the complexities, and why in the initial version overrides work the way they do.

In #61225 there's some discussion about a different way to compose patterns, particularly in the comment #61225 (comment).

[ziomoiz]

Thank you for the thorough explanation.

I'm not advanced in coding, so I can't propose a technical solution. However, in terms of logic and functionality, I thought of an analogy with the structure and behavior of Components and its instances (maybe even Variants) in Figma:

https://help.figma.com/hc/en-us/articles/360039150733-Apply-overrides-to-instances
https://help.figma.com/hc/en-us/articles/360056440594-Create-and-use-variants

Perhaps in the first phase of developing Synced Pattern Overrides, it could be made possible to at least edit text content (title for Image, content for Heading and Paragraph, text and link options for Button)?
It's far from a complete solution, but I feel that this would be a significant convenience for most use cases.