Active filter chips render tags without their colour, the only place that does #185

New Issue

2026-08-25T13:12:37-05:00

bermudalamb commented

2026-08-25 13:12:37 -05:00

A tag carries a colour, chosen by the admin or derived from its name so the same name always lands on the same colour. Everywhere a tag is shown, that colour is shown with it — except the one place it would help most.

Where	Coloured
`ItemCard` — tags on a product card	yes, `color={tag.color}`
`FilterDrawer` — selected tags in the control	yes, via `tagRender` (#169)
`Tags.tsx` — the admin taxonomy screen	yes
`ActiveFilterChips` — the removable chips beside the Filters button	no

Every chip in that row renders as a default grey <Tag>, because the chip record it builds carries only { key, label, onRemove }. A customer who has just picked vintage from a control that showed it in red sees a grey chip appear next to the button — the same tag, twice, in two different colours.

What this should do

Tag chips carry tag.color. The others — category, price, favorites, status — have no colour associated with them and keep the default.

That asymmetry is a feature rather than an inconsistency: once only tags are coloured, colour in that row means "this is a tag", which is exactly the distinction a row mixing four kinds of filter needs. The label still says what it is, so nothing depends on colour alone.

Detail worth getting right

The chips are closable with a custom closeIcon, and the icon inherits the tag's text colour, so a coloured chip gets a matching × rather than a grey one on a coloured ground.

A tag that is not in the loaded options — the row renders before /api/filters resolves, and falls back to Tag {id} — has no colour to use and keeps the default. The fallback already exists so the chip never renders as an empty box.

A tag carries a colour, chosen by the admin or derived from its name so the same name always lands on the same colour. Everywhere a tag is shown, that colour is shown with it — except the one place it would help most. | Where | Coloured | | --- | --- | | `ItemCard` — tags on a product card | yes, `color={tag.color}` | | `FilterDrawer` — selected tags in the control | yes, via `tagRender` (#169) | | `Tags.tsx` — the admin taxonomy screen | yes | | **`ActiveFilterChips` — the removable chips beside the Filters button** | **no** | Every chip in that row renders as a default grey `<Tag>`, because the chip record it builds carries only `{ key, label, onRemove }`. A customer who has just picked `vintage` from a control that showed it in red sees a grey chip appear next to the button — the same tag, twice, in two different colours. ## What this should do Tag chips carry `tag.color`. The others — category, price, favorites, status — have no colour associated with them and keep the default. That asymmetry is a feature rather than an inconsistency: once only tags are coloured, colour in that row *means* "this is a tag", which is exactly the distinction a row mixing four kinds of filter needs. The label still says what it is, so nothing depends on colour alone. ## Detail worth getting right The chips are closable with a custom `closeIcon`, and the icon inherits the tag's text colour, so a coloured chip gets a matching `×` rather than a grey one on a coloured ground. A tag that is not in the loaded options — the row renders before `/api/filters` resolves, and falls back to `Tag {id}` — has no colour to use and keeps the default. The fallback already exists so the chip never renders as an empty box.

bermudalamb referenced this issue from a commit

2026-08-25 13:20:39 -05:00

feat(filters): show a tag's own colour on its active filter chip (#185)

bermudalamb referenced a pull request that will close this issue

2026-08-25 14:04:29 -05:00

feat(filters): show a tag's own colour on its active filter chip (#185) #187

bermudalamb closed this issue

2026-08-25 14:05:34 -05:00

bermudalamb referenced this issue from a commit

2026-08-25 14:05:35 -05:00

feat(filters): show a tag's own colour on its active filter chip (#185)

bermudalamb referenced this issue from a commit