Query block: Query Builder

[mapk]

Problem

How do we create a scalable and predictable UI for the Query block that provides enough power for advanced users to build detailed queries, works with the REST API, and communicates the query clearly for non-developer people to also use?

Solution

Based on this comment from @ItsJonQ, and an earlier discussion with Q, @mariohamann, and @ntsekouras, we thought it worth while to investigate a design direction that involves a condition builder (aka Query Builder) for the Query block.

This UI introduces a modal element for a block. While modals exist in Gutenberg today, it's a bit new to allow one to appear from a block's toolbar (I think). We needed plenty of area to implement the form fields necessary for this builder. Sidebars and block toolbar dropdowns weren't enough.

I had explored setting design options here. And while they solved the problem, it was difficult to settle on where the settings and filters would exist and caused visual clutter when viewing them all at once. The Query Builder helps in this respect by moving the complicated query building to a modal and hiding that power behind an icon in the block's toolbar. The Query is still communicated in the sidebar (currently as JSON text), but provides a quick view of the actual query without having to dive back into the modal.

Prototype

Query Builder Modal

cc @mtias

[mtias]

I'd challenge a bit the initial assessment:

that provides enough power for advanced users to build detailed queries, works with the REST API, and communicates the query clearly for non-developer people to also use?

I don't think such a mix should be pursued. What type of user and use cases is it trying to serve? The query block needs to allow theme developers and block authors to specify queries as needed (it can be through block attributes and doesn't necessarily imply a UI) and end-users to interact with a subset of them in a much more straightforward way.

This has to be informed by what the real needs are and not an abstract interface to WP_Query, which could spiral into an entirely separate project and lose sight on the "why".

The other important part of the query block, in contrast with the Latest Posts block currently in core, is the ability to work with different templates and structures for organizing post items (title, date, author, content, etc). That's where most of the important work rests right now — variations, patterns, individual blocks and their tools. Excellent handling of featured image (find ways to allow using a Cover block to render a featured image, for example). Possible integrations with layout blocks like Columns. Good editing flows for the Loop inner blocks template.

Reminder of the very initial kickstart for this block; I need to be able to create this:

Once we are closer to this being a reality it could make sense to explore a full interface over the query object, but it's not a priority right now.

[ItsJonQ]

@mtias Thanks for the feedback!

I was looped into Query Block recently. I did my best to interpret the gigantic discussion (😂 ).
It led me to suggesting a "condition builder" approach.
I must have missed some context here.

Apologies for potentially misguiding the direction of things 🙏

I think this reframing was helpful.

I'm happy to assist with ongoing work if needed.
Otherwise, I can step back and allow others who have much more project awareness and context to continue.

[mariohamann]

@mtias Thank you for your description! Personally, after having seen the newest (really nice!) explorations of @mapk over here, I more and more have the feeling, that the Query Block at the moment has to combine too many too different concepts:

1. "Query configurations" = Which posts are shown (e. g. Offset, Order, Post Type, Sticks Posts etc.)
2. "Query content" = Which content of the posts is shown (e. g. Title, Date, Excerpt, Featured Image"
3. "Query style" = How content is rendered (e. g. Grids, Sliders, etc.)

The current approach is to use variations – but we need variations for every part. E. g. a "Latest Posts" variation which of course handles "Query configurations". But "Latest Posts" could be shown as a simple list or as cards etc. etc. Would that be two variations e. g. "Latest Posts: Cards" and "Latest Posts: Grids"? I don't think that's a scalable solution.

I would like to propose the idea to seperate at least the first concept from the others and would like to bring in the "Loop Block" for further considerations:

1. Query Block handles only which posts are shown; for the beginning with some simple stuff like amount of posts, order, offset, etc.; variations could handle those configurations (like "Latest Posts")
2. Loop Block handles which content is shown; again variations or even patterns could be used to select a preset for the content to be shown and maybe even the style of the content.

For more clarification, here a quick draft:

Would that be technically possible? Would that make things even easier? I would be happy about your feedback.

[mtias]

@mariohamann that's already how it works :) When you insert a Query block it also inserts a Loop block with a default template. The Query controls the attributes of the query; the Loop controls the inner blocks template.