Query Panel Design / API (Latest Posts, Calendar, etc)

[folletto]

In #1594 we explored the idea of having a "universal" Query Panel that any block and plugin could reuse. The general idea is to provide an easy way to execute queries (WP Query) so any block that lists posts, pages, or other content type could use.

Benefits:

1. Any developer that needs to get content in their block, can simply implement it, without having to program the UI from scratch.
2. If WordPress updates and there are upgrades to the UI of the "Filter Content" panel, every block that makes use of it will get automatically upgraded too.

Cons:

1. I can't see any cons to this approach, except deadlines: we might want something VERY simple to start with, so Core and new block plugins can use it, and then start upgrading it over time as it can blow up in a fairly complex UI.

Notably this means having a v1 added to Gutenberg soon, so blocks and plugin developers could use it, and with following iterations we can rely on the common API to upgrade it.

[folletto]

Here's the basic design for a v1 — a "minimal" solution:

I reduced the set to:

• Sort Order
• Category
• Number of Items

Rationale:

1. There's no way we'll make everyone happy in a v1, so I included a subset that will still allow a good degree of flexibility.
2. I limited to three items as more it felt cumbersome. If we grow this it needs to change the UI to something like @westonruter mentioned above.
3. Sorting is relevant as it's a way to anchor somewhere the list. Notice how I avoided also "ascending" or "descending" wording, as it's too technical.
4. Number of items is relevant to limit the quantity. I feel this is very important both for performance reasons and structure of the page.
5. I opted for Categories instead of Tags as the UI to manage them is a bit more intuitive: click to assign a category, click from the list to filter that specific category. Also it avoids the complications of tags which would allow multiple tags.
6. The combination of Order / Category / Number feels a good starting point that still allow three very different dimension to slice it.

Note: I didn't use a slider for "Number of Items" as I'm considering adding "All" (but, performance?). If we don't want to add All but we want a limit, then we should user the slider component.

In the mockup I also avoided getting in too many details about the content of each of these lists, so if we agree the three dimensions above are a good v1, we should review its content.

Order By:

• Newest to Oldest
• Oldest to Newest
• A → Z
• Z → A

Category:

• All
• Any other category, with indentation

Number of items:

• All
• 1
• 3
• 5
• 10
• 25

I haven't included an idea for a Query Panel v2 yet as time wise this seems more relevant, but of course the key concept here is that if we introduce a "universal" Query Panel that any block can use, we can extend it later with 100% compatibility and instant upgrade for any plugin that reuses it.

[karmatosed]

I really like this. I can see it helping a lot of people get a head start into blocks - which is a huge benefit. My concern is time and getting this done, that said I think it's a great project for someone to take ownership of. I would love to include this as soon as possible if someone is up for implementing it. Any takers?

[westonruter]

For “Number of Items”, what about a type=number input which has a min=0 and max=100? Maybe there is a component already for that, for a range. Having those specific numbers available seems a little bit arbitrary?

[folletto]

For “Number of Items”, what about a type=number input which has a min=0 and max=100? Maybe there is a component already for that, for a range. Having those specific numbers available seems a little bit arbitrary?

As I mentioned above:

Note: I didn't use a slider for "Number of Items" as I'm considering adding "All" (but, performance?). If we don't want to add All but we want a limit, then we should user the slider component.

So yes, if we don't want an "All" we can use the existing slider component:

As for arbitrary – they aren't, if we want to go in that direction I can explain. ;)

[westonruter]

Right, “all” is not appropriate for performance reasons. Slider with number input I think is right.

[folletto]

Ok! Quick i2 to update that:

[jorgefilipecosta]

Query panel was merged in #3198 implementing the proposed design for the latest posts block.

[folletto]

Question: is the implementation of QueryPanel also abstract enough that any Block plugin author can simply load it and get the UI and the WP Query data output?

[jorgefilipecosta]

Hi @folletto, when implementing the QueryPanel I tried to make it reusable and abstract enough so that other blocks can use it. It is an independent component, for each input you need to pass the current value that is selected and an onChange handler. The fields shown are also configurable e.g: some can be hidden.

[folletto]

Awesome! Thank you! <3