Server-side filtering with facet counts

[erikhfj]

Faceted filtering that does not lead the user into an empty page.

• AlbumFilters: genres, decades, countries, hasReviews
• genreFacets / decadeFacets counts computed with the counted dimension excluded from the filter
• filter panel renders counts and hides categories that would return zero
• changing a filter resets to the first page (drops the cursor)

Acceptance: with a genre selected, the decade counts reflect only that genre, and with a decade selected the genre counts reflect only that decade.

[erikhfj]

Rachel's question in the group chat is the right one to settle before this issue is implemented, because the two halves come as a pair and the current state of the repo has one of each.

Today:

• This issue's body says facets are "computed with the counted dimension excluded"
• The earlier group decision was "tallene burde minke dersom man velger flere filtre", which is the opposite behaviour

Those two cannot both hold. Here is why, and what each choice costs.

The two coherent pairs

A. OR within category, AND between categories. Rock and Pop gives Rock OR Pop. Genre and decade gives genre AND decade.

B. AND within category. Rock and Pop gives Rock AND Pop, the intersection.

Facet counts then follow from the choice rather than the other way round.

Worked example

Search is empty. No filters.

	A: OR within	B: AND within
facet counts, nothing selected	Rock 10, Pop 5, Jazz 2	Rock 10, Pop 5, Jazz 2
select Rock	results 10	results 10
genre counts while Rock is selected	Rock 10, Pop 5, Jazz 2	Rock 10, Pop 1, Jazz 0
select Pop as well	results 15 (Rock OR Pop)	results 1 (Rock AND Pop)
does a count predict the click?	no, clicking Pop gives 15 not 5	yes, Pop showed 1 and gives 1
do counts shrink as you select?	no, within the same category	yes

What each one is good for

A is what Amazon, Solr and Algolia do, and it is what Rachel is leaning towards. "Show me Rock or Pop albums from the 1990s" is a natural thing to ask. The facet count answers "how many would I get if this were my only selection in this category", which is useful when you are exploring.

Its cost: the counts do not move as you tick genres. totalCount grows when you add a genre, which is the opposite of the earlier "numbers should shrink".

B is what we said earlier, and it has one real advantage: the number next to each option is exactly what you get when you click it. That is the strongest possible guard against the lecture's pitfall, "ikke la brukere ende opp med null i resultatsettet", because a selection that would empty the list shows 0 before you click.

Its cost: Rock AND Pop is a small intersection, and in a music catalogue where albums legitimately carry several genre tags it is a less common thing to want. With 16 sample albums it will empty out fast.

My read

Rachel is right that A is more natural for genres. But then the facet counts have to be per-dimension exclusion, which means giving up "counts shrink as you select" within a category. Numbers still shrink across categories: adding a decade narrows the genre counts, and totalCount responds to everything.

If we want both, there is a middle path: A for filtering, and show each genre's count as "what you would add", meaning the number of albums you gain by ticking it. That number does grow and shrink meaningfully. It is not what other sites show, so it needs a clear label in the UI.

What I would not do

Pick the filter combination first and bolt the facet counts on afterwards. The count is what stops the user from dead-ending themselves, so the two have to be designed together.

Suggested resolution

Rachel and Even try both locally as Even suggested, and then this issue's body gets rewritten to match whichever pair they pick. The body as it stands describes A while our notes describe B, and whichever way it goes, one of the two needs correcting.

If it helps, I can add a temporary flag in the resolver to flip between the two so the comparison is a UI toggle rather than a rebuild.