Where should a screen's data request be declared: inside the component that reads it, on the route, or in a shared definition?

"Where is the request declared" sounds like a style question. It is really an architectural one, because the declaration site fixes who has the *authority* to start, stop and observe the request — and those capabilities are exactly what you need when a screen turns out to be slow a year later. ## The three capabilities the site decides 1. **Who can start it early.** Only a layer that runs before the screen exists can move a request off the critical path. A request written inside a component can never be speculated on from a link, because the thing that would start it does not exist until after the navigation. 2. **Who can supersede or cancel it.** Ownership follows the site: a component owns the lifetime of what it started; a router owns the lifetime of a pending transition; an intent handler owns something that outlives the element that fired it. 3. **Who sees the failure.** A failure inside a rendered screen can be shown next to the thing that failed, with a retry in place. A failure before the screen exists must be handled by the route, which usually means a whole-screen error — a coarser, sometimes worse, experience. ## Comparing the three sites | | In the reading component | On the route | In a shared definition used by both | |---|---|---|---| | Earliest possible start | after that component renders | when the route matches | whenever any layer chooses | | Cancelled or superseded by | the component's teardown | the router's transition | whoever started it | | Failure surfaces | in place, with local retry | before the screen, usually whole-screen | wherever the read happens | | Reuse across screens | duplicated per screen | duplicated per route | one definition, many call sites | | Risk of two different keys for one dataset | high | medium | low | | Coupling | none to routing | component needs a route entry | call sites depend on a shared catalogue | | Best for | data an interaction reveals | data the screen is meaningless without | anything read from more than one place | The table is the argument for the hybrid. The first two columns each make one thing easy and one thing impossible; the third makes the *timing* a separate, movable decision. ## The policy to actually propose - **Define once.** Every remote read gets a named, parameterised definition with a deterministic key derived from its parameters. Nothing outside that definition constructs the key by hand. - **Block deliberately.** Only data the screen would be misleading without may hold a navigation. Everything else is either started at the boundary and read as it settles, or started by the component. - **Speculate where it is cheap.** Intent handlers refer to the same definitions, so a prefetch and the real read resolve to the same in-flight work instead of two requests. - **Keep local reads local.** Data revealed by an interaction — a panel the user opens, a row expanded — belongs to the component. Hoisting it to a route pays latency for visits that never open it. - **Make the exception explicit.** When a screen must serialise two requests, the dependency is written down in the place that starts them, so the next reader sees the chain rather than inferring it from two files. ## The organisational half Declaration sites are also team boundaries. If routes are owned by a platform group and screens by feature teams, putting requests on routes makes every data change a cross-team change; putting them inside components makes screen performance invisible to the group accountable for it. A shared definitions layer is the only arrangement where both teams can act: the feature team owns what a request is, the platform layer owns when transitions may block. Say this out loud in a leadership interview, because it is the reason the hybrid wins in real organisations and not merely in a diagram. Two guardrails keep it honest. First, a review rule that a new blocking entry on a route needs a stated reason, or the blocking set grows monotonically until every navigation is slow. Second, a budget expressed from the user's side — time from committed navigation to the screen being useful — so the discussion is about that number rather than about which file the request lives in. ## Migration, when the codebase already fetches everywhere Do not rewrite the tree. Extract definitions for the requests on the slowest surfaces first, leave the components reading them exactly as they did, then move the start site for those definitions to the route or an intent handler. Because the read did not change, each step is independently shippable and independently measurable, and you can stop when the number is good enough instead of finishing a refactor for its own sake.