Passing the whole ctx.params() object makes an Angular route resource reload on every navigation

`params: () => ctx.params()` is the line to flag in review. It type-checks and it does the wrong thing: the router creates a fresh params object on every navigation, so the resource sees a new reference and reloads even when the sku did not change ^[9]. Writing `params: () => ctx.params()['sku']` fixes it, because the resource then reacts only to the primitive value ^[10]. Under the object form, any navigation into the route costs one loader call whether the sku moved or not; under the primitive form, a navigation that leaves the sku alone costs none ^[21]. A bug that renders the right data while doubling the requests behind it tends to survive review.

Blocking also decides where the loading state lives. The router handles loading and error before the component exists, and the input arrives as the resolved value `T` and not `Resource<T>` ^[14]. A blocking route therefore keeps its spinner and its failure path outside the component, and a route that wants them in its own template wraps the resource in `nonBlocking()` ^[15]. In my view blocking is the right default for a detail page with nothing to draw before the record arrives; a route whose shell is useful on its own is where the extra template branch is worth writing.

The post names `router_resource.ts` as the file covering everything between `resource({...})` in the route config and the value arriving in the component ^[17]. It says three things come out of that file: how blocking works, why the UI does not flash a loading skeleton when you navigate between two similar pages, and where a navigation cancellation can leave you stuck if you do not understand the reload guard ^[18]. Blocking is the one worked through in the published text, which breaks off mid-snippet inside the `nonBlocking()` example ^[19]. The other two are stated as conclusions.

Adoption is two lines at bootstrap. `withRouterResources()` opens the gate, and `withComponentInputBinding()` is what delivers a resolved resource as a plain `input()`; without the second, components read `ActivatedRoute.resources` by hand ^[4][5][20]. The `resources` function runs in an injection context, so `inject(ProductService)` sits at the top of it with no factory wrapper ^[8]. It can be `async` when the loader needs a dynamic import first ^[11].

The case made against resolvers is sequencing and refresh: they run one after the other, parent to child, and cannot be refreshed without triggering a full navigation ^[2]. The dev.to write-up calls that "a price you pay on every navigation" ^[3].