Query Loop block: Consider click to edit treatment

[annezazu]

What problem does this address?

This is feedback from the nineteenth call for testing for the FSE Outreach Program:

There is no easy way to select the Query Loop without going to the List View, as any attempt to select an element on that block selects the Column ‘level’ or deeper.

Here's a quick video with GB 14.9 to demonstrate how you both can select the query loop block but also easily miss it:

query.loop.selection.mov

What is your proposed solution?

I am torn here as I both like the experience as it is and could see where, upon emphasizing patterns more, we might want to consider a "click to edit" treatment so folks can replace/swap patterns with more ease. What about if a site has patterns turned off? Do we want to push folks into the complexity of the query loop block outright? I also have repeatedly seen feedback about it being annoying to double click the navigation block to access it due to this same "click to edit" treatment. In that case, it makes sense to me since we do need an easy way for folks to select a header.

Curious what @WordPress/gutenberg-design thinks :)

[jameskoster]

There is no easy way to select the Query Loop without going to the List View, as any attempt to select an element on that block selects the Column ‘level’ or deeper.

Worth noting this is not limited to the Query Loop, and is pretty much the case for all containers. That is to say, would it be strange if Query Loop behaved differently to other container blocks in that respect, or should we consider all containers here?

I wonder if there's something we could do with the locking api to make this behavior a user preference... perhaps an option that disables on-canvas selection of a containers children? Or even simpler: blocks in a container that are locked cannot be selected on-canvas?

[annezazu]

Agreed. This feels a bit like a slippery slope but I'm not sure how it also ties into integrating with patterns as I imagine container blocks are where the pattern switching/swapping will happen. A user preference might be a neat approach to this :)

[jameskoster]

Spitballing some more... If there was a "Disable editing" option here:

And all the blocks inside a container were fully locked, then it seems plausible that those blocks would not be selectable on the canvas, and a 'click-to-edit' UI might be organically surfaced when the parent container is selected.

In terms of pattern switching, I think that falls into "templateLock":"contentOnly" territory, and is being worked on here: #45618. We still need to figure out how that integrates with the locking api too :)