Architecture scenarioMedium~10 minFrontend Foundations / 26 of 30

Interview question

How do you decide whether state belongs locally, in a parent, in the URL, in a cache, or in a shared store?

Choose React state ownership and lifetime

Places state according to who owns it, how long it must live, and whether the URL or server is the source of truth.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

I place state with the smallest owner that needs to coordinate it. Temporary input or an open panel can stay local. State shared by nearby siblings can move to their nearest common parent. Filters, sorting, pagination, or a selected record belong in the URL when users need refresh, back and forward navigation, or shareable links. Remote records belong in a server-data cache, while a shared store is useful for client state that spans distant features and has a clear lifecycle.

Full answer below

Practice focus

State ownership, lifetime, local state, lifted state, URL state, server state, context, global stores, and reset behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Many React problems are ownership problems presented as library choices. Putting every value in one global store can be as fragile as hiding shared workflow state deep inside a leaf component.
I place state with the smallest owner that needs to coordinate it. Temporary input or an open panel can stay local. State shared by nearby siblings can move to their nearest common parent. Filters, sorting, pagination, or a selected record belong in the URL when users need refresh, back and forward navigation, or shareable links. Remote records belong in a server-data cache, while a shared store is useful for client state that spans distant features and has a clear lifecycle.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I separate the value from copies of the value. Server data is not automatically global client state, and derived counts or filtered lists usually do not need storage. Context is useful for stable cross-tree dependencies such as theme or a feature-scoped controller, but frequent broad updates can rerender many consumers. Before lifting state, I define when it initializes, resets, persists, and becomes invalid. Those lifecycle rules prevent old drafts or selections from leaking into another user, tenant, or route.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make ownership visible in module boundaries and avoid multiple writable sources for the same fact. Authentication and permissions can be exposed to the UI for presentation, but the server remains authoritative. Cross-tab persistence, offline use, and navigation restoration add new owners and conflict rules; I would introduce them only when the product requires them. I would test remount, route change, logout, mutation, and server refresh because those transitions reveal whether state lives too long or disappears too early.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Putting every value in a global store by default.
Copying query data into separate writable component state.
Keeping shareable filters only in memory.
Leaving reset behavior to accidental remounting.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Two parts of the UI can write conflicting copies of one value.
A user or tenant switch preserves the previous draft.
Browser navigation does not reproduce the visible page state.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When should state move into the URL?
What is the difference between server state and client state?
When can context become too broad?

Continue the section

Next in Frontend Foundations: React Reducers

Step 27 of 30

Use a reducer for explicit React state transitions

Opening drill

Architecture scenarioMedium~10 minFrontend Foundations / 26 of 30

Interview question

How do you decide whether state belongs locally, in a parent, in the URL, in a cache, or in a shared store?

Choose React state ownership and lifetime

Places state according to who owns it, how long it must live, and whether the URL or server is the source of truth.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Full answer below

Practice focus

State ownership, lifetime, local state, lifted state, URL state, server state, context, global stores, and reset behavior.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Many React problems are ownership problems presented as library choices. Putting every value in one global store can be as fragile as hiding shared workflow state deep inside a leaf component.
I place state with the smallest owner that needs to coordinate it. Temporary input or an open panel can stay local. State shared by nearby siblings can move to their nearest common parent. Filters, sorting, pagination, or a selected record belong in the URL when users need refresh, back and forward navigation, or shareable links. Remote records belong in a server-data cache, while a shared store is useful for client state that spans distant features and has a clear lifecycle.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
I separate the value from copies of the value. Server data is not automatically global client state, and derived counts or filtered lists usually do not need storage. Context is useful for stable cross-tree dependencies such as theme or a feature-scoped controller, but frequent broad updates can rerender many consumers. Before lifting state, I define when it initializes, resets, persists, and becomes invalid. Those lifecycle rules prevent old drafts or selections from leaking into another user, tenant, or route.
Finish
Advanced answer
Optional deeper angle for production judgment and nuance.
In production I would make ownership visible in module boundaries and avoid multiple writable sources for the same fact. Authentication and permissions can be exposed to the UI for presentation, but the server remains authoritative. Cross-tab persistence, offline use, and navigation restoration add new owners and conflict rules; I would introduce them only when the product requires them. I would test remount, route change, logout, mutation, and server refresh because those transitions reveal whether state lives too long or disappears too early.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Putting every value in a global store by default.
Copying query data into separate writable component state.
Keeping shareable filters only in memory.
Leaving reset behavior to accidental remounting.

Red flagsCandidateSigns the approach is fragileSignals that an interviewer may treat as risky.Open details

Details

Two parts of the UI can write conflicting copies of one value.
A user or tenant switch preserves the previous draft.
Browser navigation does not reproduce the visible page state.

Follow-up prompts

Quick interviewer prompts inside this drill.

Follow-up questionsCandidateFollow-up questionsLikely next questions after the main answer.Open details

Details

Treat these as the next interviewer turn. Answer one out loud, then save the gap in your practice notes.

When should state move into the URL?
What is the difference between server state and client state?
When can context become too broad?

Continue the section

Next in Frontend Foundations: React Reducers

Step 27 of 30

Use a reducer for explicit React state transitions

How do you decide whether state belongs locally, in a parent, in the URL, in a cache, or in a shared store?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section

How do you decide whether state belongs locally, in a parent, in the URL, in a cache, or in a shared store?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue the section