Command Palette

Search for a command to run...

Hectal
Phase 22Advanced23 of 28 in React

Architecture and Patterns

Structure a React codebase that grows: feature folders, component APIs, logic apart from UI, an error strategy, i18n, large-app boundaries and anti-pattern fixes.

By now you can build almost any screen. This phase is about the code around the screens: where files go, how a component's props are designed so other people can use it, how logic is kept apart from markup, where errors are caught, how text and numbers adapt to every language, and how a codebase stays healthy when ten or a hundred people work on it.

Architecture can sound abstract, so every topic here is concrete: a small piece of code shown before and after a refactor, running live. A single live example often pretends to be several files, with comments marking where each file would start. Real folder trees, lint configs and monorepo setups are shown as plain code blocks.

The phase builds on custom hooks and reuse patterns (Phase 10), state at scale (Phase 15), performance (Phase 16) and testing (Phase 17), and it ends with the anti-patterns that appear in almost every real codebase, each one broken and then fixed.

0/7 · 0%
7 topics ~3 h 26 code blocks & diagrams
Start with the first topic
1
22.1

Project Structure That Scales

Group files by feature (everything about the cart in features/cart/) instead of by file type, keep each thing next to the code that uses it, put truly generic UI in a shared folder, give each feature one public entry point, and let a lint rule enforce who may import what.

27 min 1 diagram 3 code practice

2
22.2

Designing Component APIs

A component's props are its API: name them like the platform (onChange, disabled), support both controlled (value + onChange) and uncontrolled (defaultValue) use, prefer composition with children over piles of configuration props, express looks as variant/size, and leave escape hatches: className, ...rest and ref.

28 min 3 code practice

3
22.3

Separating Logic from UI

Put what the component does (state, data loading, rules) in a custom hook or a plain function, and how it looks in presentational components that only take props; headless components push this furthest by shipping behaviour and accessibility with no markup at all, and both halves become easy to test and reuse.

29 min 4 code practice

4
22.4

An Error Handling Strategy

Decide in advance where each kind of error goes: expected errors (validation, 404, a refused action) are shown inline or as a toast where they happen, unexpected bugs are caught by error boundaries placed at the root, route and widget levels, every error is reported once from a central place, and only temporary failures are retried, with backoff.

29 min 4 code practice

5
22.5

Internationalisation

Internationalisation (i18n) means building the app so it can speak any language and follow any region's rules: format numbers, money, dates and lists with the browser's Intl APIs, choose plural forms with Intl.PluralRules, keep all text in translation files read through a t() function (react-i18next, FormatJS), and lay out pages with logical CSS so right-to-left languages work.

29 min 4 code practice

6
22.6

Large Apps: Monorepos, Micro-Frontends and Module Boundaries

When many teams share one frontend, a monorepo keeps several apps and packages in one repository with shared tooling, and micro-frontends split one product into separately deployed apps composed at runtime (for example with module federation); both enforce module boundaries, both have real costs, and most apps are better served by a well-structured single app first.

27 min 3 code practice

7
22.7

Common React Anti-Patterns and Their Fixes

Six mistakes show up in almost every React codebase: copying props into state, chains of effects that set state, index keys on lists that change, giant components, drilling every prop everywhere, and memoising by reflex; each has a small, well-known fix taught earlier in this course.

28 min 4 code practice

Practise this phase

Hands-on exercises: write the code, see your page live, and press Check to have it tested automatically.

1

A switch that works controlled and uncontrolled

The Switch component only keeps its own state, so the parent can't control it. Make it support both modes, like a native input: checked + onCheckedChange (controlled) and defaultChecked (uncontrolled).

Intermediate
2

Extract a useFilter hook

FruitList has working search logic written inline. CityList needs the same behaviour but doesn't filter at all.

Intermediate
3

Fix mirrored state and an effect chain

This invoice has two anti-patterns from Topic 22.7. Switching the customer in #customer doesn't update the name field #name (it was copied into state once). The total and shipping are kept in state and updated by a chain of effects.

Intermediate
4

An order summary for any locale

The order summary hard-codes US formats. Make it follow the locale chosen in #locale (en-US uses USD, de-DE uses EUR, ja-JP uses JPY).

Advanced
5

A dashboard that survives a broken widget

The Weather widget throws while rendering, and with no error boundary the whole dashboard disappears.

Advanced