Provide location and navigationType on loader arguments

[oscsx]

What is the new or updated feature that you are suggesting?

Provide the new location and the associated navigationType on the loader function arguments.

Why should this feature be included?

Considering that the loader function may be seen as part of the component itself, it is only natural that it can also have access to the mentioned data, like the component has through the useLocation and useNavigationType hooks.

The new location can be accessed currently by resorting to the router instance, at router.state.navigation.location. This seems to be undesirable since we are directly accessing the router instance state. Additionally, there seems to be some potential for this data to be unreliable, since lazy loaders run asynchronously and further navigations may occur in between. Passing this data as arguments of the loader function should ensure that the data is reliable.

I found no way of determining the navigationType inside the loader.

My particular use case is on an application that I'm migrating to react-router-dom 6. That application caches some data at each location. When navigating back to one of these locations, the cached data is retrieved so that the component can be rendered at the state it was before navigating away from it.

I could implement the desired behavior by performing the data load on a useEffect hook, since it grants me access to the useLocation and useNavigationType hooks. However, this would raise the need to render a loading state while the data is being fetched. Being able to implement the desired behavior in the loader function removes the need for a loading state on the component.

In a way, this is similar to #11227, but I'm requesting more data to be available.

[fpintos]

+1 for this.
I have a case where I would like to log where navigation came from and I could pass a state to navigate/Link and then read it from the loader function, and I don't want to include that as a URL segment or query string value.
Unless there is a particular reason why that should not be allowed.
I'm also open to other solutions to do that cleanly.

[depoulo]

Another use case: https://x.com/depoulo/status/1783140411394941081

[depoulo]

I found no way of determining the navigationType inside the loader.

Workaround:

// in some top level component
useBlocker(({ historyAction }) => {
  window.getNavigationType = () => historyAction
  // or any other way of sharing this with the loader,
  // but I prefer not to put makeup on my hacks
  return false
})

[depoulo]

Only downside is that you'll have to copy this into any nested useBlockers, and live with that dreaded warning from #12182

[depoulo]

That is, unless you patch react-router to support multiple blockers.

[jbojcic1]

Would also solve this remix-run/remix#10721