why is QueryClientProvider required?
our company is looking into using react-query, but since we use a micro-service with multiple mounted react apps on a single page, the implementation would become quite the undertaking...
this would require each app to have a
QueryClientProvider in it's root... and we have lots of apps...
is there any technical reason why react-query NEEDS a provider? I get that you're passing client around with context... but couldn't that be done with an instanced object?
we're now talking about patching QueryClientProvider.tsx locally to fix this... any help on this topic is much appreciated8 Replies
harsh-harlequin•3y ago
Not sure I fully understand the problem. If you want to start to use react-query inside on of your micro-frontends, you have to add
useQuery anyways, so why can't you add a Provider at the top?
The provider is necessary because it distributes the QueryClient, which contains the cache. In v5 (currently in alpha), you will be able to pass the QueryClient directly as last argument to all hooks. In those cases, it will use the passed arg directly rather than using the one from context:
but you still need to get the QueryClient from somewhere. Sure, you can create it, export it and import it again on all usage sites, but at that point, how is that better than just wrapping the tree in a Provider?like-goldOP•3y ago
^ but that's the problem, we don't have a standard react "tree" - we're using single spa to mount many many react apps
like-goldOP•3y ago
so yes, we would need to put the QueryClient in its own service, and import that into each react app
to your suggestion:
useQuery({ queryKey, queryFn }, queryClient)
yes, we were thinking about creating wrappers for each query method and exporting that so we wouldn't need to manually add the client on each call
but if we do this, the code still breaks cause a "QueryClientProvider" is still requiredharsh-harlequin•3y ago
So the question is: do you want to share the cache between services or not?
sunny-green•3y ago
yeah we want one shared cache between all services. The way it works in v5 by having the option to pass the queryClient to
useQuery seems like what we'd want. We just won't be able to upgrade to v5 until we can also get on to React 18.harsh-harlequin•3y ago
Imo, sharing a cache goes a bit against the isolation aspect if microfrontends does it not? Managing keys / making sure they don't overlap etc. seems to be the hardest part
sunny-green•3y ago
It would be ideal if we could have them in isolation but we have many common API requests that are made between services. For example, fetching a list of users to populate in a selection dropdown. What I like about v5 is that we could have both a global query client and a query client local to the service if we wanted. But yeah our services do have some coupling, our main benefit with a microfrontend is the ability to chunk up our app so that we can have separate squads work on services in isolation (for the most part) and we also get benefits like quicker deploys and mocking specific services.
xenial-black•3y ago
Query isolation could be done using app-related query key part. « [app1,users…] » … you would still be able to access those queries thanks to fuzzy matching of « *queries » API.