How do you decide whether a piece of state should live locally in a component or be shared more globally?

technical-conceptual · Junior level · software-engineering

What the interviewer is really asking

Tests judgment about scoping state to the smallest place that needs it and lifting or sharing it only when multiple components genuinely depend on it.

What to say

• Start with the default of keeping state as local as possible, in the component that owns it, because that limits re-renders and keeps the component easy to reason about.
• Explain you lift state up to a common ancestor when two or more components need to read or change the same value.
• Note that truly app-wide, low-frequency values like the logged-in user, theme, or locale are good candidates for shared mechanisms like context, while most state doesn't need to be global.

What to avoid

• Defaulting to a global store for everything 'to be safe', which adds complexity and unnecessary re-renders.
• Saying all state should always be local even when several components depend on it.
• Reaching for a heavy state library before understanding what actually needs to be shared.

Example answers

Strong: My default is to keep state local, in the component that uses it, so re-renders stay contained and the component is easy to follow. Once two sibling components need the same value, I lift it up to their closest common parent and pass it down. For things that are genuinely app-wide and change rarely, like the current user or the theme, I'll put it in context. But I don't make everything global by default, because that creates extra re-renders and indirection for state that only one component cares about.

Weak: I usually just put state in a global store like Redux so any component can grab it if it needs it later. That way I don't have to pass props around or lift things up.