Aabha · Frontend foundations

React with TypeScript · Harbor Together

React with TypeScript: Harbor Together, rebuilt as a UI

Version 2026-10-14.1. This course follows Aabha’s HTML/CSS and Basic JavaScript courses.

What you will make

A local, fictional community-event explorer: filter events, save event IDs, inspect an event on its own URL, and check a practice form without transmitting it. You will rebuild the familiar Harbor Together interface using components and typed data. You will explain what belongs in state, what can be calculated, and what must be synchronized with a browser system.

Entry check

Before starting, explain array map/filter, object destructuring, imports/exports, promises, fetch, try/catch and a DOM event handler. Build a labeled HTML form and describe its keyboard behavior. If these are unfamiliar, revisit the corresponding Basic JavaScript lessons. A short diagnostic is supplied. This course introduces TypeScript and package tooling; it does not repeat JavaScript syntax from scratch.

Ordered route

  1. Set up a repeatable React workspace (100 minutes): Node/npm, package.json and lockfile, Vite, TypeScript versus JavaScript, TSX, render entry point, strict checks. Checkpoint 01: a first typed page.
  2. Describe UI with components and props (100 minutes): pure rendering, JSX expression boundaries, composition, typed props and conditional UI. Checkpoint 02: event cards.
  3. Model trustworthy event data (110 minutes): object and union types, optional fields, inference, unknown, narrowing and runtime validation. Checkpoint 03: validated fixture data.
  4. Connect interactions to state (110 minutes): event handlers, state snapshots, immutable functional updates, lifting state and deriving visible results. Checkpoint 04: searchable events.
  5. Keep identity through changing lists (90 minutes): stable keys, saved-ID state, preserving/resetting component state and avoiding duplicated objects. Checkpoint 05: saved events.
  6. Build an honest accessible practice form (120 minutes): controlled fields, typed events, native constraints, custom feedback, focus and synthetic-only submission. Checkpoint 06: practice confirmation.
  7. Synchronize with browser systems (100 minutes): effects versus calculations/events, dependencies, cleanup, Strict Mode, failure-tolerant localStorage. Checkpoint 07: remembered event IDs.
  8. Handle remote-shaped data locally (130 minutes): discriminated loading states, fetch and HTTP failures, validation, stale work, abort/cleanup and retry. Checkpoint 08: local fixture loader.
  9. Give screens meaningful URLs (100 minutes): declarative client routing, links, route parameters, missing-event behavior, URL/history versus local state and focus/title changes. Checkpoint 09: explorer and detail screen.
  10. Test behavior and prepare a build (130 minutes): Vitest, Testing Library, user events, async tests, behavior versus implementation assertions, production assets and acceptance evidence. Checkpoint 10: integrated reference app with checks.
  11. Build and defend your own explorer (5–7 hours): an independent starter, six milestones, acceptance criteria, a scored rubric and a separately stored reference.

The ten taught modules total about 18 hours 10 minutes; with the capstone, allow roughly 23–25 hours. These estimates include reading and practice but are provisional and unpiloted. Setup and revision may add time. Validate pacing with beginners before making scheduling or marketing claims.

How to study

Read a concept, predict a result, run the checkpoint, then change it. Each module includes a guided build, a repair, and a transfer exercise; worked solutions live separately. Keep a short evidence log: prediction, observed result, explanation, next experiment. Do not equate a green build with working or accessible UI.

Assessment

Complete the entry diagnostic, two mid-course assessments, a release assessment and the capstone. Advance when you can explain a design choice and reproduce behavior without copying a solution. Assessment answers and the capstone reference are intentionally separate from the questions and starter.

Boundaries

All data are synthetic. No real accounts, payments, registrations or external submissions. No server, Next.js, server components, backend authentication, global-state library or paid service. Routing uses one focused client-side library when multiple screens create a genuine need. The build is prepared locally, not published. Browser, device, screen-reader and beginner-pilot checks remain explicit acceptance tasks unless verified in the QA report.