loaderDeps does not provide `{ context }`
I want to define
loaderDeps from context not search (see docs: https://tanstack.com/router/latest/docs/framework/react/api/router/RouteOptionsType#loaderdeps) but it seems only search is defined? Is that a bug or on purpose?
If it is on purpose, why is it only possible to define search params as loaderDeps? Since I use the context in the loader to pass data from the context as fetch arguments, I would like the loader to be triggered again as soon as the context data I'm using changes.
Reference:
https://github.com/TanStack/router/issues/12167 Replies
optimistic-gold•2y ago
@Tanner Linsley should
context be accessible within loaderDeps?exotic-emerald•2y ago
Context is just weird right now. Its not tracked like state is for changes
And it’s not serialized across SSR
So I’m weary to pass it
What’s the use case?
harsh-harlequinOP•2y ago
What’s the use case?A React context that is used across multiple routes but not all. The context handles filter state and passes it to the router context to fetch data when filters are changed.
exotic-emerald•2y ago
Gotcha.
Well, we would need a way to “trigger” route loading when the context value changes, just like react.
overseas-lavender•2y ago
Do you have any news regarding this? I have a similar use case: I want to trigger the loader when some value of the context changes.
cloudy-cyan•2y ago
i would see the
context more as a static dependency injection, and something I can write towards, not a reactive thing to read from. In terms of a router, the reactive part is usually the url.exotic-emerald•2y ago
Right
Most situations where context becomes dynamic, you start to see bugs
e.g. you start to store some state in it, then expect routes to "invalidate" when that state changes
But the router context isn't state, nor does it live in react
@TkDodo 🔮 is spot on that it's more about dependency injection
In fact, I've debated removing the ability to augment it with anything remotely dynamic