Components, React, Hydration, and Islands

_Locale: en-US · Lesson: WEBF-006 · Public order: 33_

Outcome and working artifact

This lesson produces a UI Activation Boundary Record v1: a decision artifact that separates observations, assumptions, limits, and required evidence. The goal is a transferable model, not memorized tool names.

Classify a bounded interactive UI by component boundary, initial HTML source, and client activation boundary; explain whether hydration or an island model is actually present rather than assumed.

Boundary model

Component, React, hydration, and island name different layers. A component is a way to divide a user interface into owned units. React is one library that can express components. Hydration attaches client behavior to server-rendered markup under a matching render model. An island architecture activates selected interactive regions instead of treating the whole document as one client-controlled root.

Keep three labels throughout the work: observed, bounded inference, and needs verification. When evidence is unavailable, record unknown. A product name or a passing happy path is not a substitute for evidence.

1. Component is a design boundary

A component can own structure, behavior, state, and an interface to its parent. It is not inherently tied to React, client rendering, or even JavaScript.

2. React is a concrete library

React supplies a programming model and runtime APIs for UI trees. Calling every component a React component erases the distinction between a general architecture idea and one implementation.

3. Server rendering and hydration are separate decisions

Server rendering produces initial HTML. Hydration is client work that connects a compatible component tree and event behavior to that HTML; server-rendered HTML alone does not prove hydration.

4. Hydration needs agreement

If client output does not match the server markup, the framework may warn, recover, or replace work. Deterministic initial data and clear browser-only boundaries are part of the design.

5. Islands narrow the activation surface

In an island approach, most of the page can remain static HTML while selected components receive client code. This can reduce shipped JavaScript, but it does not mean zero JavaScript or zero coordination cost.

Five-step method

1. Mark each UI region and state who owns its markup, state, and events.
2. Record where initial HTML comes from: static file, server render, or client render.
3. Record the activation unit: none, one full root, or selected islands.
4. For hydrated regions, identify the data and environment assumptions that must match.
5. Evaluate the tradeoff with evidence: interactivity need, JavaScript cost, dependency boundaries, failure fallback, and accessibility.

Worked case

A product page is delivered as HTML. Its article and pricing table have no client behavior. A quantity picker is an Astro island activated when visible; a separate account drawer is a React root hydrated from server markup. The record must not call the entire page a hydrated React app. It classifies two activation boundaries, explains what HTML remains useful before activation, and records the data each region needs to match.

Decision and evidence matrix

Failure probes and repair

• All components are React components.
• All modern web apps hydrate.
• Islands architecture means no JavaScript.
• This split-curriculum page does not claim ownership of the complete WEB-000 Web Mental Model.

For each statement, narrow the claim, create a counterexample, and name the observation that could confirm or reject it.

Transfer challenge

Change the scenario so that one assumption in the worked case no longer holds. Rebuild the UI Activation Boundary Record v1 without copying the earlier decision, then explain what changed in the input and what stayed stable in the decision rule.

What this does not prove

This lesson does not claim certification, production guarantees, or coverage of every implementation. Its conclusion is valid only within the scenario boundary, dated sources, and recorded observations.

Self-check

• [ ] Did I separate responsibilities from framework or tool names?
• [ ] Did I state at least one failure probe and its predicted observable?
• [ ] Are fact, inference, and design choice visibly separated?
• [ ] Did I record non-claims and missing evidence?
• [ ] Did I complete transfer in a changed context without a prepared answer?

Sources and freshness boundary

Sources were reviewed for the frozen Bible as of 2026-09-19. A review_due date triggers a versioned requalification; it does not authorize silent in-place edits.

• S-REACT — React identifies itself as a library for web/native user interfaces built from components. (https://react.dev/; review: 2026-10-17)
• S-REACT-HYDRATE — Current React hydration semantics. (https://react.dev/reference/react-dom/client/hydrateRoot; review: 2026-10-17)
• S-ASTRO-ISLANDS — Current Astro islands architecture description; example, not universal definition of all island implementations. (https://docs.astro.build/en/concepts/islands/; review: 2026-10-17)