ReactJS Essentials

react.dev (opens new window) (formerly reactjs.org (opens new window))

What is it

React is a library for building user interfaces, not a whole framework. It does not prescribe routing, data fetching, or project structure; those come from other packages or from your own code.

The core idea is declarative UI: you describe the interface as a function of props and state, and React updates the DOM to match. Compare with the manual DOM code from lecture 2, where every change requires finding nodes and mutating them yourself.

function Greeting(props: { name: string }) {
  return <h1>Hello, {props.name}</h1>;
}

When name changes, React re-renders the component and updates only what differs. You never call document.createElement or textContent = for this.

Render and commit

React works in two phases:

1. Render: React calls your components to compute a new description of the UI (a virtual tree).
2. Commit: React applies the differences to the real DOM.

Comparing the new tree with the previous one is called reconciliation. The virtual tree makes updates predictable and composable, not "always faster" than hand-written DOM code—a poorly structured React app can still be slow. Render functions must be pure: same props and state in, same description out, with no side effects during render.

Components, props, state

• Props are inputs passed by the parent; the child treats them as read-only.
• State is data a component owns and can change; changing state triggers a re-render.
• Composition: small components nest into larger ones via children and props.

Thinking in React

Thinking in React (opens new window) is the canonical process for turning a UI plus its data into a component design: draw the hierarchy, decide what is state, and place that state correctly. Five steps:

1. Break the UI into a component hierarchy matching the mockup's structure.
2. Build a static version that renders from props only—no state yet.
3. Identify the minimal complete set of UI state: exclude props, constants, and anything derivable (filtered results, counts).
4. Find where the state should live: the common parent of every component that needs it.
5. Add inverse data flow: children request changes through callbacks instead of mutating the parent's data.

Worked example—a product search screen:

FilterableProductTable
├── SearchBar
└── ProductTable
    └── ProductRow (per product)

Value	Kind	Why
products	props	passed in by the parent/caller
filterText, inStockOnly	state	change over time, cannot be computed
visibleProducts, visibleCount	derived	computed from products + filters during render

FilterableProductTable owns filterText and inStockOnly, passes products and the derived visibleProducts down to ProductTable, and hands SearchBar the current values plus onChange callbacks—see components and lifting state up.

One-way data flow (Flux idea)

Data flows in one direction: an event (click, fetch response) updates the state owner, React re-renders, and new props flow down to children. Children never mutate the parent's data directly; they ask via callbacks.

Flux is an architectural pattern built on this idea (a store holds state, actions describe changes). Redux—covered in lecture 6—is a state-management library inspired by Flux rather than a literal implementation of it.

Functions vs classes

Modern React uses function components with hooks (useState, useEffect, useRef). Class components (React.Component with setState and lifecycle methods) are still supported and remain in many existing applications, so you need to read both. New code should prefer functions and hooks.

Learning path

1. Components and JSX: TSX syntax, typed props, composition, lists and keys.
2. State and events: useState, event handlers, immutable updates, controlled inputs, class setState.
3. Effects and refs: useEffect, cleanup, fetching data, useRef for DOM access.
4. Tooling and routing: TypeScript + Webpack setup for React 18, createRoot, React Router v6.
5. Pet project: rewrite task 3 as a React application.

Thinking in React (opens new window)