Introduction: How This Course Works

Welcome. This course is a complete path through modern React and Next.js, not a roadmap of links to read elsewhere. It has 54 lessons across React, the Next.js App Router, full-stack development and production work, followed by a capstone project. This page explains how the lessons are built, the project you will grow throughout the course, and how to get real working knowledge out of it rather than just reading.

How each lesson works

Every lesson follows the same shape, so you always know where to look:

• The goal: one sentence on what you will be able to do by the end.
• The lesson: the concept explained step by step, with code you can read top to bottom.
• Common mistakes: what goes wrong in real code reviews, and how to spot it.
• Practical exercise: a task to build yourself, with hints and a sample solution to compare against once you have tried.
• Check your understanding: a few questions to answer in your own words before moving on. Answers are hidden until you open them.

Each lesson also carries a priority. Must understand lessons are the foundations: you should be able to explain the idea, build a small example and review someone else’s use of it. Should know lessons cover patterns you need to recognise and use when they fit, looking up the exact API when you do.

Using the live code editor

Code blocks with a Try it button are runnable. Press it and the block becomes an editor with the result underneath. Change anything, then press Run (or Ctrl + Enter). Reset brings back the original code. Messages from console.log, and React’s own warnings, appear under the result. Try it on the example below: change the name, or the number of items.

function Greeting() {
  const name = 'Developer';
  const lessons = 54;

  console.log('Rendering Greeting for', name);

  return (
    <p>
      Hello, {name}! You have {lessons} lessons ahead.
    </p>
  );
}

The editor runs your code in an isolated frame in your browser, with React 19 available. It renders the component named App if there is one, otherwise the last component in the code. You can write import { useState } from 'react' exactly as in a real project; React’s hooks are also available without importing them. Next.js examples from Part 2 onwards need a server, so those are regular code blocks for you to run in your own project.

React, Next.js, a CMS and a database: who does what

A modern content-driven web application usually has these layers. Keeping their responsibilities separate is one of the main themes of the course.

Technology	Role	Typical concerns
React	UI library	Components, props, state, hooks, rendering
Next.js	React framework	Routing, server rendering, layouts, APIs, caching, deployment
Headless CMS (optional)	Content management	Content types, editorial workflow, media, permissions, APIs
Database	Persistent data	Relationships, constraints, migrations, backups

In the course project, the database holds the things that change all the time (tools, members, reservations) and a headless CMS holds the editorial content (repair and safety guides). The lessons use Strapi as the example CMS, but the same boundaries apply to WordPress through its REST API or WPGraphQL, or to any other content API: CMS details stay behind a small data layer so the rest of the app never depends on them.

The project you will build: a community tool library

Reading alone does not build skill, so every exercise adds a piece to one application. Most people own a drill they use for ten minutes a year. A tool library lets a neighbourhood share them instead: members browse what is available, reserve a tool for some dates, collect it and bring it back; volunteers look after the catalogue and repairs.

It is a deliberately ordinary idea with real problems inside it, which is what makes it a good teacher:

• Availability is data, not decoration. A tool is free, reserved, on loan or in repair, and the interface has to follow that state everywhere (Part 1).
• The catalogue should be fast, but never stale. Tool pages can be cached; availability cannot be wrong. Deciding what to cache, and for how long, is Part 2.
• Two people will try to book the same drill. Reservations need server-side validation and a check that cannot be beaten by two clicks at the same moment (Part 3).
• Members must only see their own bookings. Authentication tells you who someone is; authorization decides what they may see and change (Part 3).
• Real people depend on it. It has to work with a keyboard and a screen reader, load quickly on a phone, be tested and be monitored once it is live (Part 4).

By the end you will have built: a searchable, filterable catalogue; a page for every tool and category; member accounts; reservations with date checks and conflict protection; a volunteer dashboard for adding tools and marking repairs; repair guides from a CMS; and a tested, monitored production deployment. Part 1 happens entirely in the live editor on these pages. From Part 2 you move the same components into a Next.js project on your own computer, laid out roughly like this:

tool-library/
  src/
    app/
      page.tsx                  # home: what's available this week
      tools/page.tsx            # catalogue with search and filters
      tools/[slug]/page.tsx     # one tool: photos, availability, reserve
      categories/[category]/page.tsx
      reservations/page.tsx     # a member's own bookings
      dashboard/                # volunteers only
      guides/[slug]/page.tsx    # repair guides from the CMS
      api/
      layout.tsx
      error.tsx
      not-found.tsx
    components/
    lib/
      db/                       # all database access lives here
      cms/                      # all CMS access lives here
      auth/
      validation/
    types/
  tests/

Treat this as a teaching structure, not a rule. On a real team project, follow the conventions the repository already uses before introducing new folders or abstractions.

A note on versions

The course targets React 19 and Next.js 16 with the App Router. The core ideas (components, state, server and client boundaries, data layers) are stable, but framework APIs move quickly, especially caching, route parameters, Proxy and form actions. Where a lesson depends on a specific version, it says so and links to the official docs. Do not carry Next.js 13 or 14 caching assumptions into a Next.js 16 project; Lesson 29 explains what changed.