React Fundamentals
Build a small React app and reason about state
Phase 1 · JavaScript and React · 11 sections · about 11 minutes
What's a component?
A component is a JavaScript function that returns one JSX root element. That root wraps everything else.
JSX is plain JavaScript pretending to be HTML. When you write <Button>Click me</Button>, React turns it into a function call: Button({ children: 'Click me' }).
function Greeting() { return <h1>Hello, world</h1>;} function App() { return <Greeting />;}The rule is strict: one root. If you need two siblings, you wrap them. A Fragment (<>...</>) is an invisible wrapper that counts.
function Card() { return ( <> <h2>Title</h2> <p>Description</p> </> );}React calls your function when it needs to know what should appear on screen. The function answers that question for the values it has at that moment, and React calls it again whenever those values change.
useState and the re-render loop
useState is how you tell React that a component has state: data that can change. When it changes, React re-runs your function to see the new output.
import { useState } from "react"; function Counter() { const [count, setCount] = useState(0); return ( <div> <p>Count: {count}</p> <button onClick={() => setCount(count + 1)}>Increment</button> </div> );}Here's what happens: user clicks the button. onClick fires. setCount(count + 1) runs. React schedules a re-render. React calls Counter() again. This time useState(0) returns the new value, 1. The JSX says "Count: 1". The screen updates.
The loop is: event → setState → re-render → new output.
That description is accurate and it is also the part everyone has to see before they believe it. Two things in it sound contradictory: the whole function runs again from the top on every keystroke, and yet the value in state survives. Run it yourself.
Watch line 2 in particular. On the first render useState("") hands back the empty string you passed in. On every render after that it hands back whatever the state currently is, and ignores the argument entirely. That is the only line in the function with a memory. Everything else, including the filtered list, is built again from nothing each time.
On the fourth render, what does useState("") return?
You can call useState multiple times in one component. Each call gets its own pair.
function Form() { const [name, setName] = useState(""); const [email, setEmail] = useState(""); return ( <div> <label htmlFor="name">Name</label> <input id="name" value={name} onChange={(e) => setName(e.target.value)} /> <label htmlFor="email">Email</label> <input id="email" value={email} onChange={(e) => setEmail(e.target.value)} /> </div> );}Never set state directly. Always use the setter function. React needs to know state changed so it can re-render.
What React is doing for you
You have just seen React re-run a component after state changes. It is worth seeing the same job done by hand once, because then React stops being a mystery and becomes a thing that automates work you can already picture.
Tandem is a prototype I built: a split screen where a React component's code and the component itself stay in sync both ways. Drag the button on the grid and the className in the code rewrites itself. Edit the code and the button moves. There is no React in it. It is one HTML file and about a thousand lines of plain JavaScript.
Drag the button, then drag its bottom-right handle to resize it, and watch the h- and w- classes in the code change as you move. Then break a class name on purpose, like bg-neutral-90, and see what it says.
All of it runs off a few variables. The code is a string, the positions are an array, and two numbers record what is selected and what is being edited:
let code = SAMPLE;let scene = [{ x: 6, y: 5 }];let selected = -1;let editing = -1;Those four values are the only truth in the app. The canvas and the code panel are both drawn from them, which is why they never disagree with each other.
Drawing the canvas is a function that takes the state and makes the screen match it. Here is the middle of it, shortened:
function renderItems() { const list = items(); const els = [...layer.querySelectorAll(".el")]; els.slice(list.length).forEach((n) => n.remove()); list.forEach((it, i) => { let el = layer.querySelectorAll(".el")[i]; if (!el) { el = document.createElement("button"); el.className = "el"; bindItem(el); layer.appendChild(el); } const pos = scene[i]; el.style.left = (pos.x - 1) * CELL + "px"; el.style.top = (pos.y - 1) * CELL + "px"; el.style.width = it.w === null ? "auto" : it.w + "px"; el.style.background = it.fill; el.style.borderRadius = Math.min(it.radius, 9999) + "px"; el.style.fontSize = it.size + "px"; el.style.fontWeight = it.weight; });}Read what that function has to do. It creates elements that do not exist yet, removes the ones that are no longer needed, and then writes every single property back onto every element, every time. Position, size, background, radius, font size, weight. Nothing is skipped, because anything you skip is a property that keeps a value from a previous state, and the screen quietly stops matching the data.
Then there is the other half of the arrangement. Nothing on screen updates on its own, so every function that changes the state has to remember to ask for a redraw:
function undo() { if (!past.length || editing >= 0) return; future.push(snapshot()); restore(past.pop());}render() is called in thirteen different places in that file. Thirteen chances to forget.
This is the job React takes off you. useState is two things at once: a value that survives re-runs, and a message to React that when this value changes, the component needs drawing again. You never call a render function, and you never write el.style.background by hand. You describe what the button should look like for the current state, and React compares that description with what is on screen and changes only the parts that differ.
In Tandem, what goes wrong if a new property is added to an item but renderItems forgets to write it back onto the element?
The rest of this module is React doing this for you. It is worth coming back to this page at the end, once the React version is familiar, and reading it again.
Derived vs. stored state
Derived state is computed from other state. Stored state lives directly in useState.
If you have both weight and height, don't store BMI in state. Calculate it every render.
function BMI() { const [weight, setWeight] = useState(70); const [height, setHeight] = useState(1.75); // Derived: calculate it fresh every render const bmi = weight / (height * height); return ( <div> <label htmlFor="weight">Weight in kg</label> <input id="weight" value={weight} onChange={(e) => setWeight(Number(e.target.value))} /> <label htmlFor="height">Height in metres</label> <input id="height" value={height} onChange={(e) => setHeight(Number(e.target.value))} /> <p>BMI: {bmi.toFixed(1)}</p> </div> );}Why? Because now weight and height are always in sync with BMI. If you stored BMI separately, you'd have to update it manually whenever weight or height changed. Easy to forget. State goes stale.
The rule: if it can be computed from other state, don't store it.
A search page holds the query in state. Should the filtered results also live in useState?
The controlled input
An input is controlled when React holds its value in state. You set the value prop and handle onChange to update state.
function SearchBox() { const [query, setQuery] = useState(""); return ( <> <label htmlFor="search">Search</label> <input id="search" type="text" value={query} onChange={(e) => setQuery(e.target.value)} placeholder="Search..." /> </> );}React is now the source of truth for the input's value. The input can't drift out of sync with your state.
An uncontrolled input leaves the value to the browser. You read it when you need it with ref. Avoid refs for inputs unless you have a specific reason, like focus management or file uploads.
Controlled inputs are predictable. They're the default in React.
Props: data parent to child
Props are how a parent component passes data to a child. They're function arguments.
function Header({ title, subtitle }) { return ( <header> <h1>{title}</h1> <p>{subtitle}</p> </header> );} function App() { return <Header title="Welcome" subtitle="React basics" />;}Props are read-only from the child's perspective. You can't call setTitle(...) inside Header and expect the parent to update. That violates the one-way flow: parent owns the data, parent can change it, child reads it.
If a child needs to change data, it calls a function the parent passed down.
function Button({ label, onClick }) { return <button onClick={onClick}>{label}</button>;} function App() { const [count, setCount] = useState(0); return <Button label="Click me" onClick={() => setCount(count + 1)} />;}Here's a small naming convention baked into the language: onClick is reserved for the click handler prop. If you try onClick on a div, it won't work. That's "chosen, not fixed." The platform chose camelCase and reserved these names. Your code has to match.
Composition into a tree
Real apps are hierarchies of components. Each piece handles its own slice of the UI.
function SearchResults({ results }) { if (results.length === 0) return <p>No results</p>; return ( <ul> {results.map((item) => ( <ResultItem key={item.id} item={item} /> ))} </ul> );} function ResultItem({ item }) { return <li>{item.name}</li>;} function SearchPage() { const [query, setQuery] = useState(""); const results = fakeSearch(query); return ( <div> <label htmlFor="search">Search</label> <input id="search" value={query} onChange={(e) => setQuery(e.target.value)} /> <SearchResults results={results} /> </div> );}Each component has one job. SearchPage manages the query. SearchResults renders a list. ResultItem renders one item. The tree is clear.
When the query changes, SearchPage re-renders, passes new results to SearchResults, which re-renders its children. This flows naturally.
Always add a key prop when rendering lists. It helps React track which item is which if the list reorders.
Lifting state up
If two sibling components need to share state, move that state to their common parent.
function Tab({ label, isActive, onClick }) { return ( <button onClick={onClick} style={{ fontWeight: isActive ? "bold" : "normal" }} > {label} </button> );} function Tabs() { const [activeTab, setActiveTab] = useState("home"); return ( <div> <div> <Tab label="Home" isActive={activeTab === "home"} onClick={() => setActiveTab("home")} /> <Tab label="About" isActive={activeTab === "about"} onClick={() => setActiveTab("about")} /> </div> <div> {activeTab === "home" && <p>Home content</p>} {activeTab === "about" && <p>About content</p>} </div> </div> );}Both tabs need to know which one is active. Instead of storing it in each tab separately, store it in Tabs and pass it down as props. Now they always agree.
This pattern scales to any number of siblings. The parent is the single source of truth.
Two sibling components need to show the same selected item. Where does that selection belong?
The four states
Every async operation has four states: idle (waiting to start), loading (in flight), empty (done, no data), error (done, failure).
Real UIs handle all four.
function BookSearch() { const [query, setQuery] = useState(""); const [state, setState] = useState("idle"); const [results, setResults] = useState([]); const [error, setError] = useState(null); const handleSearch = async (q) => { if (!q) { setState("idle"); setResults([]); return; } setState("loading"); try { const data = await fetch(`/api/books?q=${q}`).then((r) => r.json()); if (data.length === 0) { setState("empty"); setResults([]); } else { setState("idle"); setResults(data); } } catch (err) { setState("error"); setError(err.message); } }; return ( <div> <label htmlFor="book-search">Search books</label> <input id="book-search" value={query} onChange={(e) => { setQuery(e.target.value); handleSearch(e.target.value); }} placeholder="Try a title or author" /> {state === "idle" && results.length > 0 && ( <ul> {results.map((book) => ( <li key={book.id}>{book.title}</li> ))} </ul> )} {state === "loading" && <p>Searching...</p>} {state === "empty" && <p>No books found</p>} {state === "error" && <p>Error: {error}</p>} </div> );}This is tight. Every state has its own UI. No results render until data arrives. Loading UI shows immediately. Errors have a home.
The four states are a checklist: idle, loading, empty, error. Write them down and check your UI handles all four. Most bugs are in the states you skipped.
A search returns zero results and your UI renders nothing at all. Which state did you skip?
Build: Search interaction in React
Let's build a real search experience split into components. A search box, a results list, and proper state handling.
function SearchBox({ query, onQueryChange }) { return ( <> <label htmlFor="book-search">Search books</label> <input id="book-search" type="text" value={query} onChange={(e) => onQueryChange(e.target.value)} placeholder="Try a title or author" /> </> );} function SearchResults({ state, results, error }) { if (state === "loading") return <p>Searching...</p>; if (state === "empty") return <p>No books found</p>; if (state === "error") return <p>Error: {error}</p>; if (results.length === 0) return null; return ( <ul> {results.map((book) => ( <li key={book.id}> {book.title} by {book.author} </li> ))} </ul> );} function BookSearch() { const [query, setQuery] = useState(""); const [state, setState] = useState("idle"); const [results, setResults] = useState([]); const [error, setError] = useState(null); const handleSearch = async (q) => { setQuery(q); if (!q.trim()) { setState("idle"); setResults([]); return; } setState("loading"); try { const response = await fetch(`/api/books?q=${encodeURIComponent(q)}`); const data = await response.json(); if (data.length === 0) { setState("empty"); } else { setState("idle"); setResults(data); } } catch (err) { setState("error"); setError(err.message); } }; return ( <div> <SearchBox query={query} onQueryChange={handleSearch} /> <SearchResults state={state} results={results} error={error} /> </div> );}The structure: BookSearch owns all state. It passes the query to SearchBox and the results to SearchResults. When you type, SearchBox calls onQueryChange, which runs the async fetch and updates state. SearchResults re-renders with the new state.
Each component is small and testable. The flow is clear: parent to child via props, child to parent via callbacks.
Checkpoint
Before you move on, make sure you can answer these aloud.
No derived data in useState. Look at your state shape. If something can be calculated from other state, remove it. Keep only the irreducible facts.
Justify the state shape aloud. Say why each piece of state is there. If you can't explain it in one sentence, it might be derived or unnecessary.
Handle all four states. Write code for idle, loading, empty, and error. Real apps need all four. If your UI doesn't show loading, users will think it froze.
Hand-write a prop. Create a component with three props. Pass them from a parent. Don't skip steps. Typing it yourself is the point.
Also: notice how onClick is spelled camelCase. That's not a bug. That's the platform. React chose it. Your code has to match. There's no "correct" spelling in the abstract. There's only what the platform chose, and your code following it. This is "chosen, not fixed," and it's how you learn to work with systems instead of against them.