What is React and How Does It Work?

React is the “R” in MERN and the technology that controls everything the user sees and interacts with in the browser. It is a JavaScript library for building user interfaces, maintained by Meta (Facebook) and open-source contributors. React’s defining idea is simple but powerful: describe what the UI should look like for a given application state, and let React figure out the minimum set of DOM changes needed to make the browser match that description. This declarative approach — combined with a component model that makes UI pieces reusable — is what makes React so productive for building the kind of dynamic, data-driven interfaces that MERN applications require.

React in the MERN Stack #

How React Works — The Mental Model #

Traditional (Imperative) UI — jQuery / vanilla JS:
  1. User clicks "Load Posts"
  2. You write code: find the list element, clear it, fetch data,
     create new elements, append them one by one
  3. You manually manage every DOM change

React (Declarative) UI:
  1. You describe: "When posts = [...], render a <ul> with one <li> per post"
  2. User clicks "Load Posts" → state changes to posts = [{ title: '...' }, ...]
  3. React automatically re-renders and updates only the changed DOM nodes
  4. You never touch the DOM directly — React handles it

The Virtual DOM #

How React updates the UI efficiently:

Step 1: State changes (e.g. posts array updated with new data)
        │
        ▼
Step 2: React re-renders the component in memory
        (creates a new Virtual DOM — a lightweight JS object tree)
        │
        ▼
Step 3: React "diffs" the new Virtual DOM against the previous one
        (finds the exact minimum set of changes needed)
        │
        ▼
Step 4: React applies ONLY those changes to the real browser DOM
        (e.g. adds 3 new <li> elements — does not rebuild the whole list)
        │
        ▼
Step 5: Browser paints the changes — user sees the updated UI

Result: Fast, predictable updates even in complex, large UIs

Component-Based Architecture #

Every piece of a React UI is a component — a JavaScript function that accepts data (props) and returns JSX describing what to render. Components are composable: you build complex interfaces by nesting simpler components.

// A simple React component — a function that returns JSX
function PostCard({ title, author, createdAt }) {
  return (
    <div className="post-card">
      <h2>{title}</h2>
      <p>By {author} · {new Date(createdAt).toLocaleDateString()}</p>
    </div>
  );
}

// Composing components — PostList uses PostCard
function PostList({ posts }) {
  return (
    <ul className="post-list">
      {posts.map(post => (
        <PostCard
          key={post._id}
          title={post.title}
          author={post.author.name}
          createdAt={post.createdAt}
        />
      ))}
    </ul>
  );
}

React vs Other Frontend Approaches #

React’s Data Flow #

// React data flows DOWN through props, events flow UP through callbacks

// Parent component — owns the state and the data
function BlogPage() {
  const [posts, setPosts] = React.useState([]);
  const [loading, setLoading] = React.useState(true);

  React.useEffect(() => {
    // Fetch posts from the Express API
    fetch('/api/posts')
      .then(res => res.json())
      .then(data => { setPosts(data.data); setLoading(false); });
  }, []);

  const handleDelete = (postId) => {
    // Update local state after deletion — no page reload
    setPosts(prev => prev.filter(p => p._id !== postId));
  };

  if (loading) return <p>Loading...</p>;

  return (
    <div>
      <h1>Blog</h1>
      {posts.map(post => (
        // Data flows DOWN as props
        // Events flow UP as callbacks (onDelete)
        <PostCard key={post._id} post={post} onDelete={handleDelete} />
      ))}
    </div>
  );
}

Common Mistakes #

Mistake 1 — Treating React like jQuery (imperative DOM manipulation) #

❌ Wrong — manually touching the DOM inside React components:

function Counter() {
  const handleClick = () => {
    document.getElementById('count').textContent = '1'; // direct DOM manipulation
  };
  return <div><span id="count">0</span><button onClick={handleClick}>+</button></div>;
}

✅ Correct — use state to describe the desired UI and let React update the DOM:

function Counter() {
  const [count, setCount] = React.useState(0);
  return <div><span>{count}</span><button onClick={() => setCount(c => c + 1)}>+</button></div>;
}

Mistake 2 — Confusing React with Next.js or Remix #

❌ Wrong — expecting React to provide server-side rendering, file-based routing, or API routes out of the box.

✅ Correct — plain React (via Vite) produces a client-side single-page application. Next.js and Remix are React-based frameworks that add SSR, routing, and server features on top. For this MERN series, plain Vite + React is the right choice — the Express API handles the server side.

Mistake 3 — Calling the API directly from every component #

❌ Wrong — scattered API calls across many components:

// PostCard.jsx — makes its own API call
function PostCard({ postId }) {
  useEffect(() => { fetch(`/api/posts/${postId}`).then(...) }, [postId]);
}

✅ Correct — centralise API calls in a service layer or a parent component and pass data down as props. Keep components focused on rendering, not data fetching.

Quick Reference #