Request "type" visibility in route handlers/middleware

[brophdawg11]

Currently, we normalize request.url when calling loaders/actions on the server between document/data requests by stripping the .data extension and removing any routes query params.

react-router/packages/react-router/lib/server-runtime/server.ts

Line 115 in e7879a8

normalizedPath = normalizedPath.replace(/\.data$/, "");

react-router/packages/react-router/lib/server-runtime/data.ts

Line 26 in e7879a8

request: stripRoutesParam(stripIndexParam(args.request)),

We actually don't currently do this on middleware, but that's just a bug we'll fix up.

I believe the original reasoning for this was to avoid potential footguns by allowing branching in your loader/action that behaved differently based on document vs. data which could result in your application behaving differently on SSR loads versus client-side navigations - something Remix v1 worked hard to ensure always behaved the same.

However, we have had a number of requests for this over time - and more recently with the Instrumentation APIs, it's tricky to monitor document requests differently from data requests. You can do it today with a custom server and using getLoadContext to set a value on context because that has access to the raw unmodified express req instance (or whatever else applies for your runtime).

Along the same lines, we have had many requests over the past few years to know when a loader is being called as part of a revalidation versus the initial load. We should go back and find out some of the use cases for this to see if it's something we should also consider here or not.

Options

I think we have a few potential options here:

1. Stop normalizing the URL and pass the exact URL from the HTTP request into the loaders/actions
   • This is the simplest change because we just delete code and do less
   • It would be breaking so would have to go behind a future flag
   • This doesn't help with the revalidation aspect though since you still can't differentiate a navigational versus revalidation .data requests
2. Continue normalizing, but add custom headers to the request (i.e., X-React-Router-Original-Url and X-React-Router-Revalidation-Request)
   • These align with some of the other custom headers we support throughout the app today
   • The existing headers are currently considered pseudo-private implementation details, but these new ones would be considered public API (and honestly I sort of think they should all just be documented as public)
3. Add new parameters for originalUrl and isRevalidation
   • I don't actually like this one because it explodes our the API surface a bit but adding it for completeness 😂

I like (1) for it's simplicity and the ability to delete code, but we would still need something like (2) or (3) to handle identifying revalidation requests if we went that route. I like (2) because it's non-breaking and handles both cases in the same manner.

Looking for Feedback

I'm curious to get some feedback from folks on a few things:

1. What do you use request.url for today in loaders/actions/middleware? Would it be annoying if it started reflecting .data?routes=... for data requests? Are there scenarios where you would need to write more code to get the "normalized" URL?
2. What are the use cases you have for wanting to differentiate document versus data requests?
3. What are the use cases you have for wanting to differentiate revalidation reqeusts?

[sergiodxa]

I think the headers are better. It's common to use custom headers for tools like proxies to pass values to the app code, and they don't modify the URL.

I think we should have a header X-React-Router-Request-Type that can be revalidation, navigation, or fetcher (not sure about this one). If the header is not present then it was a document request.

I don't think the original URL with .data or ?_routes are actually needed for anything, just to know the reason of the request.

[wiscat]

What's the current best way for detecting data requests?

my use case:

• initial load: Await data in the loader for server-side rendering (for SEO)
• client navigation: Behave as an SPA - skip loader delays for fast navigation and fetch data via React Query

[brophdawg11]

The best bullet proof way is to use your own express (or other server) and set something in getLoadContext where you have access to the raw Express req(or equivalent) before React Router normalizes it.

But if you're using react-router-serve, I think folks have been using https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Mode and/or https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-Fetch-Dest with some success.

[hasanayan]

Hi @brophdawg11,

In our case, we need to distinguish between:

• a navigation-triggered data request, where the user is moving to a new route, and
• a background revalidation/fetch, where the user stays on the same route.

We use that distinction to decide where to send the user after auth redirects:

• for navigations, redirect back to request.url
• for background revalidations/fetches, redirect back to Referer

We currently do this by patching react-router to add an X-Request-Type header client-side, which has worked fine, but we’d obviously prefer to remove that patch.

From your comment, it sounds like we may be able to infer this in the Express handler from the request URL shape. Before relying on that, I wanted to confirm whether this is expected/stable behavior:

1. Initial document request to /A -> request URL is /A
2. In-app navigation to /B -> request URL is /B.data
3. Loader revalidation for /B -> request URL is /B.data?_routes=...
4. useFetcher load for /C -> request URL is /C.data?_routes=...

If that understanding is correct, then it seems like checking for the presence of _routes would let us distinguish navigation-related data loads from revalidation/fetcher requests. Is that something we can safely rely on?

[brophdawg11]

Thanks for sharing - it looks like your patch only indicates revalidations coming from useRevalidator()? Not "revalidations" after Form/fetcher submissions or "revalidations" of ancestor/reused route loaders on GET navigations?

[hasanayan]

After our patch:

• createClientSideRequest adds X-Request-Type: fetch if the header is missing.
• startNavigation accepts an optional opts.isRevalidation argument. If it’s falsy, we add X-Request-Type: navigation.
• In revalidate, we make sure opts.isRevalidation is passed as true to startNavigation.

I believe this correctly sets the header for all of the cases you mentioned, and my quick manual testing seems to confirm that.

I’m happy to open a PR with tests covering all of these cases, and we can hash out details there, like the exact header name. I’m also starting to think X-Request-Intent: fetch | navigation might be a better name.

[hasanayan]

@brophdawg11 Waiting on your go-ahead to open the PR if this sounds good to you.

[brophdawg11]

The more I think about it, the header concerns me a bit because if you return different data based on the header then you open yourself up to cache poisoning if you aren't also enumerating your cache key based on the header. Maybe we should open a new RFC for this specific feature and see if it gains traction?

[hasanayan]

Alright, here is the RFC #15021

[brophdawg11]

This was shipped as the passThroughRequests future flag in 7.13.2 (unstable), stabilized in 7.15.0, and became the default behavior in 8.0.0.