Filters and sort must survive a round-trip

What it is

A user narrows a list to “unread only, price low to high,” opens an item, and on return those constraints should still be there. Keeping filters and sort across a round-trip means the query is part of this browsing task and lives through the detail page, rather than every return to the list resetting to the unfiltered default. It does not care where the user had scrolled, or how many days the constraints may live. It cares that this one there-and-back does not throw away narrowing already paid for.

Why it happens

Filters and sort are a cut the person made on a collection. The cut cost clicks, waiting, and a check that the result still looks right. Opening a detail is understood as “look at one item inside this already-cut collection,” not “leave the collection.” If return drops the facets and sort, the collection becomes the uncut world again; the item just viewed may sit dozens of screens away, and people think the object vanished. Worse, the filter controls still look on while the data is the full set—control and content disagree, and every filter is then distrusted.

The engineering failure is storing the conditions only in component memory: the detail is another route, the list is destroyed, return uses the default query. If facets are absent from the URL or the session, refresh and share lose them too, but round-trip loss happens earlier and more often. Writing conditions into the URL survives Back and refresh; memory-only does not survive unmount. From the detail page the user cannot see whether the list still remembers, so the failure is always discovered on the return frame.

Studying it

Have people apply at least two filters and change sort, open an item, return, and see whether the collection is still that cut.

• Independent variables: where conditions live (component state only / sessionStorage / URL query), whether detail shares a route with the list.
• Dependent variables: whether filters and sort still apply on return, whether control state matches results, whether people re-click the same filters.
• Methodological note: a single filter is easily matched by accident with a default. Use “non-default sort plus at least one non-default facet.” Add a contrast: open the detail via a new deep link from the list, then return—if conditions live in the URL, this path should keep them; memory-only will drop them, which splits the implementations.

Where it stops holding

If the user did something on the detail that undoes the current filter (marked the last “unread” as read, deleted the only match), return may yield an empty set. Keep the conditions and show empty; do not silently clear filters to pretend data remains. When an account-level default sort changes, a session-temporary sort conflicts with the new default; one of them must win, they cannot both light up. Admin tools that write filters into shareable URLs turn round-trip keep into “bring someone else’s filters into my session”; opening then needs confirmation, not silent inheritance.

Applying it

• Write the current facets and sort into the list route’s query (or an equivalent recoverable session). Enter the detail with push so Back brings the same query back.
• Lit filter controls must render from that same condition object. Never let the controls remember what the request forgot, or the reverse.
• Do not replace the list frame’s query away when entering a detail, or Back lands on an unfiltered list URL.
• Verify: pick two non-default filters, change sort once, open a detail, go Back. Result set, lit controls, and the query in the address bar must agree. Copy the detail URL, open it in a new tab, return to the list: if the conditions are still there, they were written to a recoverable layer, not only to memory.

Related

• Within the group: G4.03.1 Back to a list should restore where the user had scrolled · G4.03.3 Persisted state expires, and expiry must be explained
• Adjacent: G3.16 Search scope · G4.07 State persistence and position restoration · I3.06 State persistence
• Search terms: filter persistence · sort state · query string