React Engineering: Components, State, Effects, and Rendering

React Engineering: Components, State, Effects, and Rendering connects the essential decisions in this stage of frontend engineering. You will learn each browser or framework model from first principles, apply it to the progressive Learning Atlas product, diagnose a realistic failure from evidence, and direct an AI collaborator with explicit constraints. The goal is independent judgment, not memorized syntax.

What you will build or be able to do

You will advance a component-based Learning Atlas interface. By the end, you can explain every topic in this chapter, implement one focused slice per topic, adapt those slices under new constraints, and defend the result with browser evidence, strict types, accessibility checks, security boundaries, and a production build.

Before you begin

Bring forward learning-atlas/src/components and learning-atlas/src/App.tsx and the verification notes from the preceding chapter. Create a narrow Git branch, read the repository rules, and inspect existing changes before editing. When a tool or file is introduced for the first time, its purpose is explained before its syntax.

Use these project-orientation commands:

bash

pwd
node --version
npm --version
git status --short

Before beginning React Engineering: Components, State, Effects, and Rendering, stop if the working tree contains files you do not understand. Do not delete, reset, or rewrite another person's work to make the lesson cleaner.

How the outcomes connect

React renders a description of the interface from props and state. Events request state changes; React calculates a new tree and commits the minimum DOM work. Components are boundaries for responsibility, not merely smaller files. The topics below are ordered because each creates evidence needed by the next. Experienced readers may jump to a topic, but should still complete its failure investigation and adaptation task.

Step	Learning outcome	Proof of understanding
01	React's Mental Model: UI as a Function of State	Represent idle, loading, success, empty, and error as explicit input states and predict the exact tree for each before coding.
02	JSX, Components, Props, Children, and Composition	Create a visual container that does not own a heading level, then compose it into two sections with correct independent semantics.
03	Events, State, Batching, Derived Data, and Immutable Updates	Implement undoable topic completion with immutable history, then explain which values are source state and which are derived.
04	Lists, Keys, Controlled Forms, and Reusable Input Patterns	Build a reorderable form list with stable IDs, persistent labels, field errors, and focus that remains with the same logical item.
05	Effects, Refs, Custom Hooks, and Escaping React Carefully	Remove one unnecessary synchronization effect, then write a justified effect for a browser API with cleanup and a Strict Mode check.
06	Rendering, Hydration, Suspense, and the Server/Client Boundary	Render stable server content with a small client interaction, then document every prop that crosses the serialization boundary.

React's Mental Model: UI as a Function of State

A React render calculates UI from current props and state. Rendering must stay pure; events request updates; React batches work and commits changes. If the same inputs produce a different tree because of hidden mutation, the model becomes unpredictable.

Apply the model to Learning Atlas

The current artifact for react's mental model: ui as a function of state is learning-atlas/src/App.tsx. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

tsx

type Topic = { id: string; title: string; complete: boolean };
export function App({ topics }: { topics: Topic[] }) {
  const remaining = topics.filter((topic) => !topic.complete);
  return <main><h1>Learning Atlas</h1><p>{remaining.length} topics remain.</p></main>;
}

Failure evidence and minimal repair

Scenario: A component sorts its props array during render, changing the parent's data and causing another list to reorder unexpectedly.

Evidence to collect: Freeze props in a focused test, inspect render counts and references, compare before/after arrays, and locate mutation inside render.

Minimal repair rule: For react's mental model: ui as a function of state, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Represent idle, loading, success, empty, and error as explicit input states and predict the exact tree for each before coding.

JSX, Components, Props, Children, and Composition

JSX is syntax for describing a tree, not HTML stored in JavaScript. Props are component inputs; children allow structural composition. A useful component owns one coherent responsibility and preserves the semantics its caller expects.

Apply the model to Learning Atlas

The current artifact for jsx, components, props, children, and composition is learning-atlas/src/components/Section.tsx. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

tsx

import type { ReactNode } from "react";
type SectionProps = { title: string; children: ReactNode };
export function Section({ title, children }: SectionProps) {
  const id = title.toLowerCase().replaceAll(" ", "-");
  return <section aria-labelledby={id}><h2 id={id}>{title}</h2>{children}</section>;
}

Failure evidence and minimal repair

Scenario: A universal Card component renders every heading as h2, causing skipped or duplicated headings when composed inside different pages.

Evidence to collect: Inspect the final DOM rather than component names, review heading context at each call site, and test composition with multiple semantic levels.

Minimal repair rule: For jsx, components, props, children, and composition, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Create a visual container that does not own a heading level, then compose it into two sections with correct independent semantics.

Events, State, Batching, Derived Data, and Immutable Updates

State is component memory that affects rendering. Several updates may be batched; functional updates use the latest queued value. Derive values from current inputs during render, and replace objects or arrays rather than mutating shared references.

Apply the model to Learning Atlas

The current artifact for events, state, batching, derived data, and immutable updates is learning-atlas/src/components/Progress.tsx. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

tsx

"use client";
import { useState } from "react";
export function Progress() {
  const [complete, setComplete] = useState(false);
  return <button type="button" aria-pressed={complete} onClick={() => setComplete((value) => !value)}>{complete ? "Completed" : "Mark complete"}</button>;
}

Failure evidence and minimal repair

Scenario: Two rapid completion clicks increment once because both handlers captured the same old count and used count plus one.

Evidence to collect: Use React DevTools and event logs to compare captured values, queued functional updates, renders, and object identity.

Minimal repair rule: For events, state, batching, derived data, and immutable updates, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Implement undoable topic completion with immutable history, then explain which values are source state and which are derived.

Lists, Keys, Controlled Forms, and Reusable Input Patterns

Keys identify list items across renders; they are not display order. Controlled inputs derive their visible value from React state. Reusable fields must preserve labels, descriptions, errors, names, and native form behavior.

Apply the model to Learning Atlas

The current artifact for lists, keys, controlled forms, and reusable input patterns is learning-atlas/src/components/TopicForm.tsx. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

tsx

"use client";
import { useState } from "react";
export function TopicForm() {
  const [title, setTitle] = useState("");
  return <form onSubmit={(event) => { event.preventDefault(); if (title.trim()) setTitle(""); }}><label>Topic name<input value={title} onChange={(event) => setTitle(event.target.value)} /></label><button type="submit">Add topic</button></form>;
}

Failure evidence and minimal repair

Scenario: Using array indexes as keys moves typed text to a different topic when the list is filtered or reordered.

Evidence to collect: Enter distinct values, reorder the list, inspect keys with React DevTools, and compare stable domain IDs with indexes.

Minimal repair rule: For lists, keys, controlled forms, and reusable input patterns, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Build a reorderable form list with stable IDs, persistent labels, field errors, and focus that remains with the same logical item.

Effects, Refs, Custom Hooks, and Escaping React Carefully

Effects synchronize React with an external system after commit. Refs hold a mutable value or DOM reference without driving rendering. Custom hooks share stateful behavior. Data derivation, event responses, and prop-to-state copying usually do not need effects.

Apply the model to Learning Atlas

The current artifact for effects, refs, custom hooks, and escaping react carefully is learning-atlas/src/hooks/useDocumentTitle.ts. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

typescript

import { useEffect } from "react";
export function useDocumentTitle(title: string) {
  useEffect(() => {
    const previous = document.title;
    document.title = title;
    return () => { document.title = previous; };
  }, [title]);
}

Failure evidence and minimal repair

Scenario: An effect copies filtered topics into state, depends on that state, and creates an extra render loop with stale results.

Evidence to collect: Inspect effect dependencies, render counts, state setters, cleanup behavior, and whether the value can be calculated during render.

Minimal repair rule: For effects, refs, custom hooks, and escaping react carefully, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Remove one unnecessary synchronization effect, then write a justified effect for a browser API with cleanup and a Strict Mode check.

Rendering, Hydration, Suspense, and the Server/Client Boundary

Server rendering sends useful HTML before client JavaScript. Hydration attaches React behavior to matching markup. Suspense coordinates unavailable work. A client boundary opts its module subtree into browser execution and requires serializable props across the server boundary.

Apply the model to Learning Atlas

The current artifact for rendering, hydration, suspense, and the server/client boundary is learning-atlas/app/topics/loading.tsx. Before editing, predict the visible behavior and name the source of truth. Then implement or study this complete focused slice:

tsx

export default function Loading() {
  return <section aria-busy="true" aria-labelledby="loading-title"><h2 id="loading-title">Loading topics</h2><p>Your curriculum is on its way.</p></section>;
}

Failure evidence and minimal repair

Scenario: The server prints a localized date while the browser's first render uses another timezone, producing a hydration mismatch and visible replacement.

Evidence to collect: Compare raw response HTML with the first client render, timezones and locale inputs, hydration warning stack, and client boundary location.

Minimal repair rule: For rendering, hydration, suspense, and the server/client boundary, correct the first boundary that violates the documented model, preserve the rest of the working path, and add a regression check based on the observed evidence.

Adaptation task

Render stable server content with a small client interaction, then document every prop that crosses the serialization boundary.

AI Pairing Pattern for this stage

Goal: Advance a component-based Learning Atlas interface through one learning outcome at a time while keeping the implementation understandable and reversible.

Context to attach: the current react engineering outcome, the product brief, repository rules, package versions, relevant files and callers, shared types or tokens, the current Git diff, and the latest observed failure or command output.

Constraints: while advancing a component-based Learning Atlas interface, preserve concurrent work; use semantic HTML and strict TypeScript; keep Server Components as the default in Next.js; validate untrusted data on the server; do not expose secrets; include loading, empty, error, success, disabled, and partial states when relevant; make one bounded change.

Acceptance criteria: the react engineering adaptation works from 320 pixels upward; keyboard and focus behavior are complete; color is not the only signal; authorization and validation are enforced at authoritative boundaries; the relevant type, lint, build, and browser checks pass.

Reusable prompt:

We are implementing one outcome from “React Engineering: Components, State, Effects, and Rendering” in the Learning Atlas. Read the attached repository rules, outcome text, relevant files, current diff, and verification evidence. Restate the user-visible result, source of truth, trust boundary, valid states, and unknowns. Propose the smallest reversible vertical slice. Implement only that slice. Then report the exact diff, criterion-to-evidence mapping, remaining risks, and the next discriminating check. Stop before dependency installation, destructive action, public-contract change, authentication decision, or deployment unless explicitly authorized.

For React Engineering: Components, State, Effects, and Rendering, inspect the response without relying on its summary. Read every changed line, compare it with the actual source of truth, and reproduce the evidence yourself. Reject unexplained assertions, broad client boundaries, missing states, invented APIs, suppressed errors, or tests that merely restate implementation details.

Failure Lab: trace one defect across the whole stage

A filtered list uses index keys while an effect copies derived state. Reordering moves input values and the effect restores stale data. Trace identity, renders, state ownership, effect timing, and focus. Write exact reproduction steps and expected versus observed behavior. Follow the value across every relevant boundary until you find the first contradiction.

Within the adapt stage of React Engineering: Components, State, Effects, and Rendering, change one cause, not several symptoms. Rerun the original reproduction, one adjacent failure case, keyboard navigation, and the focused static checks. The lab is complete only when you can explain why the repair works and which regression check would have failed before it.

Verify It Yourself

Run the scripts that this project actually defines:

bash

npx tsc --noEmit
npm run lint
npm run build

If your learning project later defines a test script, run it as an additional gate; do not report tests as passing when no test command exists. In the browser, exercise every state transition, inspect component props, use stable list keys, and confirm rerenders preserve focus and input. Repeat the primary journey at 320, 768, and wide desktop widths, at 200% zoom, in both themes, by keyboard, and with reduced motion. For networked work, simulate slow, malformed, unauthorized, empty, and failed responses.

Review lenses

Accessibility: Verify the final DOM, stable keys, labels, focus after list changes, announcements, and effect cleanup under Strict Mode.
Security: Never let client state stand in for server authorization; escape content and treat props crossing external boundaries as untrusted.
Responsive design: Exercise composition with long children, controlled inputs, reordered lists, mobile keyboards, zoom, and Suspense fallbacks.
Performance: Inspect rerenders and client JavaScript before memoizing; derive values during render and keep effects for external synchronization.

Checkpoint and practice extension

Close React Engineering: Components, State, Effects, and Rendering and draw its models from memory. Pick two outcomes and explain how a decision in the first can cause a failure in the second. Then complete three levels of practice:

Guided: repeat one react engineering example with a second realistic data item and compare the evidence.
Independent: complete one adapt-stage adaptation without the example, keeping a decision log and regression check.
Expert: design an alternative architecture for a component-based Learning Atlas interface; compare correctness, accessibility, security, responsive behavior, performance, operations, and migration cost using measured evidence.

Recap and bridge

You have treated react engineering as a connected engineering system rather than isolated syntax. The durable result is not the example code; it is the ability to predict behavior, expose assumptions, collect evidence, bound AI work, and repair the first broken boundary. Carry the product files and evidence log into the next stage.