Feature/139 searchable multi select filters #170

2026-08-24T16:44:41-05:00

bermudalamb commented

2026-08-24 16:44:41 -05:00

No description provided.

bermudalamb self-assigned this 2026-08-24 16:44:41 -05:00

bermudalamb added this to the Customer and Admin UI review findings project 2026-08-24 16:44:41 -05:00

bermudalamb added 2 commits 2026-08-24 16:44:41 -05:00

feat(filters): make the storefront filter panel searchable and multi-select (#139 ) faf38be91a

The filter drawer did not scale with the taxonomy behind it. Categories were a bare antd `Tree` rendered at whatever depth it had grown to, with no search and single selection, and tags were a wall of every tag in the system. Neither said what was selected except through highlighting and chip colour.

Both are now searchable multi-selects. Categories keep their hierarchy in a `TreeSelect`, matching the admin's `CategoryTreeSelect` so the two screens behave alike; tags become a multiple `Select` whose selected pills keep their colours, which is the only place a tag's colour was load-bearing.

Several categories combine as OR. A customer picking Furniture and Decor wants both, not the empty intersection, and each selected id still expands to its descendants, so the answer is the union of the subtrees. That is deliberately the opposite of the tag rule, which stays AND, and both headings now state their rule rather than leaving it to be discovered.

`ItemFilters.categoryId` becomes `categoryIds` end to end. The recursive CTE is seeded with `= ANY($n::int[])` rather than one id, which walks every selected root in one recursion and gives the OR for free; matching on `IN` keeps it a set test, so an item under two selected branches still appears once. The query parameter keeps its singular name and becomes comma-separated, the shape `tags` and `status` already use, so every `?category=1` link written before this still parses as a list of one. A list containing anything unreadable is still a 400, per decision 9 — honouring the readable half would answer a narrower question than the one asked and look indistinguishable from a filter that worked.

The admin's inventory filter stays single-select, since it asks what is in a category rather than in any of several, but reads and writes a list of at most one so there is one shared filter type rather than two that drift.

Closes #139

fix(filters): give the category tree selectable values, and drive both controls by search (#139 )

SonarQube Analysis / sonarqube (pull_request) Failing after 5m5s

Details

Linting / lint (pull_request) Successful in 2m10s

Details

856d8c4511

Three things the e2e run found.

`toTreeData` still emitted `key`, which is how an antd `Tree` identifies a node and not how a `TreeSelect` selects one. Nothing could be picked, and `treeNodeFilterProp="title"` had nothing to filter against. It now emits `value`, matching the admin's CategoryTreeSelect.

The page object typed the name before clicking it, in both controls. Not for realism: the option lists are virtualized, so against a database holding hundreds of categories the wanted row never renders until a search narrows to it, and scrolling to it would be testing the virtual list rather than the filter.

Tag options are matched by class rather than by role, for the reason AdminInventory.toggleStatus already records — antd renders an invisible role="listbox" shim beside the real list, so getByRole('option') resolves to something zero-sized that can never be clicked. The drawer's own title is a plain element rather than a heading, so the click that closes an option list lands on the Favorites heading instead.

The multi-category URL assertion accepts the comma either percent-encoded or literal. URLSearchParams encodes it, which is how the `tags` parameter has always looked, and both spellings parse.

bermudalamb moved this to Review in Customer and Admin UI review findings on 2026-08-24 16:44:57 -05:00

bermudalamb added 1 commit 2026-08-24 16:47:14 -05:00

Merge branch 'main' into feature/139-searchable-multi-select-filters

SonarQube Analysis / sonarqube (pull_request) Failing after 5m8s

Details

Linting / lint (pull_request) Successful in 2m3s

Details

d0606dfcec

bermudalamb closed this pull request

2026-08-24 16:50:50 -05:00

bermudalamb moved this to Ready for Release in Customer and Admin UI review findings on 2026-09-09 13:33:54 -05:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bermudalamb/redefined-designs#170