julien
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.
1.5 KiB
1.5 KiB
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.