The Choice That Kept Disappearing

Once I chose a smaller account, the app would keep that choice as I moved through the work. Then I clicked an item inside that account and landed back at the parent account as if I had never made the choice at all.

There was no warning. Nothing crashed. The screen simply forgot where I was.

The feature itself was useful and ordinary. An account administrator could use a dropdown to choose a sub-account, then see the detail screen narrowed to that sub-account’s information instead of the larger parent account. It was the kind of choice a person expects a tool to remember for the next few minutes. Pick the drawer you need, then keep working in that drawer.

I put that choice in the page address. A query parameter is just a small labeled bit of information at the end of a web address, such as ?div=42. It seemed like the right home for the choice. Reload the page and the same sub-account stays open. Save the address or send it to someone, and it opens to the same place. The page could read the choice again each time it opened.

For half a day, I felt smart about that. The choice survived a refresh, and it could be shared. Those are real benefits. A note kept only in a page’s short-term memory disappears when the page reloads. A note written into the address can come back with the page.

What I missed was the cost. Every link that was supposed to keep someone inside the chosen sub-account also had to carry that little piece of the address forward. One missing &div= was enough to wipe out the context. It was like writing a room number on a stack of papers, then forgetting to copy it onto the next sheet. The work still exists. You just no longer know which room it belongs to.

The first failure appeared in the header link for an item. I had chosen a sub-account, opened an item inside it, and the link took me to the parent account’s screen instead. The link knew the item number, but it had forgotten the selected sub-account.

At first, I fixed that one link by adding the missing piece of the address. It was a one-line change. That did not solve the larger problem, because another path had the same gap. After saving an item, the page did a short reload to bring me back to the detail screen. That reload also left out the selected sub-account. About 500 milliseconds after saving, the screen quietly sent me back to the parent account’s root view.

The cost was a whole commit spent hunting for every place the app built an internal destination. It also cost the kind of patience that disappears quickly when a person saves work, blinks, and finds the tool has lost its place. Neither bug announced itself with a helpful message. I found both by using the feature and thinking, more than once, “Where did my selection go?”

The two failures looked different on the surface. One came from clicking a related item. The other came after saving. But they were the same mistake: a new destination had been built without carrying the choice that defined the current view.

That matters beyond this one screen. Sometimes a link should leave the current view behind. If you choose a different part of the tool, keeping the old choice could be wrong. The trouble is not that a page address holds a choice. The trouble is making that decision separately in every little link, button, and reload. Sooner or later, one of them will be missed.

The better answer was not to keep pasting &div= into more places. I should have built one small helper that makes the addresses for this page. It would start with the choices that should travel along, add the new details for the next destination, and produce the finished address in one place. A link to an item could ask for the item it needs, while the helper remembers the active sub-account. A link that truly begins something new could deliberately leave the old choice out.

That small change moves the important question to one visible spot: what belongs to this view, and what does not? It also means a new link does not depend on someone remembering a hidden rule from months ago.

I built that helper after fixing the same lost-choice problem twice, which is a mildly embarrassing order to do it in. But the pattern is clear now. If the same tiny repair has to be made in several files, the real repair is usually to give that job one home.

The header link and the post-save reload were the same bug found twice, one &div= missing in two different places. The fix that actually held was the one helper that builds every destination address for that page, carrying the active sub-account forward by default instead of leaving it to whoever writes the next link to remember.

dxdev LESSON · paste into your AI coding agent
LESSON: State kept in the URL is only as durable as every link that builds a new URL from it
SOURCE: dxdev.com/blog/2026-02-27_choice-that-kept-disappearing
WHAT HAPPENED: A sub-account selection was stored as a query parameter (like ?div=42) so it would survive a page refresh and could be shared as a link. That worked until any code path built a new destination URL without also carrying the parameter forward. An item's header link dropped it and landed back on the parent account. Separately, the short reload after saving an item also dropped it, quietly sending the user back to the parent account's root view about half a second after they saved. Both were the same root cause found twice as two different bugs. The fix replaced ad hoc parameter-copying with one URL-building helper for the page that carries the active selection forward by default, so a new link does not depend on someone remembering to add it.
THE RULE: State kept in the URL is only as durable as every place in the code that constructs a new URL from it; centralizing URL construction in one shared helper is what stops any single link from silently dropping the context.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
      1. Any page state stored in a query parameter with more than one place in the codebase building destination URLs by hand.
      2. Any post-action redirect or reload built as a brand new URL rather than the current URL with updated parameters merged in.
      3. Two or more bug fixes that each added the same missing parameter to a different link, which is a sign the real fix belongs in one shared URL builder instead of at each call site.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.