-
Notifications
You must be signed in to change notification settings - Fork 638
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add createQueryStore #6325
Add createQueryStore #6325
Conversation
… store methods from persisted state
…ocs, add overloads, misc. fixes
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code looks good. I need to test closer for potential memory leaks with timeouts etc. but first glance looks fine.
const [persist, discard] = [true, false]; | ||
|
||
const SHOULD_PERSIST_INTERNAL_STATE_MAP: Record<string, boolean> = { | ||
/* Internal state to persist if the store is persisted */ | ||
enabled: persist, | ||
error: persist, | ||
lastFetchedAt: persist, | ||
queryCache: persist, | ||
queryKey: persist, | ||
status: persist, | ||
|
||
/* Internal state and methods to discard */ | ||
fetch: discard, | ||
getData: discard, | ||
getStatus: discard, | ||
isDataExpired: discard, | ||
isStale: discard, | ||
reset: discard, | ||
subscriptionCount: discard, | ||
} satisfies Record<InternalStateKeys, boolean>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1
if (IS_DEV && !suppressStaleTimeWarning && staleTime < MIN_STALE_TIME) { | ||
console.warn( | ||
`[createQueryStore${persistConfig?.storageKey ? `: ${persistConfig.storageKey}` : ''}] ❌ Stale times under ${ | ||
MIN_STALE_TIME / 1000 | ||
} seconds are not recommended.` | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if we should just override the value if it's beneath this value. I don't know if you see a reason for having it exist, but seems to me that it should be disallowed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to create a query that fetches freshest data with staleTime = 0
, but that doesn't need to be refetched on an interval by setting disableAutoRefetching
3ed8b48
to
7dba53b
Compare
…tion, better handle `keepPreviousData`
…y within `lazyPersist`, handle maps and sets internally if neither `deserializer` nor `serializer` are provided, add `persistThrottleMs` to config
7dba53b
to
958cd90
Compare
* Migrate dapps query to `createQueryStore`, clean up types * Replace old haptics with turbo-haptics * Bump up `cacheTime` and `staleTime` * Fix merge conflicts, enable `keepPreviousData`
Fixes APP-2154
What changed (plus any additional context for devs)
createQueryStore
, which is a version ofcreateRainbowStore
with built-in fetching functionality, designed to be a more performant, more composable alternative touseQuery
, for most use casesuseQuery
→ Zustand sync pattern, which is inefficient and redundantMap
andSet
persistence support tocreateRainbowStore
partializer
tocreateRainbowStore
that automatically omits top-level store methods, which previously were being persisted whenpartialize
was not specifiedHow It Works
zustand-signal
. The$
function transforms a slice of a Zustand store into a liveAttachValue
. Under the hood, it’s a proxy that subscribes to changes in that slice of the store's state. When the specified state updates, the proxy immediately detects this, forcing the query store to recompute its internalqueryKey
based on the new params and refetch if needed.$
APIQueryStoreConfig
interfaceQueryStore
state interfaceNotes
set
andget
within the custom state creator currently are not aware of the query store's internal stateMay want to add a helper setting for a manual mode, where no automatic refetching would occur (perhaps with the exception of the initial fetch), relying only on manually callingfetch
for data updatesCurrently you can achieve something close to this by specifyingstaleTime: Infinity
(first-time fetches will still occur)disableAutoRefetching
API Examples
The API In Its Simplest Form:
Dynamic
$
Params:Narrow state subscriptions linked directly to either internal or external store state.
No Params & Overriding Built-in Data Caching via
setData
:Screen recordings / screenshots
Two copies of the same query store implementation, each with their own state and a unique
address
param, both leveraging persistence and dynamic$
params (you wouldn't want two copies of the same store in practice, that's purely for testing purposes):ScreenRecording_12-23-2024.18-02-12_1.MP4
What to test