Browse
What you're building: a listing page that shows results as soon as it loads, and narrows as people filter, sort and paginate.
Browse is built around a wrapper. Everything that belongs to the listing — filters, results, pagination, sort — lives inside it. That containment is what lets the script know which controls drive which result set.
What you need
- Applies toA Section or Div wrapping the whole listing
The wrapper. Everything else goes inside it.
- Applies toThe browse wrapper
Which index this listing queries.
- Applies toA Div inside the wrapper
Where results are rendered.
- Applies toOne card inside the results Div
Cloned once per result.
Build it
1. Wrap the listing. Put and on the Section that contains the whole feature.
2. Add results and a template, exactly as in Search.
3. Publish. The page now loads with the first page of results.
Everything below is optional and can be added one piece at a time.
A filter group placed outside the browse wrapper renders its options and then never affects anything, with no error. It is the most common structural mistake on a browse page. If a filter looks right but does nothing, check its position in the Navigator first.
Page size and pagination
sets how many results load at a time.
chooses the style — see Pagination for the values and the controls each one needs.
shifts the scroll position when a new page loads, so a sticky header does not cover the first row.
Shareable URLs
Add to the wrapper and the current filters, sort and page are written to the URL. Copying that URL reproduces the same view, and the browser back button steps through it.
Leave it off for a listing embedded in a larger page, where changing the URL would be surprising.
Always-on filters
Sometimes a listing should be permanently restricted — a category page that only ever shows one category, regardless of what the visitor picks.
applies a filter that visitors cannot remove. It is combined with, rather than replaced by, whatever they select.
Two spellings exist. The compact form takes a whole expression:
<section
wf-algolia-element="browse"
wf-algolia-index="products"
wf-algolia-base-filter="category:Shoes"
></section>
The split form is easier to generate from a CMS binding, and takes the field and value separately:
<section
wf-algolia-element="browse"
wf-algolia-index="products"
wf-algolia-base-filter-field="category"
wf-algolia-base-filter-value="Shoes"
></section>
Both accept -match and -logic suffixes to control how multiple values
combine, the same way ordinary filters do.
It does not appear as a filter chip and cannot be cleared. If people should be able to remove it, it is an ordinary filter with a preselected value, not a base filter.
A search box inside browse
Use for a text input
that narrows the listing already on screen. That is different from
search-input, which starts a search — see
Search or browse.
Counts and empty states
- renders the number
of matches.
wf-algolia-text-templatecontrols the wording. - is shown only when nothing matches.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Page loads empty | No wf-algolia-index on the wrapper | Add it — browse cannot infer the index |
| Filters do nothing | They sit outside the browse wrapper | Move them inside |
| Results ignore the category | A base filter is set that you forgot about | Check the wrapper for wf-algolia-base-filter |
| Pagination controls do nothing | wf-algolia-pagination not set, or the controls are outside the wrapper | See Pagination |
| Back button does not restore filters | URL sync is off | Add wf-algolia-url-sync="true" |