Replies: 3 comments 1 reply
-
+1 for this. |
Beta Was this translation helpful? Give feedback.
-
Another use case: https://x.com/depoulo/status/1783140411394941081 |
Beta Was this translation helpful? Give feedback.
-
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
}) |
Beta Was this translation helpful? Give feedback.
-
What is the new or updated feature that you are suggesting?
Provide the new
location
and the associatednavigationType
on theloader
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 theuseLocation
anduseNavigationType
hooks.The new
location
can be accessed currently by resorting to the router instance, atrouter.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 theloader
.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 theuseLocation
anduseNavigationType
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 theloader
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.
Beta Was this translation helpful? Give feedback.
All reactions