Composing dependent queries with custom hooks

[klaidman]

Hi...

I'm just getting into react-query, and have a question about how best to compose dependent queries. I've looked at the examples, and am using the recommended approach of setting up custom hooks for each query.

All of my API calls depend on at least two other pieces of data - a base URL, and the user's JWT auth token. Those get fetched through individual queries, like so:

// query functions
const getConfig = async () => {
	// returns { baseUrl: 'http://localhost:3001'}
};

const getAuth = async () => {
	// returns {jwt: 'mock-JWT-token'}
};

// and the hooks:
const useConfig = () => {
  return useQuery('config', getConfig, {staleTime: Infinity});
}

const useAuth = () => {
  return useQuery('auth', getAuth);
};

So far, so good, this all works as expected. When composing these into a dependent query though, there's a weird behavior I've noticed. That query is set up like so:

// need the query params here:
const getApiData = async (_, baseUrl, jwt) => {
	const url = `${baseUrl}/rest/of/route`;
	const headers = { authorization: `Bearer ${jwt}` }
	// etc... fetches from api
}

// hook with dependencies:
const useApiData = () => {
	const { data: config = { baseUrl: null } } = useConfig();
	const { data: app = { jwt: null } } = useAuth();
	
	const { baseUrl } = env;
	const { jwt } = app;
	
	const enabled = !!(baseUrl && jwt);
  
	return useQuery(['api', baseUrl, jwt], getApiData,{ enabled });
};

When the api call runs the first time, neither the config nor auth queries have previously run, so this kicks those off.

Using the dev tools, it looks like this creates 3 separate api queries with different keys, as each of the dependencies resolves, which look like:

query ['api', null, null]
query ['api', 'http://localhost:3001', null]
query ['api', 'http://localhost:3001', 'mock-JWT-token']

The first 2 queries with null params are disabled and inactive, have 0 observers, and eventually get garbage collected after a few minutes. Only the last query with all params actuallly fires, so this seems to work OK...?

The unnecessary queries were bugging me though, so I tried to mitigate that by setting the cacheTime to zero until the query becomes enabled:

const useApiData = async () => {
	const { data: config = { baseUrl: null } } = useConfig();
	const { data: app = { jwt: null } } = useAuth();
	
	const { baseUrl } = config;
	const { jwt } = app;
	
	const enabled = !!(baseUrl && jwt);
	const cacheTime = enabled ? 5 * 60 * 1000 : 0;
  
	return useQuery(['api', baseUrl, jwt], getApiData,{ enabled, cacheTime });
};

This seems to work to kill off the inactive queries, as they get garbage collected immediately. Feels a little hacky though, and maybe unnecessary?

I'm wondering if this is the expected behavior, and if this is a legit way to handle this, or if there's a better way to set up these kinds of queries? Am I overthinking this?

I have a lot of API calls I'm porting over to react-query, so I want to make sure I set those up with a solid pattern from the outset.

Thanks for any feedback!

[TkDodo]

This is a very comprehensive post / question. I thought a bit about it, but I couldn't really come up with a better way than you already have.

I don't think the extra entries in the cache are a problem.

Only thing you could do is not add baseUrl and token to your key. This depends on what you want to do when those keys change. If the baseUrl is static per deployment and getting a new jwt token should not trigger a hard loading state (which I would assume), then you can do:

const useApiData = async () => {
	const { data: config = { baseUrl: null } } = useConfig();
	const { data: app = { jwt: null } } = useAuth();
	
	const { baseUrl } = config;
	const { jwt } = app;
	
	const enabled = !!(baseUrl && jwt);
  
	return useQuery(['api'], () => getApiData(baseUrl, jwt) ,{ enabled, cacheTime });
};

But if the tokens are issued once per user, and you get a new token when a new user logs in, you actually do want it as part of the key to get a new entry in the cache. Everything that the fetch function received should be almost always part of the key, so I like your solution...

[klaidman]

Thanks so much for the feedback! Since I'm just bashing my way through this stuff on my own, it's great to get input from someone with more experience with the library and best practices around it.

You're right about your assumptions - the base URL is environment specific, and loaded from a static json file that is generated during the deployment, and will never change throughout the lifetime of the app. The JWT though, could get silently refreshed in the background at any point during the session, so I would just want that to pick up on the API calls without needing to show the user a loading state.

If the hook is only going to create a couple of extra entries, and, presumably, only the first time they are called - as config & auth should be ready the next time a dependent query needs them - then that's fine. I think I'll probably end up prefetching those at the parent level, since a failure to load either would be fatal to the app. But I wanted to check that I'm not writing code in a way that's going to generate a bunch of useless objects every time a query runs, or setting up a bad pattern that's going to get repeated a lot in the codebase.

I do like the idea of using an intermediate function to explicitly pass args to the actual query function instead of just relying on using query key values for everything. Some of my API calls may need to pass in a bunch of extra params to build routes / querystrings / headers / etc, so that could be a useful technique.

So, thanks again! React-query is turning out to be a pretty awesome library, and seems to have a great community around it as well. Cheers!

[TkDodo]

The JWT though, could get silently refreshed in the background at any point during the session, so I would just want that to pick up on the API calls without needing to show the user a loading state.

If you want to work around the intermediate loading states, you can also take a look at the keepPreviousData function. It will make sure that the current data is moved to the "new" cache when the key changes (if you keep the jwt in the key)