A toggle’s state must survive a page refresh

What it is

A toggle shows a setting, not this session’s mood. After a refresh, a re-entry, or opening from another device, the key should still reflect the same value. Snapping back to unpressed while the data is still on—or remembering on while the data is gone—makes people act on the look and flip the value again. Persistence means look and store together survive the page’s life cycle, not that the browser happens not to have torn down the DOM.

Why it happens

People treat a toggle as a window on world state. A window that returns to default after refresh is read as “the system cleared my choice,” so they turn it on again; if the data was still there, that second click turns it off. When the two ends disagree, look is the trusted end because it can be seen. Single-page apps often keep the value only in component state, drop it on a route change, while the server or document model still holds it. Multiple tabs add another copy: A has it on, B is stale, a refresh of B overwrites A. Persistence failure looks like random flipping; the cause is a life cycle that split view from source.

Studying it

Have people turn a setting on, then hard-refresh, go back and forward, open the same URL in another tab. Log whether look, local store, and server agree.

Independent variables: which layer holds the value (component only / localStorage / server), whether tabs sync. Dependent variables: false flips after refresh, “I didn’t turn it off again,” cross-tab conflicts.

A lab demo that lives in memory never refreshes. Use a real reload, including a mobile cold start after the OS killed the process.

Where it stops holding

In-document formatting (bold in this file) should follow the document, not persist as a global user setting—that is a different value. A one-shot Show password should not survive refresh. A session-level Preview may live only for this visit if copy says so. Read-only demo data has no writable source; persistence does not apply.

Applying it

• Read the toggle’s look from a persistent source and use the same read after refresh; do not hard-code the component’s initial value to off.
• Write to the source at the interaction, not on unload.
• When two tabs open the same setting, sync from the source or surface the conflict; do not let each tab keep a private local state.
• Verify by turning the setting on, hard-refreshing, then cold-starting. One disagreement between look and value, or a user flipping it “back on” and thereby turning it off, is a persistence failure.

Related

• Within the group: E1.12.1 A toggle button uses pressed and unpressed to show the current setting · E1.12.2 Assistive technology must see a toggle as a switch-like state · E1.12.3 Toolbar toggles need a different look from neighboring action buttons
• Adjacent: I3 State management · E3.03 Switches · H3.09 Crash and offline recovery
• Search terms: state persistence · toggle button · refresh restores settings