EasyFrontendAsked in 20244 min read

Sync State Across Tabs Using the storage Event

Q: Sync State Across Tabs Using the storage Event

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the sharpest, most commonly-missed part of this question — that the storage event genuinely never fires in the SAME document that made the write — was verified directly, live, in a real browser, not assumed from documentation. ## 1. The problem, restated Using only `localStorage` and its associated real browser event, make every OTHER open tab of the same app automatically react when one tab writes a new value — without polling, and without any server round-trip. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Does the writing tab need to react to its own write? | The real, sharp core of this question — it genuinely does NOT, automatically, via this mechanism. | | Is `BroadcastChannel` acceptable instead? | A real, valid, more modern alternative (covered in the javascript conceptual bank) — worth na

3.2k views

4 of 154

The problem

Problem, as an interviewer would state it: "A user changes a setting (like the theme) in one open tab. How would you make every OTHER open tab of the same app pick up that change automatically, using nothing but localStorage?"

Examples:

Code

// tab A: localStorage.setItem("theme", "dark")
// tab B: window.addEventListener("storage", (e) => { if (e.key === "theme") applyTheme(e.newValue); })

Clarifying questions expected:

Does the tab that MADE the change need to react to its own write too, or only the others?
Is BroadcastChannel an acceptable alternative, or does the solution specifically need to use localStorage?
Should this work across tabs that were already open before the change, newly opened tabs, or both?

Code / implementation expected: Yes — real, live proof of the storage event's own real, sharp self-exclusion behavior: it does not fire in the writing document, but does fire in other real, same-origin contexts.

js-coding
utility
algorithm

Try it yourself

Sketch your approach before you read the solution. That is what the interview tests.

Stuck? Get a hint.

A short nudge toward the approach. It will not give the answer away.

Solution

Target Audience: Engineers preparing for practical JavaScript coding interviews. Difficulty: Easy

How to read this doc: the sharpest, most commonly-missed part of this question — that the storage event genuinely never fires in the SAME document that made the write — was verified directly, live, in a real browser, not assumed from documentation.

1. The problem, restated

Using only localStorage and its associated real browser event, make every OTHER open tab of the same app automatically react when one tab writes a new value — without polling, and without any server round-trip.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Does the writing tab need to react to its own write?	The real, sharp core of this question — it genuinely does NOT, automatically, via this mechanism.
Is `BroadcastChannel` acceptable inst

The solution is hidden so you can try first

4 min read · 9 sections

Run the code

Edit the code and run it here. Each console line with an expected value becomes a test.

JavaScriptReal, live-verified proof: the storage event genuinely never fires in the writing document, but correctly fires in a separate, same-origin context — verified directly

Practice

Discussion

Other approaches, follow-ups and how it went in real interviews.

No comments yet. Share how you would answer it.

Question 4 of 154 in JavaScript coding

Keep your momentum going.

Mark this question solved to track your progress, then take the next one while it is fresh.

All JavaScript coding questions

Up nextEasy→

Promise Timeout

Continue