Architecture Walkthrough

Declarative Programming Model

React's core value proposition is declarative UI. In an imperative approach, you write step-by-step instructions to mutate the DOM when data changes: find the element, check its current value, update the text, toggle the class. Every piece of interactive UI requires code that manages state and DOM mutations together, and the DOM becomes the single source of truth.

In React, you describe what the UI should look like given the current state. When state changes, React calls your component function again and you return the new description. React figures out what DOM mutations are necessary. Your code never manually touches the DOM; it only describes the desired output. The benefit is that complex UIs remain predictable: you read the component function and know exactly what will be rendered for any given state input.

The Virtual DOM

Direct DOM manipulation is expensive because any DOM read or write can force the browser to recalculate layout, which is slow. React addresses this by maintaining a virtual DOM: a lightweight JavaScript representation of the DOM tree. When state changes, React computes a new virtual DOM tree, compares it against the previous one (diffing), and computes the minimum set of real DOM mutations needed to bring the DOM in sync with the new description.

The virtual DOM is not always faster than direct DOM manipulation for any single operation. Its advantage is that it batches and minimizes mutations, making complex updates more predictable than hand-written imperative DOM code, especially as application complexity grows. The mental model (describe the UI, React handles the DOM) also produces fewer bugs than manual DOM management.

Component-Based Architecture

React applications are trees of components. Each component is a function that takes props as input and returns JSX as output. Components are composable: a complex UI is built by combining smaller components. Each component manages its own concerns: its structure, its local state, its styles, its event handling. A well-designed component has one responsibility and can be reused anywhere the same UI element is needed.

This composability is what gives React applications their structure. Large screens decompose into smaller sections, which decompose into individual components, each independently testable and reusable.

Key Code Explained

// Imperative: manually updating the DOM when data changes
let count = 0;
const button = document.querySelector('#increment');
const display = document.querySelector('#count');

button.addEventListener('click', () => {
  count++;
  display.textContent = count; // manually finding and updating the DOM node
});


// Declarative (React): describe the output, React handles the DOM
function Counter() {
  const [count, setCount] = useState(0);

  // No DOM manipulation. React calls this function again when count changes
  // and reconciles the output with the previous render.
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount((c) => c + 1)}>Increment</button>
    </div>
  );
}


// Component composition: building complex UI from simple parts
function App() {
  return (
    <Layout>
      <Header title="IOCombats" />
      <main>
        <QuestionList questions={questions} />
      </main>
      <Footer />
    </Layout>
  );
}

// React's internal flow (simplified):
// 1. State changes: setCount is called
// 2. Render phase: Counter() is called, returns new virtual DOM
// 3. Diff: new vDOM is compared to previous vDOM
// 4. Commit: only changed DOM nodes are updated (minimal mutations)
// 5. Browser repaints the updated portion of the screen


// React (library) vs Next.js (framework)
// React provides:        useState, useEffect, component model, reconciler
// Next.js adds:          file-based routing, server-side rendering, static generation,
//                        API routes, image optimization, middleware, build system

The setCount(c => c + 1) updater form is used here instead of setCount(count + 1) because event handlers close over the state value at render time. If multiple updates are batched, the updater form ensures each update receives the latest queued state rather than a stale snapshot from the last render.

Tradeoffs

What Interviewers Actually Check

• Whether you can explain declarative vs imperative with a concrete example
• Whether you know the virtual DOM is a JavaScript representation and why it exists
• Whether you can describe reconciliation at a high level: render, diff, commit
• Whether you know React is a library (not a framework) and what the distinction means
• Whether you can explain component composition as a design principle

Follow-Up Questions

1. How does React Native use React's declarative model to render mobile UIs instead of DOM elements?
2. What is React's scheduler and how does it prioritize rendering work in React 18?
3. How does React's server component model (React 19) change the rendering model from what you described?
4. What are the alternatives to the virtual DOM approach (Svelte compiles away the virtual DOM; Solid uses fine-grained reactivity)?
5. When would direct DOM manipulation still be appropriate in a React application?

Common Candidate Mistakes

• Describing React as a full framework instead of a view library
• Saying the virtual DOM is always faster than direct DOM manipulation (it is a batching optimization, not a raw-speed guarantee)
• Confusing React's virtual DOM with the browser's shadow DOM (they are unrelated concepts)
• Not knowing what Next.js, Remix, or similar tools add on top of React
• Being unable to contrast declarative and imperative code with a concrete example

Interview Readiness Checklist

Before you leave this question, make sure you can answer:

• Can you explain declarative vs imperative programming with a simple React example?
• Can you describe what the virtual DOM is and what problem it solves?
• Can you describe the reconciliation process: render to virtual DOM, diff, commit to real DOM?
• Can you distinguish React the library from Next.js or Remix as frameworks?
• Can you explain component-based architecture and why it enables reuse and composition?

Summary

React is a JavaScript library for building user interfaces. It handles only the view layer: describing what the UI should look like and updating the DOM efficiently when data changes. Routing, data fetching, and server integration are left to frameworks (Next.js, Remix) or external libraries.

React's core model is declarative: you write components that return a description of the UI for a given state, and React handles all DOM mutations. When state changes, React renders the component again, diffs the new output against the previous output using the virtual DOM, and applies only the necessary real DOM mutations. This batch-and-minimize approach makes complex interactive UIs more predictable and maintainable than imperative DOM code.

The component model is React's architectural contribution: complex UIs decompose into trees of simple, reusable components, each with a single responsibility. A component receives props as input and returns JSX as output. State held inside a component triggers re-renders when it changes. State shared between components lives in the closest common ancestor and flows down as props. These three ideas, declarative rendering, the virtual DOM, and component composition, are the core of what React is.