What is React & How It Works

LinkedIn Hook

Most developers say "React is a JavaScript framework." That single word — "framework" — can cost you the interview before it even starts.

React is a library, and the distinction matters more than you think. Interviewers use this as a litmus test: if you don't know the difference, what else don't you know?

In Lesson 1.1, you'll learn exactly what React is, the problem it was built to solve, and the 4 core ideas behind it — explained so clearly you'll never fumble this question again.

Read the full lesson → [link]

#React #JavaScript #WebDevelopment #FrontendDevelopment #InterviewPrep

---

---

What You'll Learn

• The real difference between a library and a framework — and why React is a library
• How component-based architecture works and why it changed frontend development
• Declarative vs imperative programming with concrete code comparisons
• One-way data flow and the problem React was specifically built to solve

---

The LEGO Analogy — Think Before You Code

Imagine you're building a house out of LEGO bricks. Each brick is small, self-contained, and reusable. You don't build the entire house as one massive molded piece — you snap together individual bricks, and each brick doesn't care what the rest of the house looks like.

That's React.

Each component is a LEGO brick. It manages its own appearance and behavior. You compose them together to build entire interfaces. If one brick breaks or needs replacing, you swap it out without tearing down the whole house.

Before React, building a web app felt more like sculpting from clay — everything was connected, intertwined, and fragile. Change one thing, and cracks appeared everywhere.

---

Library vs Framework — The Interview Gatekeeper

This is the question interviewers use to filter candidates in the first 60 seconds.

A framework tells you how to structure your entire application. It controls the flow — you fill in the blanks. Angular, for example, dictates your folder structure, routing, HTTP layer, dependency injection, and testing approach. The framework calls your code.

A library gives you tools and gets out of the way. You call it when you need it, and you decide everything else — routing, state management, folder structure, build tools. Your code calls the library.

React is a UI library. It does exactly one thing: build user interfaces from components. Everything else — routing (React Router), state management (Redux, Zustand), HTTP requests (Axios, fetch) — is a separate choice you make.

The Hollywood Principle: Frameworks follow "Don't call us, we'll call you." Libraries follow "Call us whenever you need us." React follows the library pattern.

Why This Matters in Interviews

When you say "React is a framework," interviewers hear: "This person memorized buzzwords but doesn't understand architecture decisions." When you say "React is a library focused on the view layer, and I choose my own tools for the rest," interviewers hear: "This person understands system design."

+-----------------------------------------------------+
|                    FRAMEWORK (Angular)               |
|  +----------+ +--------+ +-------+ +-------------+  |
|  | Routing  | | HTTP   | | Forms | | DI Container |  |
|  +----------+ +--------+ +-------+ +-------------+  |
|  +----------+ +--------+ +-------+ +-------------+  |
|  | Testing  | | State  | | i18n  | | Animation    |  |
|  +----------+ +--------+ +-------+ +-------------+  |
|                 YOU fill in the gaps                  |
+-----------------------------------------------------+

+------------------+   +--------+   +----------+
|  React (Library) |   | Router |   | State Mgmt|
|  UI Components   |   | (pick) |   |  (pick)   |
+------------------+   +--------+   +----------+
       YOU assemble the pieces yourself

Napkin AI Visual Prompt: "Dark gradient (#0d1117 → #161b22). Two side-by-side boxes. Left box labeled 'Framework' in neon pink (#ff2d55), filled with connected modules. Right side shows separate floating blocks labeled 'React', 'Router', 'State' in React blue (#61dafb), arranged freely. White monospace labels. Title: 'Library vs Framework'."

---

Component-Based Architecture — Everything is a Component

Before React, developers built pages. With React, you build components that assemble into pages.

A component is a self-contained piece of UI that:

1. Has its own markup (what it looks like)
2. Has its own logic (how it behaves)
3. Has its own data (what it knows)
4. Can be reused anywhere

Example: Breaking a Page into Components

// A page is just components composed together
function App() {
  return (
    <div>
      <Header />        {/* Navigation, logo */}
      <SearchBar />     {/* Input field, search button */}
      <ProductList />   {/* Grid of product cards */}
      <Footer />        {/* Links, copyright */}
    </div>
  );
}

// Each component is independent and reusable
function Header() {
  return (
    <header>
      <h1>My Store</h1>
      <nav>
        <a href="/home">Home</a>
        <a href="/cart">Cart</a>
      </nav>
    </header>
  );
}

// Components can be nested — ProductList contains ProductCard
function ProductList() {
  return (
    <div className="grid">
      <ProductCard name="Laptop" price={999} />
      <ProductCard name="Phone" price={699} />
      <ProductCard name="Tablet" price={499} />
    </div>
  );
}

// A reusable component — same component, different data
function ProductCard({ name, price }) {
  return (
    <div className="card">
      <h2>{name}</h2>
      <p>${price}</p>
    </div>
  );
}

Output (rendered HTML):

My Store
Home | Cart

[Laptop - $999]  [Phone - $699]  [Tablet - $499]

Footer content

The key insight: ProductCard is written once and used three times with different data. Change the card design once, and it updates everywhere.

Napkin AI Visual Prompt: "Dark gradient (#0d1117 → #161b22). A tree diagram showing App at the top in React blue (#61dafb), branching down to Header, SearchBar, ProductList, Footer. ProductList further branches into three ProductCard nodes highlighted in neon pink (#ff2d55). White monospace labels. Title: 'Component Tree'."

---

Declarative vs Imperative — Describe What, Not How

This concept separates React developers who understand the mental model from those who just write code that works.

Imperative programming means you write step-by-step instructions for how to do something. You tell the computer every single action.

Declarative programming means you describe what you want the result to look like, and the tool figures out how to get there.

The Restaurant Analogy

• Imperative: "Walk to the kitchen. Open the fridge. Take out chicken. Preheat oven to 375. Season the chicken. Place it on a baking sheet. Put it in the oven. Set a timer for 45 minutes..."
• Declarative: "I'd like roasted chicken, please." The chef (React) figures out the steps.

Code Comparison

// IMPERATIVE — Vanilla JavaScript
// You tell the browser every step manually

// Step 1: Find the container
const container = document.getElementById("app");

// Step 2: Create an element
const heading = document.createElement("h1");

// Step 3: Set the text
heading.textContent = "Hello, World!";

// Step 4: Set a class
heading.className = "title";

// Step 5: Attach it to the page
container.appendChild(heading);

// Step 6: Later, to update it...
heading.textContent = "Hello, React!"; // Manually find and mutate

// DECLARATIVE — React
// You describe what the UI should look like, React handles the DOM

function Greeting({ name }) {
  // Just describe the result — React figures out the DOM operations
  return <h1 className="title">Hello, {name}!</h1>;
}

// When `name` changes from "World" to "React",
// React automatically figures out that only the text node needs updating.
// You never touch the DOM yourself.

// Output when name="World":  <h1 class="title">Hello, World!</h1>
// Output when name="React":  <h1 class="title">Hello, React!</h1>

The imperative version has 6 steps to put text on a screen — and that's a trivial example. In a real app with hundreds of dynamic elements, imperative DOM manipulation becomes a tangled mess of getElementById, createElement, appendChild, and manual state tracking.

React's declarative approach means: "Given this data, here's what the UI should look like." React handles the rest.

---

One-Way Data Flow — The Predictability Principle

In React, data flows in one direction: parent to child, through props. This is called unidirectional data flow.

     +--------+
     |  App   |  (owns the data)
     +---+----+
         |
    passes data down via props
         |
   +-----+------+
   |            |
+--+---+   +---+--+
|Header|   | List |  (receive data, cannot modify parent's data)
+------+   +--+---+
               |
          +----+----+
          |         |
       +--+--+  +--+--+
       |Item |  |Item |  (receive data from List)
       +-----+  +-----+

Why One-Way?

Before React, two-way data binding (like early Angular) meant the UI and the data could update each other freely. This sounds convenient until your app grows:

• A form field updates a model
• The model triggers a controller update
• The controller updates another model
• That model updates a different view
• That view triggers another change...

Debugging this is like untangling a plate of spaghetti. You can't trace where a change started.

React's one-way flow creates a predictable chain: State changes → Component re-renders → UI updates. If something goes wrong, you trace the data down the tree. That's it.

// One-way data flow in action
function App() {
  const [username, setUsername] = React.useState("Alice");

  // Data flows DOWN to child via props
  // Events flow UP via callback functions
  return (
    <div>
      <Display name={username} />
      <EditButton onRename={setUsername} />
    </div>
  );
}

// Child receives data — it cannot modify `username` directly
function Display({ name }) {
  return <p>Current user: {name}</p>;
}

// Child can REQUEST a change by calling the callback
function EditButton({ onRename }) {
  return (
    <button onClick={() => onRename("Bob")}>
      Rename to Bob
    </button>
  );
}

// Output initially:       Current user: Alice  [Rename to Bob]
// Output after click:     Current user: Bob    [Rename to Bob]

Notice: Display never modifies username. EditButton never modifies username. They call onRename (which is actually setUsername from the parent), and the parent decides what happens. Data always flows down. Change requests always flow up.

Napkin AI Visual Prompt: "Dark gradient (#0d1117 → #161b22). A vertical flowchart: 'State' box at top in React blue (#61dafb) with downward arrows labeled 'props' connecting to child component boxes. Upward dashed arrows in neon pink (#ff2d55) labeled 'callbacks' going from children back to state. White monospace text. Title: 'One-Way Data Flow'."

---

Why React Exists — The Problem It Solves

React wasn't created because JavaScript was boring. It was created because Facebook's UI was breaking.

The Problem (2011-2013)

Facebook's notification system had a persistent bug: the notification count badge would show unread messages even after you'd read them. The badge, the chat panel, and the notification dropdown all showed different numbers — because they were all tracking the same data independently with imperative DOM updates.

The engineering team realized the root cause wasn't bad code. It was a bad architecture. When multiple parts of a UI depend on the same data and each one manually manages its own DOM, they inevitably fall out of sync.

React's Solution

React introduced three ideas that solved this:

1. Components — Each piece of UI is isolated and manages its own rendering
2. Declarative rendering — You describe the result, React handles the DOM updates
3. Single source of truth — Data lives in one place and flows down. No duplicate state tracking.

The notification bug becomes impossible in React. The unread count lives in one state. Every component that needs it receives it through props. When the count changes, every component automatically shows the correct value.

// The Facebook notification problem — solved with React's model
function App() {
  const [unreadCount, setUnreadCount] = React.useState(3);

  const markAllRead = () => setUnreadCount(0);

  // One source of truth, multiple consumers
  return (
    <div>
      <NavBadge count={unreadCount} />
      <ChatPanel count={unreadCount} />
      <NotificationDropdown count={unreadCount} onReadAll={markAllRead} />
    </div>
  );
}

// All three components ALWAYS show the same number
// because they all read from the same source
function NavBadge({ count }) {
  return <span className="badge">{count > 0 ? count : ""}</span>;
}

function ChatPanel({ count }) {
  return <div>Unread messages: {count}</div>;
}

function NotificationDropdown({ count, onReadAll }) {
  return (
    <div>
      <p>{count} unread notifications</p>
      <button onClick={onReadAll}>Mark all as read</button>
    </div>
  );
}

// Output: Badge shows "3", Chat shows "Unread messages: 3",
//         Dropdown shows "3 unread notifications"
// After clicking "Mark all as read":
//         Badge shows "", Chat shows "Unread messages: 0",
//         Dropdown shows "0 unread notifications"
// They can NEVER be out of sync.

---

Common Mistakes

• Calling React a framework. React is a library for building UIs. It doesn't provide routing, HTTP handling, or folder structure — you choose those separately. Saying "framework" in an interview signals a surface-level understanding.

• Confusing declarative with "less code." Declarative doesn't mean shorter code. It means you describe the desired output state rather than the step-by-step mutations. Sometimes declarative code is actually longer — but it's more predictable and maintainable.

• Thinking one-way data flow means children can never communicate with parents. Children can't modify parent state directly, but they can call callback functions passed as props. The data still flows one way — the parent decides how to handle the request.

---

Interview Questions

1. What is React, and why is it called a library instead of a framework?

(Covered in the Library vs Framework section above.)

2. Explain the difference between declarative and imperative programming. Which approach does React use and why?

(Covered in the Declarative vs Imperative section above.)

3. What problem was React originally built to solve?

(Covered in the Why React Exists section above.)

4. What does "one-way data flow" mean in React? How does data move between components?

(Covered in the One-Way Data Flow section above.)

5. Can you name two things React does NOT provide out of the box that a framework like Angular does?

React does not provide a built-in routing solution (you need React Router or similar) or a built-in HTTP client (you use fetch, Axios, or another library). It also doesn't include form validation, dependency injection, or an opinionated project structure. These are all separate choices the developer makes.

---

Quick Reference — Cheat Sheet

Concept	Key Point
React is a...	Library (not a framework) — focused on the UI layer
Core idea	Build UIs from reusable, composable components
Rendering model	Declarative — describe what the UI should look like, not how to update it
Data flow	One-way (parent → child via props)
Change requests	Children call callbacks passed from parents
Created by	Facebook (2013) — to fix UI sync bugs
Solves	Keeping UI in sync with data without manual DOM manipulation

+--------------------------------------+
|          React Mental Model          |
+--------------------------------------+
|                                      |
|   State (single source of truth)     |
|       |                              |
|       v                              |
|   Component (declarative render)     |
|       |                              |
|       v                              |
|   UI (automatically in sync)         |
|                                      |
|   Data flows DOWN (props)            |
|   Events flow UP (callbacks)         |
|                                      |
+--------------------------------------+

---

Next: Lesson 1.2 — Virtual DOM & Reconciliation →

---

This is Lesson 1.1 of the React Interview Prep Course — 10 chapters, 42 lessons.