trpc/react-query render logic
I've made the attached diagram to try and explain the scenario, but for additional context, my issue is this:
I have a page that conditionally renders two main views. the editable view submits a form, after which I would like to render the opposite view, but with the new data.
currently, i'm invalidating on success, though it seems that the completion of invalidate doesn't ensure that my other component will have refetched its data yet. my idea would then be to block my readonly component on both loading AND fetching. the issue here is that toggling between views when there is not a form submission ends up showing a load state, presumably because isRefetching is true even if its fetching from cache.
im primarily wondering if there's a fundamental problem in where i have the data/handler ownership on the page. The code is here as well (ignore the ListEditor jsx for the most part, its a huge mess): https://github.com/jackbisceglia/p4p/blob/selections/src/pages/me.tsx
9 Replies
does the mutation alter what's cached for the readonly view? or is the subsequent request necessary
yea it does alter it. essentially, the data that is mapped over in either view is very similar, and is related (the editable view just has some extra options). So when the user submits their edits, those changes should be reflected in the readonly view
are you saying i should have the return value from the mutation directly update the state of the readonly view, rather than do a refetch?
I think optimistic UI would do you well in this case. Afaik, you can’t wait for an
invalidate to finish, but you can manually set the new data and rollback on error: https://tanstack.com/query/v4/docs/react/guides/optimistic-updatesOptimistic Updates | TanStack Query Docs
When you optimistically update your state before performing a mutation, there is a chance that the mutation will fail. In most of these failure cases, you can just trigger a refetch for your optimistic queries to revert them to their true server state. In some circumstances though, refetching may not work correctly and the mutation error could ...
Though… invalidate may return a Promise, which you could await and then call navigate afterwards, which may be just what you want
Looks like invalidateQueries returns a promise, not too sure how that translates to trpc
ok ill try going this route, thanks
Optimistic UI should do the thing but if it doesn't it seems like the toggle makes your components unmount. On the toggle they have to rerender so they also fetch (if I understand this correctly). If that's the case then maybe you will also have to keep your currently hidden component somewhere else in the DOM tree (could be done using portals) so it's ready whenever you need to swap between them
u can fetch independently of what's happening with the rendering, no need to do anything with portals
Of course but swapping between views probably causes both a rerender and a refetch (it will happen even if there's cached value)
@maxtreme if you adjust your cache settings it wont refetch, or you can have the queries be in a parent component of the views being swapped which also wouldn’t refetch. React query gives control over refetching behavior via “staleTime” and “cacheTime”.
Rerendering is expected if your state changes, that’s expected and nothing to worry about