Why it is built this way
The filter is an ordinary form that sends its choices in the address. The script reads the same form. That gives three things for free: it works with JavaScript off, the page can be cached like any other, and there is no endpoint on your site for a visitor to call. Nothing is written to the database to answer a request.
What gets swapped
- the product list, whether it is WooCommerce’s product collection block, an archive products widget or a classic
ul.products; - the result count and the sorting menu;
- the pagination;
- the filter itself, so counts and chips are the new ones. A set that was open stays open.
The address in the browser is updated, the page title follows, and the back button moves between the filter states.
The details that make it usable
A request still on its way is cancelled when the shopper chooses again. Keyboard focus stays on the control that was used, and a hidden status line announces the new result count to screen readers.
Other scripts that need to know can listen for the siftwren:updated event on the document, and on sites that load jQuery, the script also triggers the post-load event many themes already listen for.
When it does not fit
If the product list is missing from the answer, or the request fails, the script follows the address as a link. A theme that draws its products in an unusual place can be pointed at them with the Product list selector setting. You can also turn the whole thing off, and the form then loads the page as it did before. Here is an address as the script builds it:
Read a filter address
Paste the address of a filtered shop page and read it in plain English. Nothing you type leaves this page.