Query Loop Block: develop a content-only representation

[annezazu]

Similar to #65699, we need to think about the experience of interacting with the Query Loop block when in Write mode/content only. As it stands right now, the experience is quite confusing as the only items you can edit or change when viewing a homepage aren't items most will need to change. For example, here's a video showing how in Write mode, the only piece you can edit is the no results message:

no.results.found.query.loop.content.only.mov

When testing this with loved ones (I can ask for permission to share some of the video), repeatedly folks would edit this text as it was the only thing offered to them to edit in much of the homepage! Similar to the navigation block, we need to find a way to open up some controls and options while also clarifying the current limitations to know when to switch into Design mode.

[richtabor]

What about surfacing alternate designs, like here: #63497, so you can essentially swap out blog designs. We already have "Replace" in the toolbar.

[jasmussen]

I like that, and it pairs well with the fact that the loop placeholder block also allows you to pick from those options.

[richtabor]

Let's try that to start, before surfacing additional controls in write mode.

[ramonjd]

Let's try that to start, before surfacing additional controls in write mode.

I started a WIP PR for #63497 over at #66993

[ramonjd]

I attached this issue to the audit tracking issue:

• Audit blocks for writing and contentOnly modes #65778

[annezazu]

Happy to open this as a separate issues if we need it but I wanted to note that it's also really frustrating right now where if you swap between certain patterns in the query loop block, you suddenly can't see the "replace" option in the toolbar:

no.longer.can.replace.patterns.mov

This is using TT5 with GB 19.8.

[ramonjd]

if you swap between certain patterns in the query loop block, you suddenly can't see the "replace" option in the toolbar:

🤔 It looks like the query loops is being replaced by a pattern with no content blocks (??)

So selecting the pattern is only selecting its container block. If you enter Design mode again, the query loop is inside the pattern.

But when I add a group block with a query block inside it's also not accessible.

Kapture.2024-12-10.at.13.22.49.mp4

Does this mean query loops should always be accessible in write mode for the purposes of changing their designs?

[ramonjd]

But when I add a group block with a query block inside it's also not accessible.

@talldan just pointed out to me the significance of the main section, which, according to the editor is the first container block (usually group) that has a tagName of main.

The query block will only be shown as a child in Write mode when its inside a main section AND that main section is the first one in the tree.

Kapture.2024-12-10.at.16.19.52.mp4

Whether this is a useful constraint/intuitive design pattern is another discussion 😄

[ramonjd]

I've been looking at this one today, and have been hacking about.

I found that if I gave the Query Block "query" attribute a role of "content" in block.json, the block will show in the list view, and therefore the block toolbar works.

Let's ignore for a bit whether this is right or not 😄

The Change Design button won't show on nested Query Blocks, as it is considered the child of a section. The selector won't return any patterns.

Here's the call stack in the block editor selectors file:

getPatternsByBlockTypes()
__experimentalGetAllowedPatterns()
canInsertBlockType()
canInsertBlockTypeUnmemoized()
isSectionBlock()

So for query blocks, the easiest way to get patterns all the time is to pretend that query block has no parents, and therefore is not nested in a pattern.

This means calling getPatternsByBlockTypes() with no rootClientId. I don't know if there are any side-effects - the patterns appear the same all the time regardless of the rootClientId. It could be further refined by only passing a rootClientId when blockEditingMode !== 'contentOnly'.

Kapture.2024-12-19.at.15.20.35.mp4

There are some other inconsistencies, such as the drag dots and the context menu. Should these be there are at all I wonder? In my mind, dragging/copying/duplicating/deleting is design functionality.

[ramonjd]

Let's ignore for a bit whether this is right or not

I was chatting with @talldan and one approach is to create a flag in the block metadata, e.g., contentParent: true for cases such as this. It might benefit the nav block too.

[ntsekouras]

This means calling getPatternsByBlockTypes() with no rootClientId. I don't know if there are any side-effects - the patterns appear the same all the time regardless of the rootClientId

rootClientId affects the returned patterns by checking for blocks that are not allowed to be inserted. So you probably don't see any side effects because you allow all blocks.

I was chatting with @talldan and one approach is to create a flag in the block metadata, e.g., contentParent: true for cases such as this. It might benefit the nav block too.

In general I also believe a prop in Blocks API would be better than trying to add role:content to random attributes. Not necessarily something like contentParent though, because that would help some cases like the toolbar etc of that block, but doesn't help other blocks like Site Title.

Having said that, the hard thing about trying to figure out how all blocks should behave in write/design mode is that the current mechanism relies on role: content and this was introduced for an entirely different reason (transform patterns). I haven't figured out an alternative solution, but it feels like we should also try to find a way to have our modes with a new mechanism..

[talldan]

Not necessarily something like contentParent though, because that would help some cases like the toolbar etc of that block, but doesn't help other blocks like Site Title.

The naming might not be perfect. I think we need to try something and see how it works. I was mostly thinking about how it applies to the navigation block. That's what led me to thinking about contentParent.

Site Title / Tagline / Logo etc are a problem. #67372 does make Title and Logo work via role: content, but Tagline is still an issue.

There was a suggestion on that PR to make Template Parts work exactly like Synced Patterns where all the content is locked (even blocks with role: content) and only blocks with bindings/pattern overrides are editable. If we do that, role: content isn't enough and something extra is still needed (I tried it in #68042).

[ramonjd]

If we do that, role: content isn't enough and something extra is still needed

I won't pretend I have all the issues covered, but on that specific point: forgetting about what the prop is called for a moment, it could be an object for more flexibility in describing its behaviour.

Plus, if it's private and not part of the block.json schema it gives some breathing room to test and iterate.

[ramonjd]

Exploratory PR over here for discussion purposes:

• Try: add content flag to blocks with no content attributes #68162