Deferred apply
What you're building: filters that stage their changes until the visitor presses Apply, instead of re-querying on every click.
Instant filtering is right for a handful of options. It is wrong on mobile, where every tick re-renders the list under the visitor's thumb, and wrong for filter panels with many groups.
What you need
- Applies toThe filter group
Stages selections instead of applying them.
- Applies toA button inside the browse wrapper
Commits the staged selections.
Build it
Set on each group that should stage, then add a button with .
Add a second button with to discard staged changes.
Mixing modes is allowed and often right: a sort control that applies instantly alongside a filter panel that stages.
Styling the staged state
Staged-but-not-applied selections carry data-wf-algolia-staged, so the
difference between "ticked" and "in effect" is visible:
[data-wf-algolia-staged] {
outline: 1px dashed currentColor;
}
Without some visual difference, deferred mode feels broken — the visitor clicks and nothing happens.
Driving it from your own code
The public API exposes the same primitives:
WfAlgolia.commitStaging();
WfAlgolia.refresh();
commitStaging() deliberately does not run the query, so you can commit several
groups and query once. Call refresh() afterwards. The Apply button does both.
Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| Filters still apply instantly | wf-algolia-apply-mode is not on the group | Set it per group, not on the wrapper |
| Apply does nothing | The button sits outside the browse wrapper | Move it inside |
| Staged changes look identical to applied ones | No styling on data-wf-algolia-staged | Add a style |
| Committing from code changes nothing | refresh() was not called | Call it after commitStaging() |