Template part vs block pattern, establishing best practices

[carolinan]

This is not indented as criticism.

I think it would be a good idea to have a discussion about best practices when it comes to deciding if something should
be a template part or a block pattern (like how the community has discussed the naming of colors and font sizes).

Currently many parts in the theme are patterns.
But it is actually more difficult -and a much larger number of clicks- for a user to replace existing content in a header or footer with a pattern than it is to use the replace functionality that is available in the template part*.
Because with patterns, the user has to select and delete all the existing content, then add a new pattern via the block inserter.
-And they need to do this on every page, and it means they can't take advantage of making changes to all headers or footers at once.

It makes sense to have patterns ready for sharing in the pattern directory.
-But it also makes sense to turn header and footer patterns into template parts, because they are designed to be used in the header and footer template areas.

*Assuming this bug will be fixed.

[tinjure20]

An ordinary user's (aspiring developer) perspective here. I couldn't agree more with @carolinan. I have been making my hands-dirty with Block themes for a while - customizing Quadrat theme for my personal rambling site project.

The other day, I was trying to set up my own twenty twenty-two test site similar to this demo site. I had a hard time selecting header-large-dark pattern and adding the bird image there. Only after watching this video, I got my "Aha!" moment and was able to change the header. I had to do for every page template as described by @carolinan . Without a visual or very detailed guide, I too suspect many WP users would be able to reproduce the demo site on their own sites.

[ellenbauer]

That is an important point Caroline makes and I wonder how we should approach this in block themes in general. I also feel there is a confusion between patterns and Template Parts right now.

[kjellr]

My expectation has been that someday if you were to hit "replace" for a template part, Gutenberg would load both patterns and template parts to choose from. At some point, there was some drive in Gutenberg to expand the "contextual pattern transforms" that were added to a few blocks (see the notes in WordPress/gutenberg#30925 (comment)). This seems to have stalled out though, so as you note, it's basically impossible to switch your existing header template part to use a different pattern.

(Also: We can start discussing this here, but I think the issue so heavily relies on the UI for switching sections out, this discussion will likely have more impact over in Gutenberg).

[overclokk]

What I seeing developing an experimental child theme is that template files should be as few as possible and use patterns to add more variations of the theme design, this is primarly because I see the templates as static files (and they are, yes) default for basic design and pattarn more dynamic elements whre you can also generate variation by PHP loop.

[carolinan]

The pattern would need to be placed inside the template part, not replace it. That is difficult to do manually since you have to know which blocks to select and remove, and you have to know the concept of "parent block" "container block".
Otherwise we would still have the problem that if you change the content, it is only changed in one place, compared to if you change the content of the template part, it is changed on every page where the template part is used.

[carolinan]

@jameskoster Do you know if updating this flow is planned for 5.9?
I see that related issues were removed from 5.8 milestone, but then most of them has had no action since.
Is there an overview issue for this flow?

[kjellr]

To illustrate some of the confusion here: If I wanted to add a "header" to this page, which of these blocks do I choose?

Today's answer:

• The first one is the right choice only if I want to choose from patterns, or start blank with a brand new header.
• The second one is the right choice only if I want to choose an existing header.

Most users won't know to anticipate the difference. 😅

[carolinan]

Neither, because there is already a header in place when you open the editors... 😁

[overclokk]

@carolinan but if the header (or other parts) does not exist?

[carolinan]

When you are in the block editor and select new template, that default includes a header.
If your theme goes as far as changing the default, well then I'd say you as theme author will need to leave instructions.

[jameskoster]

@jameskoster Do you know if updating this flow is planned for 5.9?

Which flow? "Replacing" a template part quickly with a pattern? I don't think it's planned for 5.9 but I agree it needs attention. While working on this we also need to consider literal template part swapping (IE swapping "Header A" for "Header B"). They're conceptually similar, but technically quite different.

To illustrate some of the confusion here: If I wanted to add a "header" to this page, which of these blocks do I choose?

Imo these base-level "Template part" blocks should probably not be exposed in the Inserter(s). It's a really poor flow that assumes way too much technical knowledge. We should instead expose the template parts themselves.

[carolinan]

Both -Because as it is now a block theme is almost unusable. Can it really wait til later?

[carolinan]

literal template part swapping (IE swapping "Header A" for "Header B")
This sort of works except as above, you also have to make a change to the template for the change to save.

[carolinan]

I did a quick test and when the template parts are assigned to the header and footer area in theme.json as in #122 Then the template parts show up under "choose existing" when I type /header but there is no preview of the template part when I add a header from the inserter.

[jameskoster]

I think it would be a good idea to have a discussion about best practices when it comes to deciding if something should
be a template part or a block pattern

Focussing on this topic, I think template mechanics can be used to help themers decide what to use. That is to say: if you're bundling a template that demands a certain header style/composition – that must be a discrete template part. But if you just want to offer alternative header options for use in any template, they should be patterns.

For the latter use case, users should be able to quickly view and select contextual patterns when editing something like a Header. I agree that this is a lacklustre UX currently, but I wouldn't say that it makes block themes unusable.

I did a quick test and when the template parts are assigned to the header and footer area in theme.json as in #122 Then the template parts show up under "choose existing" when I type /header but there is no preview of the template part when I add a header from the inserter.

For this flow I think it makes most sense to simply display the template parts in the inserter: WordPress/gutenberg#31748 That way we would (hopefully) get previews for free.

[carolinan]

But how do users get from
This theme has a header, I like this pattern better so I will delete the current blocks and insert the pattern from the inserter
to
This theme has a header, I like this pattern better, I have added it and made changes to the color and navigation block, and the header on all my existing content was updated. The next content I create will use this new header automatically.

[jameskoster]

So you are asking how a user would transform a pattern they inserted outside of a template part, in to a template part? That seems like a bit of an edge case... isn't it more likely that the user would simply edit the existing header?

In any case, block(s) can be made in to a template part via the ellipsis menu in the toolbar:

[carolinan]

My concern is that it is not an edge case because selecting the correct block, (header) deleting the correct inner blocks, and replacing them inside that block, is not so easy.
How will they know they should not delete the entire header?

If you need to turn something in to a template part, isn't it easier if it already is a template part from the beginning.

[carolinan]

I've not explored this, what about locking the header and footer? Would that keep the template part in place but allow editing the content?

[jameskoster]

If you need to turn something in to a template part, isn't it easier if it already is a template part from the beginning.

Possibly :) There's nothing to stop a theme providing many header template parts, and many header patterns if it wants to. This is a complex problem with many blurred lines. It may not even be possible to determine a single best practise.

Ultimately we need to make both flows intuitive in the template editor:

1. Swap existing Header A for existing Header B
2. Quickly browse and try different header patterns (supplied either by the theme or the pattern directory) in either Header A or Header B.

From there it's up to theme authors how they want to supply the different options. Yesterday I concluded that using template mechanics as a rule of thumb would work because it could help decrease potential bloat, and perhaps foster community involvement in the pattern directory.

But perhaps it would be better for themes to supply the options as template parts regardless, and leave patterns to the directory? That may make sense if we think of the first flow as switching between two installed themes, and the second flow like live previewing a new theme altogether. Perhaps that is a distinction that would resonate?

How will they know they should not delete the entire header?

If we get the second flow right, folks should be less inclined to delete the header entirely. But it's worth noting that this scenario is not a disaster... you can insert a pattern directly in to the template and it will work just the same. Template parts are helpful tools that enable us to reuse the same block compositions across multiple templates... but they aren't strictly required.

[elbsegler63]

#189 (comment)

[kjellr]

Now that we're nearing release, I'm going to close this issue. If anyone has further thoughts to share on this topic, feel free to open up a new issue on Trac or in the Gutenberg repository.