React solves predictable UI rendering from state with a component model and reconciliation. It does not provide routing, data fetching, or state management out of the box. This clarity guides architecture decisions; the trade-off is adding routing or state libraries and testing their integration.
What core problem does React solve, and what does it deliberately NOT solve?
Preparing for interviews?
Use guided tracks for structured prep, then practice company-specific question sets when you want targeted interview coverage.
Quick Answer
Answer
Core idea
React solves one main problem: reliably keeping the UI in sync with changing data (state/props/context) without manually mutating the DOM. It gives you a component model + a declarative rendering system so you describe what the UI should look like, and React figures out how to update the DOM efficiently.
Problem in UI apps | What React provides | Why it matters |
|---|---|---|
Manual DOM updates become complex and bug-prone | Declarative rendering (re-render components from current inputs) | Reduces “UI out of sync” bugs |
Hard to structure large UIs | Components (composition + reuse + isolation) | Scales UI development and ownership |
Frequent updates can be expensive | Reconciliation + efficient commits | Avoids unnecessary DOM work |
State changes need predictable flow | Unidirectional data flow (props down, events up) | Makes changes easier to trace/debug |
JSX
import { useState } from 'react';
export default function Counter() {
const [count, setCount] = useState(0);
// No manual DOM updates.
// UI is a pure result of current state.
return (
<button onClick={() => setCount((c) => c + 1)}>
Count: {count}
</button>
);
}
What React deliberately does NOT solve
React is intentionally a UI library, not a full framework. It avoids forcing a single “one true way” for the rest of the app (routing, data, architecture), so teams can choose what fits their needs.
Concern | React's stance | What you typically add |
|---|---|---|
Routing | Not included | A router (client-side or framework routing) |
Data fetching / server state | Not included (useEffect exists, but no fetching strategy) | A data-fetching/cache approach (query library or framework) |
Global state architecture | Not prescribed (Context exists, but not a full store pattern) | Store pattern/library (or colocated state + lifting) |
Forms and validation | Not included | Form library or custom form architecture |
Styling approach | Not included | CSS Modules / CSS-in-JS / utility CSS / design system |
Build tooling / bundling / SSR | Not included | A build tool or a React framework (for SSR/SSG, routing, etc.) |
Interview framing
Say it like this: React owns rendering and component composition. Everything else is a product decision: choose a stack around React (router, data strategy, state strategy, build/SSR). The trade-off is flexibility vs having to assemble your own opinionated architecture.
Practical scenario
Building a dashboard, React handles UI state and rendering while you choose routing and data-fetching libraries for navigation and cache.
Common pitfalls
- Expecting React to provide routing or global state out of the box.
- Mixing view state with server-cache concerns.
- Ignoring performance and testing needs for large component trees.
The lean core is flexible but requires architecture decisions. Test by listing missing pieces (routing, data fetching, auth) before you build.
Summary
React solves: predictable UI updates from state using declarative components + reconciliation. React does NOT solve: routing, data fetching strategy, global state architecture, forms, styling, or build/SSR tooling — those are intentionally left to the ecosystem.
Similar questions
Guides