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.