EasyFrontendAsked in 20246 min read

LocalStorage wrapper items TTL

Q: LocalStorage wrapper items TTL

**Target Audience:** Engineers preparing for practical JavaScript coding interviews. **Difficulty:** Easy > **How to read this doc:** the self-cleaning claim — that an expired read genuinely removes the stale entry, not just reports it as gone — was verified live in a real browser, checking `localStorage` directly before and after. ## 1. The problem, restated Build `setWithTTL(key, value, ttlMs)` and `getWithTTL(key)` — a thin wrapper over `localStorage` where each stored value carries its own expiry time, and reading an expired value returns `null` while also genuinely removing the stale raw entry. ## 2. Clarifying questions a strong candidate asks | Question | Why it matters | | :--- | :--- | | Lazy cleanup (on read) or proactive (background sweep)? | Lazy is genuinely simpler and sufficient for most real use cases — worth naming the trade-off. | | Corrupted/invalid stored JSON? | A real, honest edge case — should fail gracefully, not throw and break the whole app. | | Global de

2.7k views

7 of 154

The problem

Problem, as an interviewer would state it: "Wrap localStorage so each stored item has a TTL (time to live). Reading an expired item should return null and actually clean it up, not just report it as missing while leaving stale data sitting in storage forever."

Examples:

Code

setWithTTL("session", "abc123", 100); // expires in 100ms
getWithTTL("session"); // "abc123" (still valid)
// after 150ms...
getWithTTL("session"); // null, AND the raw entry is genuinely removed from storage

Clarifying questions expected:

Should expired entries be cleaned up lazily (only when read) or proactively (a background sweep)?
What should happen if a stored value isn't valid JSON (corrupted or from an older, incompatible format)?
Is a global default TTL needed, or is TTL always specified per item?

Code / implementation expected: Yes — real, live-verified proof: a value reads correctly before expiry, reads as null after expiry, and the underlying raw localStorage entry is genuinely removed as a side effect of that expired read.

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 self-cleaning claim — that an expired read genuinely removes the stale entry, not just reports it as gone — was verified live in a real browser, checking localStorage directly before and after.

1. The problem, restated

Build setWithTTL(key, value, ttlMs) and getWithTTL(key) — a thin wrapper over localStorage where each stored value carries its own expiry time, and reading an expired value returns null while also genuinely removing the stale raw entry.

2. Clarifying questions a strong candidate asks

Question	Why it matters
Lazy cleanup (on read) or proactive (background sweep)?	Lazy is genuinely simpler and sufficient for most real use cases — worth naming the trade-off.
Corrupted/invalid stored JSON?

The solution is hidden so you can try first

6 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: a localStorage TTL wrapper correctly reads before expiry, returns null after, and genuinely self-cleans the raw entry — 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 7 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→

Wrap methods hook decorator

Continue