What are the 5 steps of building a UI in React?
1) Break UI into a component hierarchy. 2) Build a static version with no interactivity. 3) Find the minimal but complete representation of UI state. 4) Identify where your state should live. 5) Add inverse data flow.
In Step 1, what are three ways to decide how to split a design into components?
Programming: use separation of concerns (one component = one thing). CSS: consider what you’d make class selectors for. Design: consider how you’d organize the design’s layers.
Why does JSON data often map naturally to component structure?
Because UI and data models often have the same information architecture — the same shape. Each component can match one piece of your data model.
In the product table example, what are the 5 components identified?
FilterableProductTable (whole app), SearchBar (user input), ProductTable (displays/filters list), ProductCategoryRow (category heading), ProductRow (row per product).
In Step 2, why should you build a static version first before adding interactivity?
Building a static version requires a lot of typing and no thinking. Adding interactivity requires a lot of thinking and not a lot of typing. It’s easier to separate these concerns.
Should you use state when building the static version?
No. State is reserved only for interactivity (data that changes over time). The static version should only use props to pass data from parent to child.
When building the static version, should you go top-down or bottom-up?
In simpler examples, top-down is usually easier. On larger projects, bottom-up is easier.
What is one-way data flow?
Data flows down from the top-level component to the ones at the bottom of the tree via props. The top component takes the data model as a prop and passes pieces down.
In Step 3, what is the key principle for structuring state?
Keep it DRY (Don’t Repeat Yourself). Figure out the absolute minimal representation of state and compute everything else on-demand.
What 3 questions help you determine if something is NOT state?
1) Does it remain unchanged over time? If so, it isn’t state. 2) Is it passed in from a parent via props? If so, it isn’t state. 3) Can you compute it from existing state or props? If so, it definitely isn’t state.
In the product table example, which data pieces are state and which aren’t?
State: search text and checkbox value (they change over time, can’t be computed). NOT state: original product list (passed as props) and filtered product list (can be computed from the other values).
What is the difference between props and state?
Props are like function arguments — passed from parent to child to customize appearance. State is like a component’s memory — lets it track info and change it in response to interactions.
In Step 4, how do you figure out which component should own a piece of state?
1) Identify every component that renders something based on that state. 2) Find their closest common parent. 3) Put the state in that common parent (or above it, or in a new component created just for holding state).
In the product table example, why does FilterableProductTable own the state?
Because both ProductTable and SearchBar need the filter text and checkbox value. FilterableProductTable is their closest common parent.
What is ‘inverse data flow’ (Step 5)?
Passing setter functions (like setFilterText) down as props so that child components deep in the hierarchy can update state owned by a parent component.
Why does typing in a controlled input do nothing without an onChange handler?
When you write <input value={filterText} />, the input’s value is always equal to the filterText state. Since filterText is never updated by the input, the value never changes. You need onChange to call the setter.
How does SearchBar update FilterableProductTable’s state?
FilterableProductTable passes setFilterText and setInStockOnly down as props (onFilterTextChange, onInStockOnlyChange). SearchBar calls them in onChange handlers: onChange={(e) => onFilterTextChange(e.target.value)}.
What’s the difference between a controlled input with value vs an uncontrolled input with defaultValue?
value + onChange = controlled (React drives the value). defaultValue = uncontrolled (DOM manages its own state). If you provide value without onChange, React warns and the field is read-only.
