feat: tanstack query plugin improvements, refetch control & state#643
Draft
DorianMazur wants to merge 6 commits intomainfrom
Draft
feat: tanstack query plugin improvements, refetch control & state#643DorianMazur wants to merge 6 commits intomainfrom
DorianMazur wants to merge 6 commits intomainfrom
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Two gaps in the TanStack Query integration were causing problems:
1. No distinction between re-observation and explicit sync
On main,
get()calledobserver.refetch()on every call after the first, whether the observable was simply being re-observed (remount) or the user explicitly calledstate$.sync(). This meant every re-observation triggered a network request, bypassing TQ's own refetch policies (refetchOnMount,staleTime, etc.). It also meant there was no way to distinguish "the component remounted" from "the user wants fresh data now".2. Loading & error states were silently swallowed
The
subscribecallback only handledstatus === 'success'. Errors were ignored, initial load errors couldn't reject theget()promise, and there was no way to observe TQ's granular state (isFetching,fetchStatus, etc.).Solution
1. Re-observation vs explicit sync
The
getfunction now uses asubscribedInThisCycleflag to distinguish the two cases. The sync infrastructure callssubscribe()beforeget()on (re-)observation, but skipssubscribe()on an explicitsync()when already subscribed:get()(mount)subscribe()thenget())refetchOnMount,staleTime, etc.)sync()(get()without precedingsubscribe())observer.refetch(), guaranteed fresh data2. Error propagation & state exposure
Two layers of state propagation were added to the
subscribecallback:onError()intosyncState.error, and are auto-cleared on the next success.get()promise viarejectInitialPromise.onQueryStateChangea new opt-in callback for full TQ observer state: