Query Block: select from a list for categories

[annezazu]

What problem does this address?

As part of the fifth call for testing for the FSE Outreach Program, the following feedback came in. Of note, this is was translated from Japanese and is not the original text:

When selecting the category of the Query block, it would be nice to be able to select from a list of existing categories instead of suggestions from input. Because I do not remember all the categories.

Another person later brought up the same feedback:

I believe another tester mentioned this too but I think it would be helpful to have a list of the categories I can choose from or a drop down instead of relying on the user to remember their categories.

What is your proposed solution?

List the categories in a way that matches the post editor. It's not clear to me though if this might cause performance issues so, if that is the case, feel free to close this :) but I do think this might be a helpful addition to consider.

Current view:

Categories in the post editor:

[paaljoachim]

I believe this would very much help. Query Block - more advanced / multi select query options https://github.com/WordPress/gutenberg/issues/30706

[annezazu]

This came up in the seventh call for testing as well:

When in: Right sidebar > Filters > Categories. It would be nice to get a suggestion list of existing categories on focus.

[javierarce]

That issue that @paaljoachim links is very interesting and has a lot of potential, but I still think that @annezazu's proposed solution (using the same interface to select categories as in the post editor) is more intuitive and solves the problem of not remembering the names of the categories (and thus allowing to refine the query much faster).

I've also seen this UI in one of @jameskoster's explorations for this block, and I'd like to give my plus one to the implementation of this enhancement.

[annezazu]

More feedback from the tenth call from testing from our very own @paaljoachim :D

But it looks like I have to add categories to the Categories field in the sidebar settings in the Filters panel in the Query Loop. I had to open a new tab and go to Posts -> Categories and check out the names of the categories. It would be very useful with the multi select so that we can easily choose various categories from a drop down.

In my own testing, this continues to be a pain point I run into too and feels like an easy win to get in place to improve the UX.

[paaljoachim]

To me it feels like a quick fix to change categories to use regular post editor categories feature. @ntsekouras

-Edit- Adding the visual reference.

Post Editor categories:

Query Loop categories:

[ntsekouras]

👋 - I'll have to look into better at this but in general this is definitely a part of this: https://github.com/WordPress/gutenberg/issues/25198. Some designers might share some thoughts as well 😄

--cc @jameskoster @jasmussen

[jameskoster]

FWIW I worked on this exact problem for the WooCommerce Products block a couple of years ago. The UI in the video below accounts for a few things that I think have been missing in explorations shared so far:

• Selected categories are always displayed (as chips) even when searching.
• There's a quick way to deselect all categories to start again.
• Category nesting.
• OR / AND operators on the selected categories. This one is especially important in the context of the Query block.

https://user-images.githubusercontent.com/846565/136374929-31ad69ec-d9b5-44f7-b3be-8d75a25145aa.mp4

Looking at this with fresh eyes, one thing that might be missing is a "select all" option to make it easier to display posts from all categories except one or two specific ones.

Regardless of where 25198 takes us, it seems that we'll need need more intuitive patterns on a granular level for query block setup.

[noisysocks]

As a first step we could use the existing ComboboxControl component.

[AllTerrainDeveloper]

I have local changes with the following feature, I am unsure if it's good enough or not, but could you point me in the right direction? If you think it's good enough I can prepare a pull request 🙂 I'm newbie in Gutenberg 🙂

[AllTerrainDeveloper]

PR Here: https://github.com/WordPress/gutenberg/pull/45695

[AllTerrainDeveloper]

It also seems I went out of scope, I am not very used to Gutenberg. Seems the change needed to be done in another place! Oops!

[paaljoachim]

It would be very helpful to get movement in this issue. It affects the Query Loop block as well as the new in beta WooCommerce Products block. I even also happen to create an issue in the WooCommerce blocks Github repo. https://github.com/woocommerce/woocommerce/issues/42416

@Mamaduka @noisysocks @youknowriad

[ntsekouras]

Just noting that the current implementation does a dynamic search, so it it's not limited to the hard limit of 100 results of the WP REST API. So if we fetch some first categories to be visible, we would still need to preserve the dynamic searching and probably combine results.

[paaljoachim]

Current implementation does a dynamic search, but one needs to know which categories one is looking for to actually do the search. The question comes back to: How can we easily show a lot of categories without it crowding up the settings sidebar?

• Multiselect drop down would make it possible to open the drop down and see a long list of categories. Selecting the categories one need. Having a dynamic search at the top to find categories when one knows which categories to search for.

• Looking at the various ways WooCommerce blocks currently presents categories.

• Having a category list with a load additional categories button to see even more categories.

There are various explorations that can be done where categories can easily be seen and found.

[ciampo]

@wordpress/components dosen't currently offer a component that allows dynamic search + async loading + multiple selection the way was highlighted above. Probably the closest component currently available is FormTokenField, although I'm not sure if the way tokens are displayed suits the specific needs that we have here.

To implement a solution closer to what was discussed above, folks could look into building a custom solution using CheckboxControl and ComboboxControl (as mentioned above by @noisysocks ).

[Mamaduka]

I just wanted to note that FormTokenField isn't the best suited for this UI.

Why?

• The component expects values to be strings used for display. So you've to use term names/labels for values.
• The term names aren't required to be unique, and we end up with errors like this - #49515.
• Using string also means maintaining the id => label map and using it to convert string values back to corresponding IDs. This adds extra overhead before saving terms in block attributes or attaching them to posts.

[richtabor]

@Mamaduka Would ComboboxControl work? Can it multi-select?

[paaljoachim]

@jarekmorawski I believe you might want to know about this issue. I am thinking in relation to how WooCommerce uses categories.

[Mamaduka]

@richtabor, IIRC, the current version of ComboboxControl doesn't support multi-select.

I think there was a plan to refactor some of these components using Ariakit (which supports multi-select) under the hood. I'm not sure about the current status, though.

[richtabor]

Got it. I'm not thinking this should be prioritized, just wanted to look ahead a bit. Thanks!

[jarekmorawski]

Design-wise, I'd prefer to stick to the form token field because it's a widely used pattern that most users are accustomed to. It supports multi-select and search. There are ways we'd make it smarter for everyone's benefit:

• Make the token component support non-text elements, like images
• Display handles and make it possible to reorder tokens by drag & drop
• Support error and loading states
• Make tokens optionally dismissible
• Make it possible to search by label, id, slug, SKU, author, and other meta-data
• Display secondary meta-data when two tokens with the same label are added, e.g., ID or Slug

[richtabor]

Design-wise, I'd prefer to stick to the form token field

Does Form Token Field currently provide all results if there are no matches? That’s the crux of this issue. To be able to see available categories without having to know the categories.

Also, per your mockups, why would you need to drag to reorder tokens?

[jarekmorawski]

Does Form Token Field currently provide all results if there are no matches?

I believe so. We use a version of it in Woo blocks and it displays available options when nothing is selected. There is, however, some work to be done around performance. For instance, we may use it for product attributes; many Woo stores have 1000s of them. It'd be great to support lazy loading or something similar to make sure the component is speedy and users don't have to wait too long for the results to load.

Also, per your mockups, why would you need to drag to reorder tokens?

In Woo's Product Collection, a close relative of the Query Loop block, users can add products that will always be displayed in the block. We'd like to let them drag the tokens to reorder products. Doing that in the canvas is impossible because the "fixed" products are mixed with dynamic data pulled from the store's database based on different contexts.

Tags, brands, and other item mata data could be another use case. They're things dynamically pulled from the currently viewed item so it is not possible to view and select them in the canvas (especially when editing a generic page template).

[paaljoachim]

I am going to add in this somewhat associated link to tags issue I found as there might be some info shared by @jarekmorawski that can be useful: https://github.com/WordPress/gutenberg/issues?q=is%3Aopen+label%3A%22%5BFeature%5D+Document+Settings%22+tags

[jameskoster]

Does Form Token Field currently provide all results if there are no matches?

Yes, see this example.

It's a bit strange how the options displace the content below rather than appearing in a popover though. On a site with hundreds of tags that's going to be quite awkward.

[ciampo]

Hey folks, just wanted to let you know that we're considering a rewrite of FormTokenField in the future, as part of our wider effort to rewrite some of our components to use ariakit internally.

Before we can work on FormTokenField we'll need to wrap up the rewrite of DropdownMenu, CustomSelectControl and ComboboxControl — so we're not going to be able to get to it soon. But it's in the works!

It would probably be a good idea to start brainstorming any tweaks and changes / improvements that we'd like to see applied to the component (like what @jarekmorawski shared here). Please feel free to open a new issue specific to FormTokenField so that @WordPress/gutenberg-design and us @WordPress/gutenberg-components can discuss it separately from the query block

[Mamaduka]

@ciampo, is there a tracking issue for the FormTokenField rewrite? Sharing ideas/requests there might be easier, considering the number of issues we have in this repo.

[ciampo]

I invited folks to open one in my previous message — but I went ahead and did it myself

https://github.com/WordPress/gutenberg/issues/64086

[jameskoster]

In Woo's Product Collection, a close relative of the Query Loop block, users can add products that will always be displayed in the block. We'd like to let them drag the tokens to reorder products. Doing that in the canvas is impossible because the "fixed" products are mixed with dynamic data pulled from the store's database based on different contexts.

This seems valid, but also incredibly niche. Do we really want to build the complexity necessary to achieve this into this component?

As a provocation; in https://github.com/WordPress/gutenberg/issues/63872 we're exploring a UI based on ItemGroup for re-ordering fields in data views. I wonder if that might work in this use case too?