Files
adastra_app/docs/decisions/0006-data-loading-via-route-resolvers.md
julien c8e2fba13e docs(adr): convert all ADRs to MADR 2.1.2 format
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.
2026-04-26 16:50:34 +02:00

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.