Skip to content

Conversation

@aminerol
Copy link

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

@vercel
Copy link

vercel bot commented Dec 15, 2020

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/tannerlinsley/react-query/k6swnw6ju
✅ Preview: https://react-query-git-react-query-blacklist-persist.tannerlinsley.vercel.app

const cacheState = dehydrate(queryClient, {
shouldDehydrateQuery: (query) => {
const isExist =
blacklistQueries.filter((bl) => deepEqual(bl, query.queryKey))
Copy link
Collaborator

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 :)

Copy link
Member

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[];
Copy link
Member

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.

Copy link
Collaborator

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

@tannerlinsley
Copy link
Member

This PR is approaching stale status. Would you like us to keep this open @aminerol?

@charlesrollin
Copy link

Hi all, I don't know what the status of this PR is, but wouldn't it make more sense to enrich the options of persistWithLocalStorage by adding the 2 following keys :

{
  hydrate: HydrateOptions,
  dehydrate: DehydrateOptions,
}

and using them when calling hydrate and dehydrate respectively.

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.

@ericbiewener
Copy link
Contributor

Throwing in a request to add an allowList option in this PR as well as the blockList.

@tannerlinsley
Copy link
Member

We're going to be changing the API of the persist plugin soon that will make these changes obsolete. Thanks for your input!

@jspizziri
Copy link

jspizziri commented Sep 22, 2021

FWIW, it looks like the option along the lines of that suggested by @charlesrollin was added in PR #2131

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants