Claude Opus 5.5: Make Product Filters Survive the Back Button

Give Claude Opus 5.5 a sequence of browser actions and expected states, then ask it to repair filter restoration. Saving a filter value is only half the job: the address, selected controls and visible results must agree after Back, Forward, reload and opening a shared link.

Decide what one step backward should mean

Start with a small history contract. In this hypothetical catalog, a shopper applies “blue,” opens a product and presses Back. The desired result is the blue-filtered catalog, not an unfiltered list. Typing three letters into a search field should not require three additional Back presses unless that is explicitly your chosen behavior.

A 2020 developer question about query parameters illustrates the opposite frustration: every tab change became a history step. It is evidence of a design question, not a universal recommendation to replace every history entry.

Treat the URL as a reproducible state description

Use public, non-sensitive values such as category, color and sort order. Do not put customer details or secrets into the URL. Parse values against an allowed set, supply defaults and decide how repeated keys work. Keep unrelated campaign parameters when changing filter parameters; do not rewrite the entire query string from memory.

For the fictional URL below, color and sort describe a reproducible catalog view:

/products?color=blue&sort=price-asc&utm_source=newsletter

A targeted edit should change color to green while retaining sort and utm_source. Use URL and URLSearchParams instead of manual string concatenation. Encode the state consistently so refresh and a newly opened tab can reconstruct it without depending on the previous tab's memory.

MDN's History API guide distinguishes adding an entry with pushState from updating one with replaceState. Calling either does not itself perform your rendering work. A traversal handler must restore the view; initialize the first entry too, so returning to it does not leave an empty state. In a routed application, use its supported navigation APIs rather than layering a competing history controller on top.

Ask Opus for a state-transition repair

Repair filter restoration in the supplied product catalog. Inputs: router version, filter component, URL parser, fetch logic and a recording of the failure. First map the current source of truth and any duplicate stores.
Desired sequence: unfiltered catalog → apply blue → open product → Back → blue list → Back → unfiltered list → Forward → blue list. A draft search must not create an entry per keystroke. Reload and a shared link must reconstruct the applied state.
Preserve unrelated query parameters. Allow-list color and sort values; define repeated-key and invalid-value behavior. Use the existing router APIs where applicable. On history traversal, update controls and results without adding a new history entry.
Handle slow requests so an older response cannot overwrite the newer filter state. Keep loading and empty-result states understandable. Restore scroll deliberately after the correct results exist.
Return a minimal patch and a test table containing URL, controls, result identity and history position for each step. Do not report browser tests as passed unless executed. Name any missing runtime inputs.

This is a proposed Opus task, not a measured model result. The official prompting guide is a reference for task framing, not proof that a patch works. An illustrative URL round-trip can be checked locally; actual history and request behavior still require a browser test.

Verify restoration under pressure

Test Back immediately after opening a product and after a slow response. Then apply blue followed quickly by green: if blue finishes last, it must not replace the green results. Abort obsolete requests or reject stale responses using the current request identity. Do not hide the bug by freezing all navigation.

**Is local storage enough?** It may remember a preference but does not by itself define each history entry or a shareable view. Avoid letting a saved preference silently overwrite an explicit URL.

**Should every filter change use replaceState?** That would remove meaningful intermediate steps in the contract above. Choose the policy before implementation.

**Is this the same as auditing campaign links?** No. Campaign-link auditing checks destinations and parameters; this checks restoration after interaction.

Create the matching product creative in Panelly Studio, then test the campaign's real destination through the full browse-and-return journey. This article does not claim Panelly integrates Opus or implements the hypothetical catalog.

Sources and further reading

• Original reference · stackoverflow.com
• Original reference · developer.mozilla.org
• Original reference · platform.claude.com