Skip to content
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

[react-hooks] invalidate / setQueryData Helpers Without Query? #336

Open
iway1 opened this issue Feb 13, 2023 · 6 comments
Open

[react-hooks] invalidate / setQueryData Helpers Without Query? #336

iway1 opened this issue Feb 13, 2023 · 6 comments
Labels
pinned issues that should not be closed by bot

Comments

@iway1
Copy link

iway1 commented Feb 13, 2023

Right now it seems like the invalidate helper is only returned from the useQuery hook, which I think can make it a little clunky in situations where you need to invalidate the query from a component that doesn't necessarily want to call the query. I think you'd have to do this (or manually do getQueryKey stuff):

const {invalidate} = hooks.useSomeQuery(params, {enabled: false});

Any desire to have an way to invalidate / set query data in a typesafe way without needing to subscribe to the query or manually get the query keys and pass them? Something like:

import {useUtils} from 'src/zodios-client';

function Component() {
  const utils = useUtils();
  function eventHandler() {
    utils.[alias].invalidate(/* optional params */);
    // OR
    utils.[alias].setQueryData(/* typesafe query data update */)
  }
}

This provides a really awesome DX

I'd be happy to dig into this if it sounds like something you'd want to have in the library @ecyrbe

@ecyrbe
Copy link
Owner

ecyrbe commented Feb 13, 2023

Hello, we have a typesafe way to get the queryKey : http://www.zodios.org/docs/client/react#zodios-key-helpers
It allows to invalidate all keys related to a path or alias (if you don't pass params) or the specific key (if you pass the parameters)

@ecyrbe ecyrbe closed this as completed Feb 13, 2023
@iway1
Copy link
Author

iway1 commented Feb 13, 2023

@ecyrbe Hi,

We can get the query key currently, BUT:

  1. Cache operations have no real typesafety with the current implementation since we're just using vanilla react query which basically just typecasts stuff.

With above approach we can have truly typesafe cache operations updateQueryData getQueryData, etc. This is a really big improvement over vanilla react query cache management because it's much less error prone and less work for the dev b/c we have inference.

  1. my suggestion IMO provides a better DX for invalidation because we just can call invalidate instead of having to mess with cache keys. This is how it's done in trpc and it's really freaking nice to just never ever have to touch a cache key.

I think the above trpc-like approach is just better. Selfishly I'm wanting to use your library on an upcoming project and would love to just have the type safe cache operations and not have to touch the query keys.

Thanks for your work on this, this library is really impressive 😊

@ecyrbe
Copy link
Owner

ecyrbe commented Feb 13, 2023

You convinced me. reopening.

@ecyrbe ecyrbe reopened this Feb 13, 2023
@stale
Copy link

stale bot commented Mar 15, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix This will not be worked on label Mar 15, 2023
@ecyrbe ecyrbe added the pinned issues that should not be closed by bot label Mar 15, 2023
@stale stale bot removed the wontfix This will not be worked on label Mar 15, 2023
@robotkutya
Copy link

this would be awesome!
any progress? any help needed?

@ecyrbe
Copy link
Owner

ecyrbe commented Mar 29, 2023

Hello @robotkutya,
i did not started working on this yet. Help is very welcomed.
If you want to help, use V11 branch and go on package react (V11 branch is a monorepository with all the packages and using pnpm/changesets to handle them)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pinned issues that should not be closed by bot
Projects
None yet
Development

No branches or pull requests

3 participants