React Query Appreciation 🙂

[bgazzera]

Just wanted to leave a note here saying thanks and great work!
Very well-thought-out API, pleasure to use.

We are using the library in a closed source (sorry) project, so I'll sponsor while my client keeps paying!

Cheers!

[tannerlinsley]

Thanks so much! I'm glad to hear it's helping out :)

[aurbano]

@bgazzera @tannerlinsley don't mean to hijack your issue but I'm now deciding which async library to use for a large production app with a very complex data model (closed source, but I'm pretty sure I'll be able to get the company to sponsor :) ) and I'd love to hear your opinion

react-query looks better than any other library I've seen! - my only concern is that the data is fully managed by it, which may make certain things a little bit tricky (but should be ok as long as each mutation invalidates/updates all the relevant queries right?).

@tannerlinsley if required, would it be feasable to store the data in a central store easily?
If we load for example the current user from and endpoint (username, email... ) and this data is used in several places of the application (assuming that passing it in a prop is not feasable), would you recommend loading it from each component that needs it using useQuery, or should I store it in a centralised store? I guess that's just my main concern really, thanks again!

[tannerlinsley]

So react query is essentially a living  store/cache. You shouldn’t need to store anything from it on your own unless it’s in local-ish state for editing and using in a mutation. If you have multiple places using the same query, then just make your own custom hook that wraps useQuery and consume that all over your app. It will dedupe and share a single instance under the hood for multiple instances of the same query. I hope that answers your question. If not let me know. I wrote this from my phone 🤦‍♂️ Tanner Linsley

…

On Nov 27, 2019, 9:26 AM -0700, Alejandro U. Alvarez ***@***.***>, wrote: @bgazzera @tannerlinsley don't mean to hijack your issue but I'm now deciding which async library to use for a large production app with a very complex data model (closed source, but I'm pretty sure I'll be able to get the company to sponsor :) ) react-query is looking better than any other library I've seen! - my only concern is that the data will be fully managed by it, which may make certain things a little bit tricky but should be ok as long as each mutation invalidates/updates all the relevant queries. @tannerlinsley if required, would it be feasable to store the data in a central store easily? And final question! If we load for example the current user from and endpoint (receiving username, email... ) and this data is used in several places of the application (assuming that passing it in a prop is not feasable), would you recommend loading it from each component that needs it using useQuery, or should I store it in a centralised store? I guess that's just my main concern really, thanks again! — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or unsubscribe.

[bgazzera]

Hey @aurbano our use case in this particular project is a fairly complex data model, where the app is mostly reading from APIs with few local mutations and PUT/POST back to the server.

We have been using it as @tannerlinsley mentioned above.
We have wrapped the useQuery almost every time, to allow for additional features, such as caching the results into localStorage for some calls, or for doing transformations to the data before we deliver it to the actual component, and to abstract/hide useQuery and simplify the way the consumers interact with the data (hiding react-query configuration or not returning the refetch() function if the component doesn't need it)

We haven't yet felt the need to tie the data layer to a state management library, like say, mobx. Our app is handling state using useState and very few useContexts and passing props around, as usual.

Hope this helps!