Plain JavaScript can absolutely build interactive pages — the JS course covered exactly that, manipulating the DOM directly with document.querySelector and friends. React is a library that changes how you build that interactivity: instead of writing step-by-step instructions for changing the DOM, you describe what the UI should look like for a given set of data, and React figures out the DOM changes needed to make that true.

The Problem React Solves

As an interface grows, manually keeping the DOM in sync with your application's data gets messy fast — every place a value changes, you have to remember every DOM element that depends on it and update each one by hand. React lets you write declarative UI code instead: "this is what the page looks like when count is 5" rather than "go find the counter element and change its text to 5." When the data changes, React re-renders the description and patches only the parts of the real DOM that actually changed.

JSX — HTML-Like Syntax Inside JavaScript

That <h1>Hello, world!</h1> isn't a string and isn't real HTML — it's JSX, a syntax extension that lets you write markup directly inside JavaScript. A build tool (covered below) compiles it down to plain JavaScript function calls before it ever runs in the browser. JSX looks like HTML but follows JavaScript's rules underneath, which leads to a few differences worth knowing immediately:

• className instead of class — class is a reserved word in JavaScript, so JSX uses the DOM property name instead.
• Curly braces { } drop back into plain JavaScript inside the markup — {name} embeds the variable's value.
• A component must return a single root element — wrap multiple sibling elements in one parent <div> (or a "fragment," <>...</>, when you don't want an extra DOM element).
• Every tag must be closed — <img />, not <img>, even for elements that are self-closing in plain HTML.

The Virtual DOM, Briefly

Each time a component's data changes, React builds a lightweight in-memory description of what the UI should look like — the virtual DOM — compares it against the previous version, and applies only the differences to the real, much slower-to-update browser DOM. You don't write any of this comparison logic yourself; it's the mechanism that makes the declarative style from earlier actually fast in practice. The chapters ahead focus entirely on the part you do write: describing what the UI should look like.

Setting Up a Project with Vite

Vite is the current standard tool for starting a new React project — it sets up the JSX-compiling build step, a fast local dev server with live reload, and a production build command, all with one starting command:

npm run dev starts a local server (usually at http://localhost:5173) that automatically refreshes the browser whenever a file is saved. A fresh Vite + React project includes a few starter files worth knowing immediately:

• src/main.jsx — the entry point; renders the top-level <App /> component into the page's <div id="root">.
• src/App.jsx — the starter component you'll edit first; this is where the demo counter button lives by default.
• index.html — the one real HTML file in the whole project; everything else gets rendered into it by React.

A Minimal Component, Start to Finish

export default App; makes this component importable from other files — main.jsx imports and renders it. Replacing the contents of App.jsx with the snippet above and saving is enough to see it appear instantly in the browser, thanks to Vite's live reload.

Coding Challenges

Chapter 1's Footer component was useful, but completely static — every instance of it renders the exact same text. Props (short for "properties") are how a parent component passes data into a child component, the same way a function takes arguments. This is what turns a one-off component into something genuinely reusable.

Passing Props from a Parent

Attributes written on a component tag — name="Philip" — become a single props object passed as the function's first parameter. Greeting reads props.name to render different text each time it's used, without needing to be rewritten. The two <Greeting /> elements above render "Hello, Philip!" and "Hello, Sam!" from the exact same component definition.

Destructuring Props

Writing { name, age } directly in the parameter list destructures the props object, pulling out name and age as standalone variables. This is the convention used in almost all real React code — it reads more clearly than repeating props. in front of every value, and makes it obvious at a glance exactly which props a component expects.

Passing Different Types of Data

A string prop uses plain quotes (title="Keyboard"), but any other JavaScript value — numbers, booleans, arrays, objects, even other components — needs curly braces instead: price={49.99}, not price="49.99" (which would pass the string "49.99" rather than an actual number).

Default Prop Values

Ordinary JavaScript default-parameter syntax works directly in a destructured props parameter: color = "blue" supplies a fallback whenever the caller doesn't pass that prop at all. Note the double curly braces in style={{ background: color }} — the outer pair is the JSX expression, the inner pair is a regular JS object literal for the style prop, which React expects as an object rather than a CSS string.

Coding Challenges

Props let a parent hand data down to a child, but they're read-only from the child's side. State is the other half of the picture — data a component owns and can change itself, in response to things like a click or a timer. Whenever a piece of state changes, React automatically re-renders that component (and re-runs the virtual DOM comparison from Chapter 1) to reflect the new value.

The useState Hook

useState(0) creates one piece of state, starting at 0, and returns an array with exactly two things: the current value (count) and a setter function (setCount) used to change it. Calling setCount(count + 1) tells React "this component's state changed, please re-render it" — the component function runs again, this time with count holding the new value.

Why Not Just a Regular Variable?

A plain let count = 0 would actually increment in memory each click, but React has no reason to re-render the component — nothing told it the UI needs updating, so the displayed number never changes on screen. setCount exists specifically to trigger that re-render; a regular variable reassignment is invisible to React.

Updating Based on the Previous Value

Passing a function to the setter (instead of a value directly) receives the most up-to-date previous value as its argument. This matters when several updates might happen close together — React guarantees each functional update sees the result of the one before it, whereas calling setCount(count + 1) twice in a row can both read the same stale count and only increment once instead of twice.

Multiple Independent State Variables

A single component can call useState as many times as it needs — each call manages a completely independent piece of state, with its own value and its own setter. There's no requirement to bundle everything into one big state object the way some older patterns did; usually several small, clearly-named pieces of state read better than one combined one.

Coding Challenges

Chapter 3's onClick={() => setCount(count + 1)} was already an event handler, just introduced without much explanation. This chapter covers the pattern properly — naming handlers, the most common event types, reading information off the event itself, and the one JSX-specific gotcha that catches almost everyone coming from plain HTML.

Inline vs Named Handler Functions

Either style works the same way — what matters is passing a function reference, not the result of calling one. onClick={handleClick} is correct; onClick={handleClick()} would call handleClick immediately during render and pass its return value as the handler instead, which is almost never what's intended.

The Event Object

React automatically passes an event object as the handler's first argument, same as it would in plain JavaScript DOM event handling. event.target is the actual DOM element the event happened on — event.target.value is by far the most common thing read off it, giving the current text inside an input as the user types.

Handling Form Submission

event.preventDefault() stops the browser's default behavior for the event — for a form's onSubmit, that default is a full page reload, which would wipe out everything React has rendered. Calling it at the very start of the handler is the standard first line for almost every form submission handler you'll write.

Passing Extra Information to a Handler

Wrapping the call in an arrow function is also how a parent's function gets called with information only the child knows — here, id is a prop the child received, and onDelete is a function the parent passed down. The child doesn't need to know what onDelete does internally; it just calls it with the right ID when its own delete button is clicked. This "child calls a function the parent gave it" pattern is exactly how a child triggers a change in a parent's state, mentioned back in Chapter 2.

Coding Challenges

JSX doesn't have its own if tag or special conditional markup — conditional rendering is just regular JavaScript deciding what to return or embed. The LightSwitch and StatusLabel components from earlier chapters were already doing this with a ternary; this chapter covers the full range of patterns and when each one reads best.

if/else — Returning Different JSX Entirely

A plain if statement works fine above the final return, or as separate early returns like this — it just can't be written directly inside the JSX itself, since if is a statement, not an expression that produces a value.

The Ternary — Inline, Within JSX

Because condition ? a : b is an expression — it produces a value — it can sit directly inside { } in the middle of JSX, unlike if. This is the most common conditional pattern in React precisely because of that: it fits inline without needing a separate return path.

&& — Rendering Something, or Nothing

condition && jsx renders the JSX only when condition is true — when it's false, JavaScript's short-circuit evaluation stops before ever reaching the JSX, and nothing extra renders. This reads more cleanly than a ternary specifically for the "show this, or show nothing" case, where a full ternary's : null would be redundant clutter.

Rendering Nothing At All

A component returning null renders nothing at all into the DOM — no empty <div>, nothing. This is the standard way to write a component that sometimes shouldn't appear in the page at all, rather than appearing with empty content.

Several Possible States — A Mapped Lookup

Once there are more than two or three possible outcomes, a chain of ? : ternaries gets hard to read fast. A plain object used as a lookup table — keyed by the possible values — scales much better, with ?? (the nullish coalescing operator) providing a fallback for any value not found in the table.

Coding Challenges

Real applications display arrays of things constantly — a list of todos, search results, products in a cart. React has no special "repeat this markup" tag; instead, you use a regular JavaScript array method, .map(), to transform an array of data into an array of JSX elements.

Rendering an Array with .map()

fruits.map(fruit => <li>...</li>) produces a new array, this time of <li> elements instead of strings — and React happily renders an array of elements embedded inside { } exactly like it renders a single one. The curly braces around the whole .map() call work the same way they always have: dropping back into JavaScript inside JSX.

The key Prop — Why It's Required

Every element produced inside a .map() needs a unique key prop, as seen above. React uses keys to match each element in a new render against the same element from the previous render — without them, React can only guess by position, which causes real bugs when items are reordered, inserted, or removed (state belonging to one item can end up incorrectly attached to a different one after the list changes).

A genuinely stable, unique identifier — like a database id — makes the best key. The plain string array example above used the fruit name itself only because the list had no duplicates and no id field available; a real dataset with an id field should always prefer it over anything else.

Rendering a Full Component Per Item

The same pattern extends naturally to rendering a custom component per item instead of a plain <li> — the key still goes directly on the outermost element returned from .map() (here, the <TodoItem /> tag itself), never on something nested inside that component.

Filtering Before Rendering

Because .map() is just a regular array method, it chains naturally with .filter(), .sort(), or anything else from the array toolbox — filter down to the items that should actually be shown first, then map the remaining ones to JSX.

Coding Challenges

Challenge 1 from Chapter 4 already built one controlled input — an input whose displayed value comes from state, updated through onChange. This chapter generalizes that pattern across a whole form with several fields, plus the input types that don't use plain text (checkbox, radio, select).

Controlled vs Uncontrolled

An input with no value prop is uncontrolled — the browser's own DOM tracks what's typed, and React only finds out by reading it later. A controlled input ties its value directly to a piece of state, with onChange updating that state on every keystroke — React becomes the single source of truth for what's in the field, not the DOM. Controlled inputs are the standard approach in React, since the current value is always available in state wherever it's needed (validation, submitting, displaying it elsewhere on the page) without ever having to reach into the DOM to ask.

One Handler for Several Fields

Rather than one useState call per field, a form with several fields commonly uses a single state object, with one shared handleChange reading the field's own name attribute off e.target to know which key to update. [name]: value is a computed property name — plain JavaScript, not anything React-specific — letting one line update whichever key matches the input that fired the event. The ...prev spread keeps every other field's value unchanged, updating only the one key that changed.

Checkboxes and the checked Prop

A checkbox doesn't use value to control its display state — it uses checked, paired with e.target.checked (a boolean) rather than e.target.value. Wrapping the input in a <label> lets clicking the surrounding text also toggle the checkbox, a free accessibility win that costs nothing extra to add.

Select Dropdowns

A <select> works the same as a text input — value and onChange on the <select> element itself (not the individual <option>s) — which is a small but genuine difference from plain HTML, where the selected attribute is normally set on the chosen <option> directly.

Coding Challenges

Everything so far has either rendered JSX or responded to a user-triggered event like a click. A side effect is anything that reaches outside the rendering process itself — fetching data, setting a timer, manually changing the document title, subscribing to something external. useEffect is the hook for running that kind of code at the right moment, tied to a component's render rather than to a click.

The Basic Shape

useEffect takes two arguments: a function containing the side effect itself, and a dependency array listing which values it depends on. React re-runs the effect function whenever any value in that array has changed since the last render — here, whenever title changes, the document's actual browser tab title updates to match.

The Three Forms of the Dependency Array

These three shapes cover almost every use case. No array at all is rare in practice — re-running on literally every render is usually a sign something belongs in the dependency array instead. An empty array is the standard choice for "run this once when the component first appears" (fetching initial data, setting up a subscription). A populated array is for "run this again whenever this specific thing changes."

Fetching Data on Mount

This is the classic shape of a data-fetching effect: state to hold the result (starting as null, meaning "not loaded yet"), an effect that fetches and calls the setter once the data arrives, and a conditional render that shows a loading state until user stops being null. [userId] ensures the fetch re-runs if a different user's profile needs to be shown — without it, switching to a new userId prop wouldn't trigger a new fetch at all. (Intermediate Chapter 6 covers more complete error/loading handling for this exact pattern.)

Cleaning Up After an Effect

Returning a function from inside the effect gives React a cleanup function, run right before the effect runs again, and also when the component is removed from the page entirely. setInterval here would otherwise keep ticking forever, even after Clock unmounts — clearInterval(id) in the cleanup function stops it at exactly the right moment. Anything that "starts" something ongoing (a timer, an event listener, a subscription) almost always needs a matching cleanup function to "stop" it.

Coding Challenges

Every component so far has rendered its own fixed JSX. Composition is about building components that wrap other JSX without needing to know what that content actually is — a generic "Card" or "Modal" that works regardless of what's placed inside it. React's mechanism for this is a special prop every component automatically receives: children.

The children Prop

Anything written between a component's opening and closing tags — instead of using the self-closing /> form seen in every example up to now — becomes available inside that component as props.children. Card doesn't know or care that it's rendering an <h2> and a <p> specifically; it just places whatever children turned out to be inside its own wrapper <div>.

Why This Matters — Reusability Without Duplication

The same Card component now wraps two entirely different pieces of content, with zero changes needed to Card itself. Compare this to the alternative — a ProfileCard and an ImageCard, each duplicating the same wrapper markup with only the inner content differing. Composition keeps the wrapper logic written exactly once.

Combining children with Regular Props

children works alongside any other prop, not instead of them — title is a regular named prop controlling one specific, known piece of the layout (a heading), while children handles the arbitrary, unknown part (the body content). This combination — a few named "slot" props for the structured bits, plus children for everything else — covers the vast majority of real wrapper components.

Passing More Than One "Slot" of JSX

children only covers the single block of content between a component's tags — when a layout genuinely needs two or more independent regions, JSX can be passed as the value of any prop, exactly like a string or number. left={<p>...</p>} works because JSX is just a JavaScript value under the hood (from Chapter 1), and any JavaScript value can be passed as a prop.

Coding Challenges

Every state example so far lived inside the one component that used it. The moment two sibling components need access to the same piece of data — and one of them needs to change it — that approach breaks down, since neither sibling can reach into the other's state directly. The fix is always the same: move the state up to their nearest common parent, then pass it back down to both children as props.

The Problem, Concretely

TemperatureInput and TemperatureDisplay are siblings — neither is the other's parent or child, so neither can read or change the other's state directly. If TemperatureDisplay needs to show whatever value is currently typed into TemperatureInput, the temp state needs to live somewhere both of them can reach.

The Fix — Move State to the Shared Parent

temp now lives in TemperaturePanel — the closest component that's an ancestor of both siblings. Both children receive it as a prop, but only TemperatureInput is also given setTemp (renamed onTempChange for the callback-prop naming convention from Chapter 4) so it can request a change. Neither child holds its own copy of the state — there's exactly one source of truth, in the parent, and both children stay in sync with it automatically.

Deciding Where State Should Live

A simple rule of thumb: state should live in the lowest common ancestor of every component that needs to read or change it — no higher, no lower. Putting it too high (e.g. in the very top-level App) when only two deeply nested components actually need it means passing it down through several layers of components that don't care about it at all, just to reach the ones that do.

Coding Challenges