api.withTRPC doesn't show isLoading or isRefetching on cache invalidation
I am using the default t3 app with Prisma, next auth, trpc and typescript currently , it's my first time with next in general so still getting the hang of things so bare with me.
I've wrapped one of my pages (
/vm
) with api.withTRPC export default api.withTRPC(VMS)
so that the data is fetched for queries on the server before returning the page (At least this is my understanding, follow up queries are streamed still). However, in another component, I've attempted to invalidate my query with the following code
I've noticed that this doesn't seem to do anything, when I am using this query in my /vm
route, if I destructure isLoading, isRefetching and isFetching from api.vm.getAll.useQuery(), none of these actually get set to true and as a matter of fact, the entire component doesn't get a re-render which I can just test by putting in a console log in the component.
If I opt not to wrap the export with withTRPC
then it works completely fine but also doesn't fetch the data before returning the page which causes an annoying loading animation every time I load the page for the first time. I can probably adjust my loading animation accordingly but I'd prefer to get to the bottom of this so I can avoid building an SPA in Next lol.
As a quick snippet, I've implemented my vm subrouter the exact same as the example router
This behavior is also identical whether I have ssr: true
or ssr: false
Happy to take this question to a TRPC forum instead if this is too specifically a TRPC problem but figured I'd ask, I'm sure this is something either super obvious or just something being done wrong but thanks in advance for the help.4 Replies
you should probably just wrap your
_app
in withTRPC
if you use useContext
in a component that's not wrapped in withTRPC
, it won't do anything
because withTRPC
has the context providers in it that this stuff needsThanks for the suggestion. I took a look, it looks like that was already wrapped by default (Or maybe I did it when I was first getting started).
With that said, I've just managed to solve the problem... I had a component "Navbar" that wasn't using TRPC but was wrapped with
withTRPC
and inside that component was the one where I was trying to invalidate the cache (NavbarButton). I actually don't fully understand why this would break the ability to invalidate the cache but removing it fixes the problem.
Thank you for your taking the time to help out!the way react context works is it travels up the tree until it finds the first valid context provider
so if you had a second wrapper, the app as a whole and the bits inside that wrapper were getting their context from different places
Was about to fall asleep (1:30am here) and had that realisation moments before I would’ve fallen asleep, that of course that’s what was happening. Thanks again for the insight, genuinely appreciate it.