Here’s the Watchlist you’re building, described as a designer would hand it over: a header with the title and “3 to watch”; a form with a title input and an Add button; a row of filter buttons (All, To watch, Watched); and a list of movies, each with its title, year and a checkbox to mark it watched. When the list is empty, a friendly message replaces it.
\nBefore you write a line of code, decide what the components are. It’s the most important design step in a React app, and it’s done with a pen.
\nTake the mockup and draw a box around every piece that does one job. Then name each box as a noun, the way you’d name a function.
\nNested boxes become a tree. App owns the whole screen. MovieList renders either many MovieItems or one EmptyState. This tree is the plan for the rest of the course; you’ll build each box as a component.
Split a piece into its own component when at least one of these is true:
\nMovieItem appears once per movie. Writing it once is the point.AddMovieForm handles typing and submitting. Nothing else needs to know how.Don’t split just because you can. A component that only wraps one <span> adds a file, an import and a name to remember, and gives nothing back. Experienced teams often keep a component at 100 lines rather than splitting it into five 20-line ones that are only used together. Start a little bigger and extract when one of the three reasons appears.
With the tree drawn, build it with hard-coded data and no interactivity. Pass data down from the top so the shape is right from the start:
\nconst MOVIES = [\n { id: 1, title: 'Arrival', year: 2016, watched: true },\n { id: 2, title: 'Past Lives', year: 2023, watched: false },\n { id: 3, title: 'Paddington 2', year: 2017, watched: false },\n];\n\nexport default function App() {\n return (\n <main>\n <Header movies={MOVIES} />\n <AddMovieForm />\n <FilterBar />\n <MovieList movies={MOVIES} />\n </main>\n );\n}\n// …Header, AddMovieForm, FilterBar and MovieList defined belowBuilding the static version is mostly typing, and it gets the structure and markup right while nothing moves. Adding interactivity is mostly thinking. Doing both at once is how components end up tangled.
\nNext, list every piece of data in the app and ask three questions about each. Does it stay the same over time? Is it passed in from a parent? Can you calculate it from other data? If the answer to any of them is yes, it isn’t state.
\nFor the Watchlist:
\n| Data | \nState? | \nWhy | \n
|---|---|---|
| The list of movies | \nYes | \nChanges when you add, remove or mark one | \n
| The current filter | \nYes | \nChanges when you click a filter button | \n
| Text typed in the form | \nYes | \nChanges as you type | \n
| Number left to watch | \nNo | \nCalculated from the movies | \n
| Movies currently visible | \nNo | \nCalculated from movies + filter | \n
Three pieces of state, two derived values. Keeping state minimal is the single habit that prevents the most bugs in React apps. Every extra piece of state is a second copy of the truth that can disagree with the first.
\n\nThe movies are needed by Header (for the count) and MovieList (to show them). The rule: data lives in the closest common parent of every component that needs it, which here is App. It flows down as props. When a child needs to change it, the parent passes down a function to call. You’ll do exactly that in Section 3.
Next, you’ll learn props properly: how to pass data into components, set defaults and keep components reusable.
\n","toc":[{"id":"sec-1","text":"Draw boxes, name them","level":2},{"id":"sec-2","text":"When to split, and when not to","level":2},{"id":"sec-3","text":"Build the static version first","level":2},{"id":"sec-4","text":"Find the minimal state","level":2},{"id":"sec-5","text":"Where the data lives","level":2}],"takeaways":["Draw boxes around the mockup and name each box; nested boxes become a component tree.","Split a component when a piece is reused, has its own job, or makes the parent hard to read, not by default.","Build a static version from hard-coded data first, then add interactivity.","Keep the minimal state; anything you can calculate from other data, such as a count or a filtered list, is derived, not state."],"further":[{"title":"Thinking in React","url":"https://react.dev/learn/thinking-in-react"},{"title":"Your UI as a Tree","url":"https://react.dev/learn/understanding-your-ui-as-a-tree"}],"quiz":[{"q":"The Watchlist needs to show how many movies are unwatched. Where should that number come from?
","options":[{"text":"A separateunwatchedCount state that every handler updates.","why":"A second copy of information that’s already in the list will eventually disagree with it. That’s the bug React is supposed to remove."},{"text":"Calculated from the movies array while rendering, with movies.filter((m) => !m.watched).length.","why":"Correct. It’s derived data. Calculating it on each render keeps it correct automatically, and for a list this size it costs nothing."},{"text":"Stored in localStorage and read back on every render.","why":"localStorage is for persisting data across reloads, not for values you can compute from data you already have."}],"answer":1},{"q":"A teammate splits the movie card into MovieTitle, MovieYear, MovieTitleWrapper and MovieYearText, each wrapping one tag. What’s the best review comment?
In the Watchlist tree, App contains Header, AddMovieForm, FilterBar and MovieList, and MovieList contains many MovieItems. Which components need the movies array?
Why build a static version of the Watchlist with hard-coded data before adding state?
","options":[{"text":"React can’t render components that have state until a static version exists.","why":"There’s no such rule. It’s a working method, not a technical requirement."},{"text":"Static components render faster in production.","why":"Speed isn’t the reason. The order of work is about separating two different kinds of thinking."},{"text":"It separates layout and structure from interactivity, so you get the tree right before thinking about what changes.","why":"Correct. Building the static version is mostly typing; deciding on state needs careful thought. Doing them one at a time avoids tangling both."}],"answer":2}],"exercise":{"kind":"choice","multiple":true,"options":["ratings","average-rating","sort-order","sorted-movies","is-sorted-by-year"],"correct":["ratings","sort-order"],"title":"Find the minimal state","prompt":"The Watchlist gets two new features. Each movie can now have a star rating from 1 to 5 that you set by clicking stars, and a dropdown lets you sort the list by title or by year. The header also shows the average rating of the movies you’ve watched.
\nWhich of these should be stored in state? Pick every one that is truly state; leave out anything that’s derived.
\n","hints":["For each item, ask: can I calculate this from other data I already have?","An average, a sorted copy and a yes/no about the sort can all be computed from the ratings and the chosen sort order."],"explanation":"Only two things change on their own because of what the user does: each movie’s rating (stored on the movie in the movies state) and the chosen sort order. Everything else is calculated during render. The average is watched ratings ÷ count, the sorted list is a sorted copy of the movies based on the sort order, and “is sorted by year” is just sortOrder === 'year'. Storing any of those would create a second copy that can go stale.
isSortedByYear used to style the dropdown","why":"Derived. It’s sortOrder === 'year'. Keeping it in its own state lets it disagree with the actual sort order."}}},"words":674,"readMinutes":3}