Thinking in React
You now have every tool: components, props, state, lists, conditionals, controlled inputs, lifted state, derived values. The remaining skill is the design process. The React team's classic recipe has five steps. Our example: a filterable product table with a search box and an 'in stock only' checkbox.
Step 1: break the UI into a component hierarchy. Draw boxes around every distinct piece:
FilterableProductTable ├── SearchBar (text input + checkbox) └── ProductTable (the rows) └── ProductRow (one product)
Step 2: build a static version. No state, all props, hard-coded data flowing down. It renders once and proves the structure. Static versions are mostly typing, interactivity is mostly thinking, keep them separate.
Step 3: find the minimal state. List every piece of data, keep only what fails ALL of these tests: passed in as props, never changes, or computable from other state/props (lesson 8-2).
- product list → passed in as a prop, not state
- search text → changes, not computable: state
- checkbox value → changes, not computable: state
- filtered rows → computable from products + search text + checkbox: derived
Two pieces of state for the whole feature.
Step 4: decide where state lives. Who reads the search text? SearchBar (to display it) and ProductTable (to filter). Their closest common parent is FilterableProductTable, so state lives there (lesson 8-1).
Step 5: add inverse data flow. SearchBar gets onSearchChange and onStockChange function props so typing updates the parent's state, the controlled-input loop from lesson 6-1 stretched across components.
Quiz
Apply step 3. In the product table, why are the filtered rows NOT state?
Quiz
Apply step 4. A ThemeToggle in Settings and a ThemedHeader at the top of the page both need the current theme. Settings and ThemedHeader are far apart in the tree. Where does the theme state go?
Problem
Steps 1 and 2 build a static, props-only version before adding any state. In one short phrase, what does the static version prove before interactivity exists?