Filtered Query Block

[Nyiriland]

Overview

This block should extend the existing Query Loop block by adding a list of categories above the posts.

Scope

Functionality outline:

• Adds a list of post categories (as a button block?) above the post loop
• Shows all categories available resulting from the current query
• Clicking a category will filter post results
• Pagination would need to be executed at the block level (no page reload)
• Ability to pre-select a category on page load

Settings/Options

• Ability to show/hide result count # in category button
• Order category list buttons
  • highest # of results
  • alphabetical
• Show/hide pagination
• Filter overflow:
  • wrap
  • scrolled
• Filter selection: limit to just one selection at a time (default), or add ability select multiple filters at once?
• Ability to edit the “No results...” message
• Styling options for post count
  • Inline or pill
  • Or, ability to style counts with the Style tab? If not possible, should be easily able to target with CSS (number should be in a <span>)
  • Category Filter curation
    • Ability to curate which categories are displayed in the filter (eg: you just want to show your top 3 categories, not all 24)
    • Possibly add ability to show all categories for current post type, vs the ones resulting from current query (although I think this would be an edge case need, since some filter buttons may provide no results)

Layout options

• Default layout: categories above posts
• Category list stacked on side

Styling

• Filter should be editable via a Button
• Inherits the default outline and filled button styles for the theme, but should be able to be overridden

Architecture

How the block architecture might make sense; this way the filters and Query Loop layout are separate pieces, easier to make custom layouts:

Front end examples

From this Figma page.

Styling

Layouts

[ockham]

👋 I've looked a bit into this today, from a "progressive enhancement" angle.

I'd think of the role of the Filtered Query block as something that simply renders a bunch of <a> links that point to the respective URLs for each category's archive page. (This is essentially what the Categories List block does.)

The client-side navigation is the "enhancement" part -- it can be added to intercept any clicks on navigation links and turn them into client-side transitions instead.

The good news is, most of the pieces should be available already! As it happens, the Query Loop block has a toggle called "Force Page reload" that's enabled by default. Disabling it will cause it to use client-side navigation instead! As a bonus, we then get pagination etc. for free from the Query Loop block.

The bad news is, there's a number of limitations to this. The toggle is wired such that it can't be disabled if there are any blocks present that are known to interfere with client-side navigation (i.e. any block that doesn't have block-support set for interactivity.clientNavigation in its block.json), most notably the Post Content block; meaning that any archive template that wants its Query Loop block to opt into client-side navigation must not use the Post Content block (but e.g. the Post Excerpt block instead).

This might still cover a decent number of use cases, but it won't work e.g. for a video archive template where each post object contains a Youtube embed that's supposed to be shown in the archive. As a work-around for this latter case, one might need to get creative and e.g. use a post meta to set the Youtube video URL, and have the template display it via Block Bindings.

Furthermore, in addition to the "hard" requirement of blocks being compatible with client-side navigation, there's also some heuristics run on the frontend that determines if there are any other things that might interfere with client-side navigation, and will disable it if that's the case. In practice, I seem to keep running into that, so I'll need to ask my more Interactivity-API-savvy teammates how to track down the reason 😅

[ockham]

Furthermore, in addition to the "hard" requirement of blocks being compatible with client-side navigation, there's also some heuristics run on the frontend that determines if there are any other things that might interfere with client-side navigation, and will disable it if that's the case. In practice, I seem to keep running into that, so I'll need to ask my more Interactivity-API-savvy teammates how to track down the reason 😅

@luisherranz kindly helped me figure this out. In short, we only support region-based (rather than full-page) client-side navigation for now, which means that it's only the contents of the Query Loop block that are being updated. This means that clicking on pagination links triggers client-side navigation; clicking on individual items in the archive list doesn't (as they'd point to a different page).

The good news is that it should be fairly straight-forward to make this work with the Categories List block (or any similar block inspired by it) 😄 Here's a PoC: