Introduction to React

The Problem React Solves

Before you learn what React is, it is worth feeling the problem it was built for. Picture a shopping cart page written in plain JavaScript. The page shows a list of items, a count badge in the header, a subtotal at the bottom, and a Checkout button that must stay disabled while the cart is empty. Every time the user adds or removes a single item, you have to reach into the page and update four separate things by hand, in the right order, without forgetting any of them.

None of those four updates is difficult on its own. The difficulty is that the list of things to remember grows with every feature you add. Add a discount line and it becomes five places. Add a delivery estimate and it becomes six. Some weeks later a teammate adds a Remove All button, updates three of the six, and ships a page where the badge says 4 while the cart is visibly empty. This is the classic bug of hand-written DOM code: the screen and the data drift apart, and nothing in the code stops it.

There is a second, quieter problem. In that style of code the truth about the cart is scattered across the page itself. The count lives inside the badge's text, the total lives inside the subtotal element, and whether checkout is allowed lives in a button attribute. The page has become your data store. Reading your own application's state then means pulling text back out of HTML elements and converting it, which is as fragile as it sounds.

• Rewrite the item list in the DOM
• Update the count badge in the header
• Recalculate and rewrite the subtotal
• Enable or disable the Checkout button
• Repeat all of the above in every single function that can change the cart

<div class="cart">
  <h2>Cart <span id="badge">0</span></h2>
  <ul id="items"></ul>
  <p>Subtotal: Rs <span id="total">0</span></p>
  <button id="add">Add a Rs 250 notebook</button>
  <button id="clear">Remove all (buggy)</button>
  <button id="checkout" disabled>Checkout</button>
</div>

.cart { font-family: system-ui, sans-serif; max-width: 360px; }
button { margin: 4px 4px 0 0; padding: 6px 10px; }
#badge { background: #eee; border-radius: 10px; padding: 0 8px; }

// No React here. This is the hand-written style React replaces.
var items = [];

function addItem() {
  items.push({ name: 'Notebook', price: 250 });

  // Four separate updates, done by hand, every single time:
  document.getElementById('items').innerHTML =
    items.map(function (i) { return '<li>' + i.name + ' - Rs ' + i.price + '</li>'; }).join('');
  document.getElementById('badge').textContent = items.length;
  document.getElementById('total').textContent =
    items.reduce(function (sum, i) { return sum + i.price; }, 0);
  document.getElementById('checkout').disabled = items.length === 0;
}

function clearCart() {
  items = [];
  // Someone was in a hurry and updated only two of the four.
  document.getElementById('items').innerHTML = '';
  document.getElementById('total').textContent = '0';
  // badge and checkout are now LYING about the cart.
}

document.getElementById('add').onclick = addItem;
document.getElementById('clear').onclick = clearCart;

// Add two items, then click 'Remove all'. The badge still shows 2
// and Checkout is still enabled. Nothing crashed - the page simply
// stopped telling the truth. React exists to make this bug impossible.

Declarative: Describe the Result, Not the Steps

The code you just read is imperative. You spell out the steps: find this element, set that text, disable that button. React is declarative instead. You write a function that takes the current data and returns a description of what the page should look like for that data. You never write an instruction like change this element. You change the data, and React works out for itself which parts of the page no longer match the description and updates exactly those.

Look at the React version below. There is one source of truth, the items array. The badge, the list, the subtotal and the disabled state are all written as plain expressions derived from that array. It is now structurally impossible for the badge to disagree with the list, because the badge is not stored anywhere. It is calculated from items every time the component runs.

That single idea is most of what makes React worth learning. It shrinks the number of things you have to keep in your head from every place that displays the cart down to the cart itself. Everything else in this course, from props to hooks, exists to support that one arrangement.

// The same screen in React. Read it as: given these items,
// this is what the page looks like. No update instructions anywhere.
import { useState } from 'react';

function Cart() {
  const [items, setItems] = useState([]);

  const subtotal = items.reduce((sum, i) => sum + i.price, 0);

  function addItem() {
    setItems([...items, { id: crypto.randomUUID(), name: 'Notebook', price: 250 }]);
  }

  return (
    <div>
      <h2>Cart <span>{items.length}</span></h2>

      <ul>
        {items.map(item => (
          <li key={item.id}>{item.name} — ₹{item.price}</li>
        ))}
      </ul>

      <p>Subtotal: ₹{subtotal}</p>

      <button onClick={addItem}>Add a ₹250 notebook</button>
      <button onClick={() => setItems([])}>Remove all</button>
      <button disabled={items.length === 0}>Checkout</button>
    </div>
  );
}

// 'Remove all' empties one array. The badge, the list, the subtotal and
// the button all follow automatically, because none of them is stored.

Components: the Unit You Build With

A component is a JavaScript function that returns a piece of UI. That is the whole definition. A component can be as small as a styled button or as large as an entire page, and components nest inside each other exactly the way HTML elements do. A page is not one enormous file; it is a tree of small functions, each responsible for one visible thing.

This matters for two reasons. The first is reuse: once you have written a ProductCard, showing forty products is one loop, not forty copies of the same markup. The second, and more important in real projects, is isolation. When a card in a product grid is showing the wrong price, you know the bug lives in ProductCard or in the data handed to it. You are never searching a 2,000-line file for the one place that touched the DOM.

Components receive data from their parent through props, and they may keep private data of their own called state. Data flows one way, from parent down to child. A child can never reach up and edit its parent's data directly; if it needs to cause a change, the parent hands it a function to call. That restriction feels limiting for about a week, and then it starts saving you, because there are only ever a few possible sources for any value on screen.

// A component is a function that returns UI.
function ProductCard({ name, price }) {
  return (
    <div className="card">
      <h3>{name}</h3>
      <p>₹{price}</p>
      <button>Add to cart</button>
    </div>
  );
}

// Components nest, exactly like HTML elements do.
function ProductGrid() {
  const products = [
    { id: 'p1', name: 'Notebook', price: 250 },
    { id: 'p2', name: 'Gel pen set', price: 120 },
    { id: 'p3', name: 'Backpack', price: 1499 }
  ];

  return (
    <div className="grid">
      {products.map(p => (
        <ProductCard key={p.id} name={p.name} price={p.price} />
      ))}
    </div>
  );
}

• A component is a function whose name starts with a capital letter and which returns UI
• Components compose — you build big screens out of small, boring pieces
• Data comes in through props and is read-only inside the component
• Private, changeable data lives in state, and belongs to one component instance
• Data flows downward; to send something upward, the parent passes down a function

How React Actually Updates the Page

If your component re-runs from scratch whenever data changes, you might expect React to wipe the page and rebuild it, which would be slow and would throw away things like scroll position and the cursor inside a text box. It does not do that. React keeps a lightweight description of your UI in memory. When data changes it builds a fresh description, compares it against the previous one, and then applies only the differences to the real page.

So if a hundred-row table re-renders and only one cell's text changed, React updates one text node. Your component code is written as though everything is redrawn, which is what makes it simple to reason about, while the actual work done to the browser stays small. That in-memory description is what people mean when they say virtual DOM.

It is worth being honest about the limits of this, because React is often described as though it were magic. React makes DOM updates cheap; it does not make your own code cheap. If a component runs an expensive calculation on every render, or if a parent re-renders thousands of children unnecessarily, you can absolutely write a slow React app. A later lesson in this course deals with exactly that, and it starts with measuring rather than guessing.

React Is a Library, Not a Framework

React deliberately covers one job: turning data into UI and keeping the two in step. It ships with no router, no HTTP client, no form validation, no styling system and no opinion about how you organise your folders. A full framework like Angular hands you all of those in the box; React expects you to choose them.

This is a genuine trade-off, not a marketing point. The upside is that you can pick the right tool for each job and swap any of them later without abandoning React. The downside is that a beginner faces a pile of decisions before writing a line of feature code, and every tutorial they read makes different ones. The list below is the conventional set of choices; this course uses them so that you are learning the combination you will actually meet in internships and open-source projects.

• Build tool — Vite, which compiles your JSX and runs the dev server
• Routing — React Router, for turning URLs into screens
• Data fetching — the built-in fetch to start with; TanStack Query or SWR in larger apps
• Styling — plain CSS, CSS Modules, or a utility framework such as Tailwind CSS
• Types — TypeScript, once a project grows past a few screens
• Full framework on top — Next.js, if you need server rendering, routing and builds handled for you

What You Need Before You Start

React is not a new language. It is ordinary JavaScript with one piece of syntax bolted on, and a set of rules about where you may call certain functions. That means most of the confusion beginners hit in React is not React confusion at all — it is JavaScript confusion arriving in unfamiliar clothes. If map, destructuring and the spread operator are shaky for you, React will feel like magic and then like nonsense.

The list below is the honest prerequisite set. You do not need to be expert at any of them, but you should be able to read each one without stopping. Everything else you need, this course teaches as it comes up.

One piece of study advice, because it changes outcomes more than any tip about React itself: type the examples out rather than copying them, and then deliberately break them. Delete a key and read the warning. Remove a dependency array and watch what happens. The error messages React prints are unusually good, and learning to read them is a large part of becoming productive.

• Arrow functions, and the fact that they are just values you can pass around
• Destructuring objects and arrays, including in function parameters
• The spread operator for copying arrays and objects — used constantly in React
• Array methods, especially map, filter and reduce
• Template literals, and the difference between an expression and a statement
• ES modules — import and export
• Promises and async/await, for the data-fetching lessons
• Comfortable HTML and CSS, since JSX is mostly HTML with different spelling