c8e2fba13e
Rewrites all 12 frontend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
43 lines
1.5 KiB
Markdown
43 lines
1.5 KiB
Markdown
# Pre-fetch route data using Angular route resolvers
|
|
|
|
- Status: accepted
|
|
- Date: 2026-04-26
|
|
|
|
## Context and Problem Statement
|
|
|
|
Route components need data to render. Should that data be fetched before the route activates (resolver) or after the component renders (in-component)?
|
|
|
|
## Considered Options
|
|
|
|
- Angular route resolvers
|
|
- In-component fetching (ngOnInit)
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Angular route resolvers", because components receive data immediately via `ActivatedRoute.data`, eliminating the need for per-component loading states on initial render.
|
|
|
|
### Positive Consequences
|
|
|
|
- No loading state needed in components for the initial data fetch.
|
|
- Loading indication can be centralised at the router level via router events.
|
|
- Data availability is guaranteed before any component lifecycle hook runs.
|
|
|
|
### Negative Consequences
|
|
|
|
- Navigation appears paused while the resolver fetches — there is no partial render before data arrives.
|
|
- Resolver errors must be handled explicitly to avoid navigation hangs on API failure.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### Angular route resolvers
|
|
|
|
- Good, because data is available immediately in the component.
|
|
- Good, because loading logic is centralised outside the component.
|
|
- Bad, because navigation is blocked until the resolver completes.
|
|
|
|
### In-component fetching (ngOnInit)
|
|
|
|
- Good, because navigation is instant — component renders immediately.
|
|
- Bad, because each component must manage its own loading and error states.
|
|
- Bad, because inconsistent UX across routes if not implemented uniformly.
|