Unlike the chapter challenges, this is a project brief, not a graded exercise — there's no single correct solution file. Instead, you get requirements, a suggested structure, and stretch goals; how you actually build it is up to you. A todo list might seem simple, but it touches almost every Fundamentals concept at once: state, lists, conditional rendering, controlled inputs, and component composition, all working together in one small app.

Requirements

Suggested Component Breakdown

This isn't the only valid structure — it's a starting point. The key decision worth sticking to: the array of todos itself should live in TodoApp (the lowest common ancestor of the form and the list), with TodoForm and TodoItem each receiving only the props and callbacks they specifically need, exactly as covered in Fundamentals Chapter 10.

A Reasonable Build Order

1. Get a static version working first — hardcode a small array of 2–3 todo objects ({ id, text, completed }) and render them with TodoList/TodoItem before wiring up any state changes.
2. Move that array into useState in TodoApp, so it's now real state instead of a hardcoded constant.
3. Wire up TodoForm to add a new todo object to the array on submit, generating a unique id for each one (e.g. Date.now() is a quick option for a small project like this).
4. Add the "toggle complete" behavior — clicking a todo's checkbox should flip its completed value without affecting any other todo in the array.
5. Add the delete behavior — removing exactly one todo from the array by its id, leaving the rest unchanged.
6. Add the empty-state message and the blank-input guard last, once the core add/toggle/delete flow is solid.

Project 1 worked entirely with local state — nothing ever left the browser. This project introduces a real external dependency: a weather API. That single change brings a whole new category of things to handle correctly — the data isn't there immediately, the request can fail, and the UI needs to make sense in all three states (loading, error, and loaded), not just the happy path.

Requirements

Suggested Component Breakdown

The status state is the important design decision here — rather than separate isLoading/hasError booleans that could theoretically contradict each other, a single status value ("idle" | "loading" | "error" | "success") guarantees the UI is always in exactly one well-defined state, using the lookup-object/conditional patterns from Fundamentals Chapter 5.

A Reasonable Build Order

1. Build SearchForm first with just a controlled input and a submit handler that logs the typed city name — no fetching yet.
2. Manually call the geocoding endpoint once in the browser/Postman/curl for a known city, to see the actual JSON shape you'll be working with before writing any fetch code.
3. Wire up the geocoding fetch inside an async function triggered on form submit, storing the resolved coordinates in state.
4. Add the second fetch for the actual weather data once coordinates are available, setting status to "loading" before it starts and "success" once it resolves.
5. Wrap both fetches in a try/catch, setting status to "error" (with a stored error message) if either one fails.
6. Build out WeatherDisplay last, rendering different JSX for each of the four status values.

Project 1's todos vanished the moment the page reloaded — every piece of state was reset to nothing. This project adds persistence: saving the current data to the browser's localStorage on every change, and reading it back when the app first loads, so a note typed today is still there tomorrow. It's also the first project with a genuine "edit an existing item in place" flow, rather than just adding/removing whole items.

Requirements

Suggested Component Breakdown

NoteItem is the trickiest piece — it needs its own small piece of local state (something like isEditing) to decide whether it's currently showing the note's static text or an editable form for it. That's a perfectly reasonable case for state living inside NoteItem itself rather than being lifted up, since no other component needs to know whether one particular note is currently being edited.

A Reasonable Build Order

1. Build the add/list/delete flow first, exactly like Project 1's todo list, with notes only living in memory (no localStorage yet).
2. Add a useEffect in NotesApp with the notes array as its dependency, calling localStorage.setItem("notes", JSON.stringify(notes)) every time it changes.
3. Add a second useEffect (with an empty dependency array, running once on mount) that reads localStorage.getItem("notes"), parses it with JSON.parse, and sets it as the initial notes state — handling the case where nothing's been saved yet.
4. Refresh the page after adding a few notes to confirm persistence is actually working before building anything else.
5. Add edit mode to NoteItem last — its own isEditing state, a controlled form shown only while editing, and a "Save" action that updates the matching note in the parent's array.

This project reaches slightly ahead of where the chapter-by-chapter courses are at — it needs two ideas that don't have their own Fundamentals chapter yet: routing (multiple "pages" in a single-page app) and debouncing (delaying a search request until typing actually pauses). Both get a working primer below; React Router gets its proper full chapter in Intermediate Chapter 5, and this project is a hands-on first taste of it ahead of that.

Suggested Data Source

The Open Library Search API is free and needs no API key, similar to Open-Meteo in Project 2 — https://openlibrary.org/search.json?q=<query> returns a list of matching books, and https://openlibrary.org/works/<id>.json returns details for one specific book.

Requirements

Suggested Component Breakdown

A Reasonable Build Order

1. Set up react-router-dom with two placeholder page components and a working <Link> between them, before any fetching exists at all — confirm navigation itself works first.
2. Build the search input with a non-debounced fetch (firing on every keystroke) to confirm the API call and result rendering work correctly.
3. Convert the search effect to the debounced version, confirming with the browser's network tab that requests are no longer firing on every single keystroke.
4. Make each result item a <Link to={`/book/${id}`}>, carrying the right id into the URL.
5. Build BookDetailPage, reading the id with useParams() and fetching that specific book's details in a useEffect keyed on the id.
6. Add loading/error handling to both pages last, once the core search → detail flow works end to end.

Every project so far has worked with a flat array — a list of todos, a list of notes. A Kanban board's state is one level more complex: an object where each key holds its own array (one per column), and the core interaction — dragging a card from one column to another — means immutably removing an item from one array and adding it to a different one, in the same update. This project also introduces the browser's native drag-and-drop events, which React doesn't wrap in anything special — they're used directly, the same way onClick always has been.

Requirements

Suggested Component Breakdown

A reasonable shape for the state itself: { todo: [{ id, text }, ...], inProgress: [...], done: [...] }. KanbanBoard owns this whole object — exactly the "lowest common ancestor" reasoning from Fundamentals Chapter 10, since moving a card between columns is fundamentally a change that affects two columns (siblings) at once, which only their shared parent can coordinate.

A Reasonable Build Order

1. Hardcode the columns object with a few sample cards in each, and get all three columns rendering their cards correctly with .map() before touching drag-and-drop at all.
2. Move the hardcoded object into useState, and build AddCardForm so new cards can be added to a chosen column's array.
3. Add draggable and onDragStart to Card, storing the card's id and its current column name (state, a ref, or e.dataTransfer all work) somewhere onDrop can read it from later.
4. Add onDragOver (with e.preventDefault()) and onDrop to Column. On drop, build a new columns object: filter the card out of its source column's array, and add it to the destination column's array.
5. Add the drag-over highlight — a small piece of state in each Column (or lifted up, tracking which column id is currently being dragged over) toggled by onDragEnter/onDragLeave.
6. Add the delete button per card last, once the drag-and-drop flow is solid.

Every previous project's state stayed within one small cluster of components, close enough together that lifting state up (Fundamentals Chapter 10) was a clean fit. A shopping cart is different: a product grid, a cart icon in the page header, and a full cart page all need to read or update the same cart — and they're nowhere near each other in the component tree. Lifting the cart all the way up to App and passing it down through every layer in between would mean prop drilling through components that have nothing to do with the cart at all. This is exactly the situation the Context API exists for, previewed here ahead of its full treatment in Intermediate Chapter 2.

Requirements

Suggested Component Breakdown

Notice that Header and ProductList are siblings, several layers removed from CartPage — exactly the layout where plain prop-passing would mean threading the cart through components that don't use it themselves. CartProvider wraps all three, and every consumer below it reaches the cart directly via useContext.

A Reasonable Build Order

1. Build the static product grid and a non-functional cart page shell first, with no Context at all yet.
2. Create CartContext and CartProvider, holding just the items array in useState, and wrap the whole app in it.
3. Write addToCart: check whether the product is already in the array; if so, increase that entry's quantity, otherwise add a new entry with quantity 1 — both cases building a new array, never mutating the existing one.
4. Wire ProductCard's button to call addToCart via useContext, and confirm the cart's contents are correct by logging them, before building any UI for the cart itself.
5. Build CartBadge next — it only needs a derived total (sum of every item's quantity), read from the same context.
6. Build out the full CartPage/CartItem views last, adding remove and quantity-update actions to the context's value alongside addToCart.

Suggested Data Source

The CoinGecko API is free and needs no API key for its public market-data endpoints — a good fit for a dashboard with multiple live-updating widgets and a price history chart per item.

Requirements

Suggested Component Breakdown

A Reasonable Build Order

1. Scaffold the Next.js app and confirm the default starter page runs, before changing anything.
2. Install React Query, set up QueryClientProvider in the root layout, and get one useQuery call successfully logging fetched data to the console.
3. Build CoinList/CoinCard, rendering real data from that query, each card linking to its own dynamic detail route.
4. Build the dynamic route page, reading the id from the URL and firing a second useQuery for that specific item's history data.
5. Install Recharts and get a <LineChart> rendering the fetched price-history data on the detail page.
6. Add refetchInterval to the overview query last, and confirm (via the network tab) that it's actually refetching on its own over time.