-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
feat: list of queries and mutations to be prevented from being persisted #1424
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
Conversation
|
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/tannerlinsley/react-query/k6swnw6ju |
| const cacheState = dehydrate(queryClient, { | ||
| shouldDehydrateQuery: (query) => { | ||
| const isExist = | ||
| blacklistQueries.filter((bl) => deepEqual(bl, query.queryKey)) |
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’m pretty sure there are Util functions already to compare query keys without the need of an extra dependency :)
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.
Indeed. We should use those utils
| * any sort of encryption */ | ||
| blacklistQueries?: QueryKey[]; | ||
| /** A list of MutationKeys to be blacklisted and prevented from persisted */ | ||
| blacklistMutations?: MutationKey[]; |
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.
We should also be avoiding charged terminology like blacklist. A good alternative might be disallow Queries, filter Queries etc.
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 think blocklist / allowlist ist the new blacklist / whitelist
|
This PR is approaching stale status. Would you like us to keep this open @aminerol? |
|
Hi all, I don't know what the status of this PR is, but wouldn't it make more sense to enrich the {
hydrate: HydrateOptions,
dehydrate: DehydrateOptions,
}and using them when calling This would allow full customization for the user, and could meet the needs of @aminerol if the utility functions @TkDodo talks about in a thread are exposed by the package. |
|
Throwing in a request to add an |
|
We're going to be changing the API of the persist plugin soon that will make these changes obsolete. Thanks for your input! |
|
FWIW, it looks like the option along the lines of that suggested by @charlesrollin was added in PR #2131 |
should be able to pass an array of QueryKeys and MutationKeys to be prevented from persisting, a use case that this should be handy its when we querying an access token, this token shouldn't be stored locally since it's not encrypted