Proposal: fetch prop for HydratedRouter

[rossipedia]

HydratedRouter should support a fetch prop that allows you to customize the fetch implementation used in Framework Mode for /__manifest and route data requests. RSCHydratedRouter already provides this, so a) there's prior art and b) this would bring feature parity to both hydrated routers.

It's also a pretty useful power-user escape hatch, allowing for several use cases that are currently hacky or difficult to implement:

• Hosting SSR and data handlers on separate origins
• Adding custom headers / trace baggage to data requests
• Globally redirecting specific URL patterns to another origin
• etc

Usage is exactly what you'd expect:

<HydratedRouter 
  // same signature as window.fetch
  fetch={(request: RequestInfo): Promise<Response> => {
    // Add custom headers, globally measure request timings, point the URL somewhere else,
    // or even load up the `Response` from browser storage for local-first scenarios.
    // The limit is your 🌈⭐️ imagination 🌈⭐️
    return window.fetch(...)
  }}
/>

Note

Q: Why not use the same signature as window.fetch?
A: window.fetch has the same signature as the Request constructor, and the standard even dictates that the first thing window.fetch() does is to pass those parameters directly to new Request(input, init). The intention is to make it easier to call directly. Since this fetch prop isn't called by your code, but rather by React Router itself, normalizing the custom fetch signature to just accept that Request instance by itself makes implementations a lot simpler, since you don't need to worry about dealing with a string, or any possible init params. You just have a Request, and you need to return a Promise<Response>. Easy-peasy.

(updated to reflect the current implementation signature)

[brophdawg11]

Linking a lot of related things this would probably address:

• global network error handling: Better error handling for actions, fetchers, revalidations (unexpected errors and network errors) #12804
• global retry mechanisms: Built-in Retry Mechanism #12892
• custom headers: Custom headers on form requests remix#4397

[hasanayan]

Perhaps this could address #15021 as well?

[brophdawg11]

Maybe? Would you need additional to implement that on top of this API?

[hasanayan]

Within that proposed fetch callback, being able to differentiate ".data requests without navigation" and set a header does the job.

[brophdawg11]

This would also handle adding formData fields (#11285, #14194), but not on a per-route level. Do you see a way to conveniently do this from clientAction? the obvious solution is arguments to serverLoader but curious if there's ways that don't need to alter that API as well.

[rossipedia]

My personal opinion is that serverAction / serverLoader should probably be left alone. I feel like adding options/args to those methods would be opening a can of worms.

At the very most it should probably reflect this proposal and just add the same thing: a fetch option.

export function clientAction({ serverAction }: Route.ClientActionArgs) {
  return serverAction({
    fetch(input, init) {
      // input is an instance of `Request` that would normally go to `window.fetch`
    }
  })
}

Although I'm not entirely certain this is The Way™ either. I can easily see this spiraling out into "I want [specific fetch impl] to apply to this route and all children", which would be a reasonable request if this were possible, which would require either affecting how clientMiddleware works or adding Yet-Another-Route-Module-Export. Which probably isn't what we want.

[jasonhuang-dev]

I hadn't noticed this discussion before, but I created a new one describing more use cases for this proposal. #15472

[brophdawg11]

Can you just bring those use cases into this comment thread and close that proposal so we don't have a duplicate?

[jasonhuang-dev]

Sure thing!

The case I described in #15472 could lead to a severe production incident if the React Router application is deployed across multiple regions.

In applications deployed across multiple regions with rolling deployments, a __manifest request from a client that was served by Region A may be routed by the CDN to Region B — which may not yet have the new version deployed. Many CDN and API gateway setups support pinning a request to a specific origin or region via a custom request header (routing hint headers are a common pattern in multi-region infrastructure).

[brophdawg11]

Thanks! Have you been able to try out the new unstable_fetch prop? Let us know if it's working for your use cases

[brophdawg11]

Adding two more related proposals that have been consolidated into this one:

• #10002 — Allow custom headers for submit and fetcher.submit
• #12023 — Allow configuration of credentials in useFetcher.submit

Implementation is tracked in PR #15586. For Framework Mode's JavaScript-issued router requests, the proposed HydratedRouter.unstable_fetch hook enables application-defined headers and credentials policies rather than adding per-submission options. Browser-managed data prefetches bypass the hook.

Authored by an AI agent on behalf of @brophdawg11

[brophdawg11]

PR: #15586

[brophdawg11]

Released in 8.5.0! We'll keep this discussion open until it stabilizes for any further discussion during early testing.