Frontend Architecture MOC
Frontend Architecture MOC
Navigation hub for six frontend architecture pattern notes organised across three concern areas: state management, rendering, and component design. These patterns are the intra-application building blocks that structure how frontend applications manage state, deliver content to the browser, and compose UI components. See Design-Patterns-MOC for the root vault entry point and Application-Architecture-MOC for the macro-level shell patterns (including Micro-Frontends) in which these patterns operate.
All six notes follow the v2.0 cross-ecosystem convention: TypeScript-only examples drawn from both React and Angular ecosystems in the same note.
State Management Paradigms
Four genuinely distinct paradigms for managing frontend application state — each with a different answer to where state lives, how changes propagate, and who is responsible for derivation.
| Pattern | React Ecosystem | Angular Ecosystem | Use When |
|---|---|---|---|
| Flux/Redux | RTK 2.x (createSlice, createAsyncThunk) | NgRx 19.x (createReducer, Effects) | Shared state across 3+ feature areas; team > 5; explicit audit trail needed |
| Signals | use() + React Compiler (experimental) | Angular Signals (signal(), computed(), effect()) | High-frequency UI updates; O(1) targeted renders; Angular 17+ preferred |
| Atomic Stores | Jotai 2.x, Zustand 5.x | NgRx SignalStore, NgRx Signal State | Medium-scale apps; component-adjacent state; escape prop drilling |
| Observable/RxJS | RxJS in React (custom hooks) | NgRx Component Store, RxJS + async pipe | Async event sequences; complex temporal logic; Angular-first teams |
See State-Management-Patterns for full suitability thresholds and TS examples.
Rendering Strategies
Five rendering strategies spanning the server-to-client spectrum. Strategy choice determines TTFB, SEO posture, and infrastructure requirements — not a stylistic preference.
| Strategy | Next.js | Angular SSR | TTFB | SEO | Use When |
|---|---|---|---|---|---|
| SSG | generateStaticParams | RenderMode.Prerender | Fastest | Full | Content static at build time; documentation, marketing |
| ISR | revalidate: N | RenderMode.Prerender + CDN TTL | Fast | Full | Content changes but not per-request; product catalogue, blog |
| SSR | export dynamic = 'force-dynamic' | RenderMode.Server | Medium | Full | Per-request personalisation; authenticated data |
| CSR | Client-only component | RenderMode.Client | Slowest | Minimal | Highly interactive; auth-gated; SEO not needed |
| PPR/Streaming | React Suspense + <Suspense> | Angular @defer + @placeholder | Progressive | Partial | Mix static shell + dynamic slots |
See Rendering-Strategies and Hydration-Patterns for full trade-off matrices.
Component Design
Seven component composition patterns, each with an explicit GoF ancestor — understanding the ancestry clarifies why these patterns have the shape they do.
| Pattern | GoF Ancestor | React | Angular | Use When |
|---|---|---|---|---|
| HOC | Decorator | withAuth(Component) | — | Component-level wrapping: auth, error boundary, analytics |
| Custom Hook | Strategy | useForm(), useAuth() | — | Logic reuse without component wrapping (React 16.8+) |
| Render Props | Strategy | <DataFetcher render={fn}> | — | Explicit UI slot pattern; largely superseded by hooks for logic |
| Directive | Decorator | — | @Directive | DOM augmentation without changing component tree |
| Inject Function | Strategy/Factory | — | inject(AuthService) | DI-based logic composition in Angular 14+ |
| Compound Component | Composite | <Select><Option> | — | Implicit state sharing via React Context |
| Atomic-Design-Pattern | Composite | <Button> → <Form> → <Header> | Same hierarchy | Design system component hierarchy; atom/molecule/organism/template/page |
See Component-Composition-Patterns for GoF lineage details and Atomic-Design-Pattern for design system hierarchy.
Selection Guide
All Six Notes — Concern Area Overview
| Note | Concern Area | React Primary | Angular Primary | Prerequisite |
|---|---|---|---|---|
| State-Management-Patterns | State | RTK, Zustand, Jotai | NgRx Store, Angular Signals | None |
| Rendering-Strategies | Rendering | Next.js App Router | Angular SSR (@angular/ssr) | None |
| Hydration-Patterns | Rendering | React islands (Astro) | Angular @defer incremental hydration | Rendering-Strategies |
| Change-Detection-and-Rendering-Engines | Rendering | React Fiber (Virtual DOM) | Zone.js / OnPush / Signals | None |
| Component-Composition-Patterns | Component Design | HOC, hooks, render props | Directives, pipes, inject functions | GoF: Decorator-Pattern, Strategy-Pattern |
| Atomic-Design-Pattern | Component Design | Storybook, React component library | Angular CDK, Angular Material | Component-Composition-Patterns |
Frontend Architecture Selection — Start Here
Is your team's primary framework React or Angular?
-> Angular: Prefer Angular Signals for reactivity, @Directive for DOM decoration,
inject() for DI composition, NgRx for large shared state, Angular SSR for rendering
-> React: Prefer custom hooks for logic reuse, HOC for component wrapping,
RTK/Zustand for state, Next.js App Router for rendering
-> Both / framework-agnostic: patterns below apply across ecosystems
Does your application have complex shared state across 3+ feature areas? -> Yes, with explicit audit trail needed: State-Management-Patterns (Flux/Redux — RTK for React, NgRx for Angular) -> Yes, Angular app, high-frequency updates: State-Management-Patterns (Signals — Angular Signals) -> Yes, React app, medium scale: State-Management-Patterns (Atomic — Zustand/Jotai) -> No, mostly local component state: start with React useState / Angular signal(); no library needed
Does your application need server-side rendering? -> Content is fully static: Rendering-Strategies (SSG) -> Content is mostly static with periodic updates: Rendering-Strategies (ISR) -> Content requires per-request data or auth: Rendering-Strategies (SSR) -> Content is SPA with no SEO requirements: Rendering-Strategies (CSR) -> Mixed — static shell + dynamic slots: Rendering-Strategies (PPR/Streaming)
Are you dealing with performance-sensitive hydration (large interactive pages)? -> Yes: Hydration-Patterns — choose partial, progressive, or islands hydration
Does your team need to understand how frameworks detect and apply DOM updates? -> Yes: Change-Detection-and-Rendering-Engines
Are you building a component library or design system? -> Yes: Atomic-Design-Pattern — atom/molecule/organism/template/page hierarchy
Are multiple teams composing a large frontend from independently deployed parts? -> Yes, 3+ teams with independent release cadences: Micro-Frontends (in Application-Architecture-MOC)
Cross-Layer Lineage Chains
Frontend architecture patterns are not invented from scratch — they are applications of GoF structural and behavioural patterns to the UI rendering domain. The chains below make the inheritance explicit.
| Chain | Lineage |
|---|---|
| UI Decoration | Decorator-Pattern -> Component-Composition-Patterns (HOC = Decorator applied to components; Angular @Directive = Decorator applied to DOM elements) |
| Reactive State | Observer-Pattern -> State-Management-Patterns (Observable/RxJS paradigm; NgRx Effects = Observer-driven side effect model) |
| Strategy/Injection | Strategy-Pattern -> Component-Composition-Patterns (inject functions and React hooks both implement Strategy — swappable behaviour via interface) |
| Part-Whole UI | Composite-Pattern -> Atomic-Design-Pattern (atoms -> molecules -> organisms = Composite tree applied to UI component hierarchy) |
Sources
- Gamma, Erich et al. — Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1994 — GoF patterns referenced in lineage chains (Decorator, Observer, Strategy, Composite)
- React documentation —
react.dev— hooks, Suspense, React Compiler, server components - Angular documentation —
angular.dev— Angular Signals,@defer,RenderMode,inject() - Next.js documentation —
nextjs.org— App Router,generateStaticParams, PPR - Abramov, Dan — "Flux Architecture" and Redux design — redux.js.org, 2015–2024
- Frost, Brad — Atomic Design, bradfrost.com, 2013 — five-level component hierarchy
- NgRx team — NgRx 19.x / 21.x documentation —
@ngrx/store, Effects, SignalStore