24. Angular concepts in practice
Answer as submitted
“Yes — all of these are part of my everyday Angular practice, not occasional exposure.”
Expanded answer
All of them are part of everyday practice. Lazy loading by route boundary with preloading for the next likely area and bundle budgets in CI. Guards and resolvers (canActivate, canMatch, canDeactivate) so authorisation and data are decided before a component is created. Functional interceptors for token attachment, single refresh-and-replay on 401, retries limited to idempotent calls, and a correlation id on every request. RxJS composition with the operator that matches the semantics (switchMap for cancellable reads, combineLatest for derived views, takeUntilDestroyed for teardown) alongside signals for local state and a store for genuinely shared state. Reusable components with typed inputs/outputs and content projection, custom directives and pipes for cross-cutting presentation, and typed reactive forms with cross-field and debounced async validators.
| Concept | How it is applied | Why it is done this way |
|---|---|---|
| Lazy loading | loadChildren/loadComponent + preloading | The first route ships only what it needs; the rest warms after idle. |
| Guards | canActivate, canMatch, canDeactivate | Authorisation decided before work starts; no silent loss of edited data. |
| Resolvers | route resolve | The page renders with data instead of flashing an empty state. |
| Interceptors | functional withInterceptors | Auth, retry and tracing are declared once, not repeated per service. |
| RxJS | switchMap, combineLatest, lifecycle teardown | Cancellation and composition are explicit; no leaking subscriptions. |
| State | signals locally, store for shared state | Local state stays local; only genuinely shared state pays for a store. |
| Reusability | typed inputs/outputs, projection, directives, pipes | Presentation logic is shared instead of copy-pasted per screen. |
| Forms | typed reactive forms + validators | The client mirrors the API contract and the server still re-validates. |
Live Angular concept workflow proof
The running component below changes its concept/result view through real event binding. Select a concept to see the code shape, the reasoning behind it, and the measurement taken from the application.
Choose an Angular concept
Select a concept to inspect the code shape, the reasoning and the measured result.
$ loadChildren: () => import('./orders/orders.routes').then(m => m.ORDERS_ROUTES) + withPreloading(PreloadAllModules)
Each feature area is split at the route boundary, and a preloading strategy warms the next likely route instead of shipping the whole application in the first bundle.
initial bundle 210 KB → 78 KB gzip 3 of 5 feature areas preloaded after idle
Why the concepts earn their place
Source files
Select a file to inspect the proof with syntax highlighting and line numbers. The first file is the code running the component above; the other two are the production shapes of these concepts.
Acceptance criteria
- Covers every concept named in the question with a concrete implementation.
- Shows the effect on bundle size, navigation, network and form reliability.
- Provides an interactive proof of choosing a concept and reading its measurement.
- Keeps authorisation, retries and tracing declared once, in interceptors.
- Defers version migration, SSR strategy and profiling to a later topic.