Build Production Apps with React

1. The React mental model

React's entire design follows from one idea: your interface is a function of your data, and you describe what the screen should look like rather than how to change it. This lesson builds that model precisely — components as pure functions of props and state, the render-then-commit cycle, the rules that keep rendering predictable, and where side effects are allowed to live. Get this model right and React's API becomes obvious; get it wrong and you will spend years fighting symptoms.

2. Props & composition

A component's props are its API, and the shape of that API decides whether the component is reusable or a maintenance tax. This lesson covers designing props (types, defaults, booleans, callbacks, variants), the difference between configuration and composition, `children` and slot patterns, when *not* to make something configurable, and the `memo` question. You will learn to read a component from its signature alone — the skill that makes teams able to share components without reading their source.

3. State & events

State is the smallest set of facts that can change, and events are the only things allowed to change it. This lesson covers where state lives (the single-state-owner rule), when to use `useState` and when to reach for `useReducer`, deriving everything else during render, the batching and updater subtleties, lifting state and sharing it with context, and handling events properly — including async handlers, controlled inputs and error boundaries. State design is application design: get the location right and most bugs disappear before they are written.

1. Forms & validation

Forms are where your application takes something valuable from a user — and where correctness, security and accessibility all become non-negotiable. This lesson covers controlled inputs, validating at the right moments (blur, submit, live), connecting errors to fields so assistive technology can find them, preserving input after failure, server-side validation as the final authority, and the complete UX of saving: pending states, success feedback and duplicate submission. A form done properly is a contract with the person filling it in.

2. Data fetching states

Every data view has five states, not one: loading, success, empty, error and stale. This lesson covers designing the full lifecycle — skeletons that match the eventual layout, retry that is safe, empty states that differ from failures, caching and staleness, cancellation of obsolete requests, avoiding waterfalls, pagination and optimistic updates — and choosing where the fetching lives: a hook in your own code, or a library whose whole job is these problems. The success screenshot is the easy twenty per cent.

3. Routing & app architecture

A screen with a URL is shareable, bookmarkable, reloadable and linkable — and a codebase organised around features survives changes that one giant folder does not. This lesson covers routing as a product decision (URLs are the app's public interface), nested layouts and dynamic segments, data loading per route, protected routes, and the folder structures that keep a growing React application navigable: feature folders, clear server/client boundaries, and where each kind of code belongs. Architecture is not ceremony; it is the set of decisions you will not want to reverse later.

4. Ship the analytics dashboard

The difference between a demo and a product is a list: the performance work, the accessibility pass, the edge cases, the empty screens, the mobile test and the deployment checklist that only get done when they are scheduled. This lesson is that list, ordered the way an experienced team runs it — measure before optimising, fix the edge cases users actually hit, verify accessibility and responsive behaviour with instruments rather than intentions, then ship behind a checklist you reuse on the next build.