RTK Query: Multiple queries at once

[jonathanschad]

Today I played around a bit with RTK Query and I was wondering if there is a way to create multiple queries at once.

The usecase for our application is the following: We have a list of larger documents(could be easily < 10mb per document) that we dynamically load from an API. These documents are needed in many different places in the application. However, the length of the list is dynamic, which means we don't know how many API requests need to be sent at the time of writing the code. Also combining the individual requests into one large request is unfortunately not possible due to the size of the data.

React-Query offers a seemingly suitable solution for this with the hook useQueries.
Another possibility we have thought about would be to write the loaded data separately into the reduxstore and then subscribe to it using useSelector. However, this does not seem to me to be an acceptable solution, as it also unnecessarily inflates the store.
Hence my question if RTK Query also offers a solution for this problem or what would be the best approach in this case?

[markerikson]

This may not be 100% identical, but there was an SO question earlier today about an infinite scroll pagination scenario where it sounds like they want to keep showing existing data, but also fetch new data:

https://stackoverflow.com/questions/67909356/is-there-any-way-to-fetch-all-the-responses-stored-in-api-slice-rtk-query

[mka142]

Yes. As it was mentioned in one of the SO answers I also think that it is good option to use queryFn for multiple requests. In that way you can fetch data from as many endpoints as you want, and then just provide { data } or { error }.

[phryneas]

Yeah, useQueries is not really the most apparent use case when designing an API - I think react query also only added that in v3 or so 😅

Right now, you would probably need to do the logic by hand, meaning something like

const runningQueries = useRef({})
useEffect(() => {
  for (const [query, arg] of queries) {
    if (!runningQueries.current[query]) {
      runningQueries.current[query] = {}
    }
    if (!runningQueries.current[query][arg]) {
      runningQueries.current[query][arg] = dispatch(api.endpoints[query].invoke(arg)
    }
  }
  for (const [query, args] of Object.entries(runningQueries.current)) {
    for (const [arg, promise] of Object.entries(args)) {
      if (!queries.some(([q,a]) => q == query && a == arg) {
        promise.unsubscribe()
      }
    }
  }
}, queries)

and then something similar with api.endpoint[query].selector.

[phryneas]

For the "infinite scrolling" approach that Mark mentioned, I answered that over in StackOverflow. I don't think that will need a generalized API, as it is quite easy to implement with just three useQuery calls and is easier to tailor to the individual API that way.

[jonathanschad]

Thanks a lot for your help. I really appreciate that. I'll try to incorporate your suggestions into our project tomorrow

[phryneas]

@jonathanschad if you come up with fully runnable code, it would be great if you could share that here with others - mine above is pretty much pseudocode from the back of my head, so there's definitely things to improve on it :)

[jonathanschad]

I have to admit defeat here. I tried converting your code in something usable but I just couldn't get it to work.

Unfortunately, I don't have time to deal with this problem any further. I think for my case it should be enough to manually fetch the data.

But thanks again for the help you guys provided :)

[lamo2k123]

also faced the problem of implementing endless data loading and did not find an opportunity to implement it without crutches. very sad

[markerikson]

@lamo2k123 hey, the library has only been out officially for just over a week :)

If you can show us examples of the specific use case you're trying to solve, we can look at providing answers or improving the API, but just saying "can't do it without crutches, very sad" isn't a response that will help us help you.

[lamo2k123]

Need an analogue useInfiniteQuery https://react-query.tanstack.com/guides/infinite-queries

I saw that now there is TODO on Infinite scrolling.

Upset by the absence of Infinite scrolling

Thanks for what you are doing and for developing the tools.

[markerikson]

@lamo2k123 Lenz showed one possible approach for an infinite query implementation in that Stack Overflow answer:

https://stackoverflow.com/questions/67909356/is-there-any-way-to-fetch-all-the-responses-stored-in-api-slice-rtk-query

Does something like that work for you?

[lamo2k123]

This option is not suitable in my case. I need an honest list of what has been uploaded

[markerikson]

@lamo2k123 can you give more specifics? what do you mean by an "honest list"?

The more details you can provide, the better we can understand what you're trying to do and what might be helpful.

Having said that, I'm going to go ahead and convert this into a discussion thread, which I think will work better.

[lamo2k123]

Here's a minimal example of the problem I'm trying to solve.

import React, { useState, useEffect } from 'react';
import axios from 'axios';

export interface IListItem {
    id: number,
    name: string
}

export const List = () => {
    const [list, setList] = useState<Array<IListItem>>([]);

    useEffect(() => {
        axios.get<any, Array<IListItem>>('/get-list', {
            params: {
                limit : 20,
                offset: 0
            }
        })
            .then((payload) => {
                setList(payload);
            })
            .catch(console.error);
    }, []);

    return (
        <div>
            <ul>
                {list.map((item) => (
                    <li key={item.id}>{item.name}</li>
                ))}
            </ul>
            <a
                href="#load-more"
                children="Load more"
                onClick={(e) => {
                    e.preventDefault();

                    axios.get<any, Array<IListItem>>('/get-list', {
                        params: {
                            limit : 20,
                            offset: list.length
                        }
                    })
                        .then((payload) => {
                            setList((state) => [...state, ...payload]);
                        })
                        .catch(console.error);
                }}
            />
        </div>
    );
};

export default List;

[lamo2k123]

If use rtk-query

export const List = () => {
    // data = Array<IListItem>
    const { data } = useGetListQuery({
        limit : 20,
        offset: 0
    });

    return (
        <div>
            <ul>
                {data.map((item) => (
                    <li key={item.id}>{item.name}</li>
                ))}
            </ul>
            <a
                href="#load-more"
                children="Load more"
                onClick={(e) => {
                    e.preventDefault();

                    // @TODO: How to be here ????? <---- My problem here
                }}
            />
        </div>
    );
};

[phryneas]

I think you can pretty much use this solution: #1163 (reply in thread)

Generally I think we're a bit wrong in a "multiple queries at once" discussion at this point, because "multiple queries" and "infinite scrolling" only has limited overlap tbh.

[phryneas]

We should probably remove that "TODO" and add an "X" or something there.

At the current point, I'm more inclined to collect several cases and add recipes for them in the docs. From all the experiences I've had with infinite fetching "solutions" of other libraries, they work very good for some cases and are an absolute pain in other cases.

I'd rather have some primitives in place and documented use cases than having something that only works in a few very select cases.

[davidtkramer]

I attempted creating a re-usable useInfiniteQuery hook here: #1163 (reply in thread). API is inspired by react-query, but only supports downward scrolling. Example:

  const {
    isLoading,
    isFetching
    isSuccess,
    isError,
    fetchNextPage,
    hasNextPage,
  } = useInfiniteQuery(myApi.endpoints.listContacts, {
    getNextPageParam: (lastPage) => lastPage.meta.nextPage ?? undefined,
  });

This might help serve as a starting point for those recipes, although there's lots of room for improvement I'm sure. Also, would appreciate any feedback! The types are pretty rough and there might be primitives I'm unaware of that would serve as a better foundation for something like this.

All in all, built-in support for infinite scrolling, similar to react-query, would definitely be appreciated as my team's use case is similar to @lamo2k123. With the custom hook, we lose out on automatic refetching when data goes stale. But again, there could be a better approach I'm unaware of that doesn't have that drawback. I definitely understand the concerns around not wanting to add a limited solution to the lib though.

[phryneas]

Let's say useQueries hook is on the backlog, but not with a very high priority right now, as Codegen, SSR and React 18/Suspense are pretty much up there - and I just don't have an infinite amount of time right :)

Once we have that I'd probably opt for pushing that out and wait for multiple "infinite query" implementations building up on that, getting different angles on the different problems - and from there we'd see if we better just have a few recipes for different cases or if we can find one common abstraction that works well for most cases.

[ghost]

I was wondering if there were any updates on the progress of the infinit scrolling? I do have a custom solution, but honestly wished RTK Query supported it out of the box.

[phryneas]

Not at the moment. A useQueries hook is still in the backlog, but the current release towards SSR has precedence - and that is quite a beast.

That said, I can't repeat it often enough: in offset-based or paginated cases the solution of just three useQuery hook calls I suggested above should work just fine without any need for that.

[HassanHeydariNasab]

Hi,
I just created a sample project to demonstrate how to implement a simple infinite scrolling using RTK Query:
https://github.com/HassanHeydariNasab/infinite-scrolling-rtk
https://codesandbox.io/s/heuristic-northcutt-tn61cg
You can also move the component logic into queryFn and use global state as you have access to args, getState, dispatch, etc.

[kelvindecosta]

Hello everyone!

I was looking into this issue and I managed a workaround but it is far from ideal.

Disclaimer: I am very new to Redux.

Premise

For my use case, I have a list of query arguments, say a list of Pokemon names.

const pokemon = ["pikachu", "zapdos", "squirtle"];

For each name, I would like to query an API, say one that gives the Pokemon's type along with other information.

A few caveats:

• I don't wish to render/show all the Pokemon with their type.
  At most, maybe just one that is selected by the user.
  This means that the <Pokemon /> component, that calls useQuery, is rendered for just one / none of the Pokemon.
• I want to compute whether there are two Pokemon of the same type.
  This would require access to all the Pokemon's types simultaneously.
• The API only accepts one string, i.e., one Pokemon name as an argument

You can imagine a scenario where there are many different Pokemon names (around 5-7).

Workaround

I call initiate whenever the pokemon array is changed, and immediately unsubscribe.

useEffect(() => {
  pokemon.forEach((p) => {
    const result = dispatch(
      pokeAPI.endpoints.getType.initiate({
        name: p,
      })
    );

    result.unsubscribe();
  });
}, [pokemon, dispatch]);

I then call useSelector like so:

const selectAllPokemonType = (state, names) =>
  names.map((n) => pokeAPI.endpoints.getType.select({ name: n })(state));

// inside a component
// ...
const allPokemonType = useSelector((state) =>
  selectAllPokemonType(state, pokemon)
);

// compute if any pokemon share a type
// ...

While this works, it updates allPokemonType whenever the store changes.

Conclusion

I would really appreciate some feedback/advice.
Is this a good approach? What should I do instead?

I would also appreciate an update on the official implementation of useQueries, for my own sanity.

Thank you very much for your time and for actively maintaining this awesome project.

[markerikson]

Response from Dominik:

the best case for useQueries is to map over a dynamic array of same-kinded data, yes. like, you have a multi-selection of pokemons, and each selection yields a query for those details.

but it also works for [getSomePokemon, getSomeUser, getSomeBlogPost] , as an alternative to run 3x useQuery . They will also run in parallel. It is however a big obstacle for typings - if you pass a tuple in, you'd want a tuple back with the "correct" result types inferred, so that you can destruct.

also:

I just discovered another issue with our useQueries types when upgrading to the react18 types, which have gotten more strict. It's not much fun. I think in rtk-query you have this better under control because you create the hooks, so I would go with a bound useQueries that fetches multiple same-kinded entities tbh. you can still do useAnyQueries or so later

[TkDodo]

let me subscribe here directly 👋

[ChuckJonas]

there was a bug in the unsubscribe logic:

/**
 * Allows running a query on a collection of data
 * @param query The RTK ApiEndpointQuery to run 
 * @param params a list of params that will be run by the query
 * @returns the rtk query result (same as useGetXQuery())
 */
export function useQueries<
  Q extends QueryDefinition<any, any, any, any>,
  D extends EndpointDefinitions
>(query: ApiEndpointQuery<Q, D>, params: Parameters<typeof query['initiate']>[0][]) {
  useEffect(() => {
    const results: QueryActionCreatorResult<any>[] = params.map((param) =>
      store.dispatch(query.initiate(param as any))
    );
    return () => {
      for (const result of results) {
        result.unsubscribe();
      }
    };
  }, [query, params]);
  return useSelector((state) => params.map((param) => query.select(param)(state as any)));
}

I believe this is now handling it correctly

[Gounlaf]

Hi,

I'm using the latest version provided above by @ChuckJonas.
I was struggling with an infinite re-render (stopped by a Maximum update depth exceeded error).

Using directly the effect and selector, eslint warned me about the params: they have to be memoized. At least it's what I understand 😅 (I'm noob in react :x).
Hope it might help someone else.

Regards.

[andrewdoro]

• To fix infinite loop errors, the params need to be memoized, this could be done either outside the hook or inside by adding JSON.strinfigy(params). (the variant with JSON is mostly a hack)
• This was creating a new object on every rerender (state) => params.map((param) => query.select(param)(state as any)), so I added an equality check for the selector with lodash isEqual. (I am not sure how I can I do this with reselect ?)

import { createSelector } from '@reduxjs/toolkit'
import { EndpointDefinitions, QueryDefinition } from '@reduxjs/toolkit/dist/query'
import { QueryActionCreatorResult } from '@reduxjs/toolkit/dist/query/core/buildInitiate'
import { ApiEndpointQuery } from '@reduxjs/toolkit/dist/query/core/module'
import { isEqual } from 'lodash'
import { useEffect } from 'react'
import { shallowEqual, useSelector } from 'react-redux'
import { useEffectDebugger } from '../utils/debugEffect/useEffectDebug'
import useDispatch from './useDispatch'

/**
 * Allows running a query on a collection of data
 * @param query The RTK ApiEndpointQuery to run
 * @param params a list of params that will be run by the query
 * @returns the rtk query result (same as useGetXQuery())
 */

export function useQueries<
  Q extends QueryDefinition<any, any, any, any>,
  D extends EndpointDefinitions
>(query: ApiEndpointQuery<Q, D>, params: Parameters<typeof query['initiate']>[0][]) {
  const dispatch = useDispatch()
  useEffect(() => {
    const results: QueryActionCreatorResult<any>[] = params.map((param) =>
      dispatch(query.initiate(param as any))
    )
    return () => {
      for (const result of results) {
        result.unsubscribe()
      }
    }
  }, [query, params, dispatch])
  //JSON.stringify(params)

  const data = useSelector(
    (state) => params.map((param) => query.select(param)(state as any)),
    (next, prev) => isEqual(next, prev)
  )
  return data
}

[kellengreen]

Here is a snippet I used for search pagination. Hope this helps someone. Should probably make a PR to bake this into RTK at some point.

Usage

  const queries = useMemo(() => {
    return pageTokens.map((pageToken) => ({
      ...baseQuery,
      lastKey: pageToken,
    }))
  }, [baseQuery, pageTokens])

  const responses = useQueries(myApi.endpoints.search, queries)

Hook

import { useEffect, useMemo, useReducer, useRef } from 'react'
import { useDispatch } from 'react-redux'

function loadingReducer(_state, originalArgs) {
  return {
    isUninitialized: false,
    isLoading: true,
    isFetching: true,
    isSuccess: false,
    isError: false,
    originalArgs: originalArgs,
    data: undefined,
    currentData: undefined,
    error: undefined,
  }
}

function fetchingReducer(state, originalArgs) {
  return {
    isUninitialized: false,
    isLoading: state.data === undefined,
    isFetching: true,
    isSuccess: state.data !== undefined,
    isError: false,
    originalArgs: originalArgs,
    data: state.data,
    currentData: undefined,
    error: undefined,
  }
}

function successReducer(state, data) {
  return {
    isUninitialized: false,
    isLoading: false,
    isFetching: false,
    isSuccess: true,
    isError: false,
    originalArgs: state.originalArgs,
    data,
    currentData: data,
    error: undefined,
  }
}

function errorReducer(state, error) {
  return {
    isUninitialized: false,
    isLoading: false,
    isFetching: false,
    isSuccess: false,
    isError: true,
    originalArgs: state.originalArgs,
    data: state.data,
    currentData: undefined,
    error,
  }
}

function useQueryResult(originalArgs) {
  const [state, setState] = useReducer(
    (state, [reducer, value]) => reducer(state, value),
    undefined,
    () => loadingReducer(undefined, originalArgs),
  )

  const setStateWrapper = useMemo(
    () => ({
      loading(originalArgs) {
        setState([loadingReducer, originalArgs])
      },
      fetching(originalArgs) {
        setState([fetchingReducer, originalArgs])
      },
      success(data) {
        setState([successReducer, data])
      },
      error(error) {
        setState([errorReducer, error])
      },
    }),
    [],
  )

  return [state, setStateWrapper]
}

export default function useQueries(endpoint, originalArgs = [undefined]) {
  const endpointRef = useRef()
  const dispatch = useDispatch()
  const [queryResult, setQueryResult] = useQueryResult(originalArgs)

  useEffect(() => {
    let active = true
    const actions = originalArgs.map((originalArg) =>
      endpoint.initiate(originalArg),
    )
    const results = actions.map((action) => dispatch(action))
    const unwrappedResults = results.map((result) => result.unwrap())

    if (endpointRef.current !== endpoint) {
      endpointRef.current = endpoint
      setQueryResult.loading(originalArgs)
    } else {
      setQueryResult.fetching(originalArgs)
    }

    Promise.all(unwrappedResults)
      .then((responses) => {
        if (active) {
          setQueryResult.success(responses)
        }
      })
      .catch((errResponse) => {
        if (active) {
          setQueryResult.error(errResponse)
        }
      })

    return () => {
      active = false
      results.forEach((result) => {
        result.unsubscribe()
      })
    }
  }, [endpoint, originalArgs, dispatch, setQueryResult])

  return queryResult
}

[philingyuup]

@kellengreen Thank you for sharing this. Your solution seems to work really well.

Just wanted to comment and suggest a possible improvement. I'm a little confused by the usage of crypto.randomUUID(). Just guessing here, but it seems the intention was to make sure we're not updating state if the component has already unmounted. If such is the case, I think we can achieve the same by just leveraging scope.

useEffect(() => {
    let active = true
    setState(["pending", args]);

    const actions = args.map((arg) => endpoint.initiate(arg));
    const results = actions.map((action) => dispatch(action));
    const unwrappedResults = results.map((result) => result.unwrap());

    Promise.all(unwrappedResults)
      .then((responses) => {
        if (active) {
          setState(["fulfilled", responses]);
        }
      })
      .catch((errResponse) => {
        if (active) {
          setState(["rejected", errResponse]);
        }
      });

    return () => {
      active = false
      results.forEach((result) => {
        result.unsubscribe();
      });
    };
  }, [endpoint, args, dispatch]);

[kellengreen]

seems the intention was to make sure we're not updating state if the component has already unmounted

That's correct, we don't want "old" hook calls updating the state.

And yes your suggestion makes much more since, I should have caught that. I've updated the example.

[kellengreen]

I should probably note that this implementation also fixes what I'm assuming is a bug in the useQuery response logic.

TL;DR - normally isSuccess briefly ticks false on subsequent queries. This implementation does not do this.

[kellengreen]

Added revision to handle changes to endpoint.

[NunoCardoso]

This snippet works great, I am "converting" it to Typescript, and trying also to add the query options like selectFromResult and skip.

               import {QueryStateSelector, UseQueryStateOptions} from '@reduxjs/toolkit/src/query/react/buildHooks'
      import { useEffect, useMemo, useReducer, useRef } from 'react'
      import { useDispatch } from 'react-redux'
      
      type State<Data, Argument> = {
        isUninitialized: boolean
        isLoading: boolean
        isFetching: boolean
        isSuccess: boolean
        isError: boolean
        originalArgs: Argument[]
        data: Data[] | undefined
        currentData: Data[] | undefined
        error: Data[] | undefined
      }
      
      const loadingReducer = <Data, Argument>(
        _state: State<Data, Argument> | undefined,
        originalArgs: Argument[]
      ) => {
        return {
          isUninitialized: false,
          isLoading: true,
          isFetching: true,
          isSuccess: false,
          isError: false,
          originalArgs: originalArgs,
          data: undefined,
          currentData: undefined,
          error: undefined
        }
      }
      
      const fetchingReducer = <Data, Argument>(state: State<Data, Argument>, originalArgs: Argument[]) => {
        return {
          isUninitialized: false,
          isLoading: state.data === undefined,
          isFetching: true,
          isSuccess: state.data !== undefined,
          isError: false,
          originalArgs: originalArgs,
          data: state.data,
          currentData: undefined,
          error: undefined
        }
      }
      
      const successReducer = <Data, Argument>(state: State<Data, Argument>, data: Data[], selectFromResult?: QueryStateSelector<any, any>) => {
        let result = {
          isUninitialized: false,
          isLoading: false,
          isFetching: false,
          isSuccess: true,
          isError: false,
          originalArgs: state.originalArgs,
          data,
          currentData: data,
          error: undefined
        }
        return selectFromResult ? selectFromResult(result) : result
      }
      
      const errorReducer = <Data, Argument>(state: State<Data, Argument>, error: Data[]) => {
        return {
          isUninitialized: false,
          isLoading: false,
          isFetching: false,
          isSuccess: false,
          isError: true,
          originalArgs: state.originalArgs,
          data: state.data,
          currentData: undefined,
          error
        }
      }
      
      type UseQueryResultReturn<Data, Argument> = [
        State<Data, Argument>,
        {
          success(data: Data[], selectFromResult ?: QueryStateSelector<any, any>): void
          fetching(originalArgs: Argument[]): void
          loading(originalArgs: Argument[]): void
          error(error: Data[]): void
        }
      ]
      
      const useQueryResult = <Data, Argument>(originalArgs: Argument[]): UseQueryResultReturn<Data, Argument> => {
        const [state, setState] = useReducer(
          (state: State<Data, Argument>, [reducer, value, fn]: any) => reducer(state, value, fn),
          undefined,
          () => loadingReducer(undefined, originalArgs)
        )
      
        const setStateWrapper = useMemo(
          () => ({
            loading(originalArgs: Argument[]) {
              setState([loadingReducer, originalArgs])
            },
            fetching(originalArgs: Argument[]) {
              setState([fetchingReducer, originalArgs])
            },
            success(data: Data[], selectFromResult ?: QueryStateSelector<any, any>) {
              setState([successReducer, data, selectFromResult])
            },
            error(error: Data[]) {
              setState([errorReducer, error])
            }
          }),
          []
        )
      
        return [state, setStateWrapper]
      }
      
      const useMultipleQueries = <Endpoint extends any, Data, Argument>(
        endpoint: Endpoint,
        originalArgs: Argument[] = [],
        options: UseQueryStateOptions<any, any> = {}
      ) => {
        const endpointRef = useRef<Endpoint>()
        const dispatch = useDispatch()
        const [queryResult, setQueryResult] = useQueryResult<Data, Argument>(originalArgs)
      
        useEffect(() => {
          if (options.skip) return
          let active = true
          const actions = originalArgs.map((originalArg) => endpoint.initiate(originalArg))
          const results = actions.map((action) => dispatch(action))
          const unwrappedResults = results.map((result) => result.unwrap())
      
          if (endpointRef.current !== endpoint) {
            endpointRef.current = endpoint
            setQueryResult.loading(originalArgs)
          } else {
            setQueryResult.fetching(originalArgs)
          }
      
          Promise.all(unwrappedResults)
            .then((responses) => {
              if (active) {
               setQueryResult.success(responses, options.selectFromResult)
              }
            })
            .catch((errResponse) => {
              if (active) {
                setQueryResult.error(errResponse)
              }
            })
      
          return () => {
            active = false
            results.forEach((result) => {
              result.unsubscribe()
            })
          }
        }, [endpoint, originalArgs, dispatch, setQueryResult])
      
        return queryResult
      }
      
      export default useMultipleQueries

[wchargin]

Hey! I'm running into a similar issue but not in the context of infinite scrolling, which is what most of this discussion seems to be about. My use case is a simple N+1 query*—actually, two of them:

1. we make a ListWidgetsRequest to find the IDs of all the available widgets;
2. we make a GetWidgetRequest for each widget by ID; and
3. each widget has a list of associated gadget IDs, so we make a GetGadgetRequest for each gadget on each widget.

This populates an Array<Widget> structure, where each Widget has an Array<Gadget>. (It'd also be fine if these were globally normalized and keyed by ID.) We need the information for all of these objects at the level of a single component making global decisions, so splitting it up into layers of components where each component just has one query is unfortunately not a great fit. Ideally, we'd like to cache each Widget and each Gadget.

Our application uses React with Redux Toolkit, but we don't use RTK Query for these endpoints. But we miss the ergonomics, the consistent caching behavior, and the nice encapsulation of the request machinery. Is this a pattern that RTK Query can comfortably support and a use case that you would recommend?

* I understand that this interface might raise some eyebrows from a performance design standpoint for traditional HTTP APIs, but in this case we're talking over a low-latency WebRTC data channel where the client can easily be updated but the server can't. We're comfortable sacrificing some wire inefficiency so that the server API can be simple and decoupled from its clients.

[markerikson]

@wchargin : I'm playing with an idea over in #4561 for prepopulating caches, such as taking a list query result and prepopulating the individual item cache entries. It's definitely missing a bunch of edge cases right now, but I think that might be roughly what you're asking for? (Although re-reading your comment, I'm not sure it is.)

[wchargin]

@markerikson: It sounds like a step in the right direction. I'd need the ability not just to prime the caches but to also access all the query state from my component. Here's an example sketch:

const GadgetsSummary: React.FC = () => {
  const listWidgetsQuery = api.endpoints.listWidgets.useQuery();
  const getWidgetQueries = api.endpoints.getWidget.useMultiQuery({
    args: listWidgetsQuery.data /*: Array<WidgetId> */ ?? [],
  });
  const getGadgetQueries = api.endpoints.getGadget.useMultiQuery({
    args: (getWidgetQueries.data ?? []).flatMap((widget) => widget.gadgetIds),
  });

  if (!getGadgetQueries.isSuccess) return <span>Loading…</span>;
  const gadgets = getGadgetQueries.data;

  const n = gadgets.length;
  const averageDiameter = average(gadgets.map((gadget) => gadget.diameter));
  return (
    <span>
      You have {n} gadgets, with average diameter {averageDiameter}.
    </span>
  );
};

Aspects that I'm trying to highlight here:

• The GadgetsSummary component needs access to all of the data at once. It can't delegate to a family of child components each of which needs only a single query, because it needs to aggregate over the query results.
• After the first getWidget query returns, we can start firing getGadget queries, even before the other widgets' data is in.

As I've sketched it out, this would require a React render cycle each time a new response comes in, which doesn't seem ideal. Ideally, I'd like the data fetching to be pipelined, but since the component blocks until everything is loaded, it would be nice if it didn't have to render so many times.

In a different codebase where we do use RTK Query, we're (ab)using lazy queries to do something similar:

const WidgetReport: React.FC = () => {
  const listWidgetsQuery = api.endpoints.listWidgets.useQuery();

  // user input state controlled by a multi-select component
  const [selectedIds, setSelectedIds] = useState<WidgetId[]>([]);

  // hacky state management to fire off multiple requests
  const [getWidget] = api.endpoints.getWidget.useLazyQuery();
  const [widgetData, setWidgetData] = useState<Record<WidgetId, Widget>>({});
  const [widgetsLoading, setWidgetsLoading] = useState<boolean>(false);
  const widgetsFetchRef = useRef(0);

  // When the user changes their selection, fire off many RTK lazy queries at
  // once and wait for the results. We don't ever use the `UseQueryStateResult`
  // returned by `useLazyQuery()`.
  const onSelectIds = (selectedIds: WidgetId[]) => {
    setSelectedIds(selectedIds);
    (async () => {
      const widgetData: Record<WidgetId, Widget> = {};
      const fetchId = ++widgetsFetchRef.current;
      setWidgetsLoading(true);
      const promises = selectedIds.map(async (widgetId) => {
        const { data: widget } = await getWidget(widgetId);
        widgetData[widget.id] = widget;
      });
      await Promise.all(promises);
      if (widgetsFetchRef.current !== fetchId) {
        // User changed selection while these requests were ongoing; abort so
        // that we don't squash the state.
        return;
      }
      setWidgetData(widgetData);
      setWidgetsLoading(false); // also in the promise rejection case; elided for brevity
    })();
  };

  if (!listWidgetsQuery.isSuccess) return <span>Loading…</span>;
  const allWidgetIds = listWidgetsQuery.data;

  return (
    <div className="flex flex-col">
      <Select
        multiple
        choices={allWidgetIds}
        value={selectedIds}
        onChange={onSelectIds}
      />
      {widgetsLoading ? (
        <LoadingIndicator />
      ) : (
        <WidgetsTable widgets={widgetData} />
      )}
    </div>
  );
};

This does seem to work okay for us, but clearly it's not what lazy queries were meant for. Ideally, I'd like to replace the whole middle section there with this:

  const widgetDataQuery = api.endpoints.getWidget.useMultiQuery({
    args: selectedIds,
    selectFromResult: (widgets: Widget[]): Record<WidgetId, Widget> => {
      return Object.fromEntries.map((widget) => [widget.id, widget]);
    },
  });
  const { data: widgetData, isLoading: widgetsLoading } = widgetDataQuery;
  const onSelectIds = setSelectedIds;

I guess as written it's still the case that setting selected IDs would need another render cycle before the queries started being fired. But that's a small deal to me compared to all the state management that gets saved.

Thanks for working on this! I hope this gives a bit more context for our use case and what I'm looking for. Let me know if I can clarify anything.

[watson28]

I'm also in need of this. Basically, I want to be able to execute N+1 queries, as @wchargin put it. I didn't know I could workaround this using lazy queries since I thought a newly executed query would cancel the previously triggered one when trying to trigger them in parallel. But I will give it a try. Previously, I was achieving the same using the rtk dispatch actions to initiate multiple queries dynamically (as it's suggested in the previous comments) and then create selectors to read the state.

[Viktor19931]

still not working multiple query at once
Any workaround ?

[kellengreen]

I'm still using my snippet from above, gets the job done.

[wchargin]

Coming back to this since I now want it again for infinite scroll reasons. I looked at the solution in the Stack Overflow post by @phryneas, but I don't see how to adapt it to a pagination API that is uses cursors rather than page numbers (since page-number-based APIs tend to run into performance issues). My API looks like this:

interface ListRequest {
  after?: string; // opaque cursor
}
interface ListResponse {
  items: T[];
  hasNextPage: boolean;
  endCursor?: string;
}
// analogous to the Relay cursor connections spec, though I don't use Relay:
// https://relay.dev/graphql/connections.htm

// usage:
list()
    ==> { items: [t1, t2], hasNextPage: true, endCursor: "xER0A41FnkDkcUr-" }
list({ after: "xER0A41FnkDkcUr-" })
    ==> { items: [t3, t4], hasNextPage: true, endCursor: "ovGmijz3urFCRbo0" }
list({ after: "ovGmijz3urFCRbo0" })
    ==> { items: [t5], hasNextPage: false })
result = [t1, t2, t3, t4, t5]

The issue is that we can't map from a scroll position to a cursor, nor is there an analogue of "currentPage - 1" to map a cursor to its predecessor or successor.

I've also seen this attempt on Stack Overflow, which uses the merge argument to build.query to merge separate pagination results together. But just blindly returning currentCache.push(...newItems) seems scary and error-prone to me. Most obviously, it means that if someone starts on page 1 and then jumps to page 3, the cached data will just be missing the data from page 2. So I'm still looking for a solution here, for both the "infinite scroll" use case and the "N+1 queries" use case that I mentioned previously.

[markerikson]

@wchargin we are specifically implementing purpose-built infinite query support, modeled after React Query's API, and have a draft PR that you can try out now:

• [DRAFT] RTKQ Infinite Query integration #4738

[agusterodin]

At work we need to perform an arbitrary amount of requests to fetch data from an endpoint and combine all results to show in a single table (combined table results are sorted on client). Note that our particular use-case is not "infinite querying". If our use-case was infinite query, we would reach for the upcoming "infinite query" feature.

If anybody else is wrestling the "get combined results of multiple queries to same endpoint in a single place" issue and reading through these threads, here was our experience. Hope it helps.

---

First attempt

We wanted to keep things as by-the-book as possible. A "multiple queries" hook would have been the most elegant solution and is most in line with how RTKQ is typically used. React Query has a really nice "multiple queries" hook, so I was hoping for a similar solution in RTKQ. After digging through this discussion, the closest thing to a working solution with proper type-safety was @NunoCardoso 's implementation. Unfortunately, the types aren't adequate. For example, the data attribute isn't getting inferred correctly.

---

Second attempt

Since a type-safe hook approach wasn't viable (without extensive additional effort), the next thing we tried was to fetch data declaratively and write a selector that gathers all the data from RTKQ's reducer.

This component setup declaratively fetches data so that it is stored in RTKQ cache. Notice we aren't actually doing anything directly with the hook result, this component exists solely to fetch data and keep in RTKQ cache when it is present in the React tree.

export default function IpAddressDataFetcher() {
  const ipAddressesToQuery = getIpAddressesToQuery(state)
  return ipAddressesToQuery.map(ipAddress => <IpAddressDataFetch key={ipAddress} ipAddress={ipAddress} />)
}

function IpAddressDataFetch({ ipAddress }: { ipAddress: string }) {
  useGetIpAddressesInformationQuery(ipAddress)
  return null
}

This is what selector would look like to grab the responses out of the RTKQ cache.

export const getIpAddressResponses = createSelector([(state: State) => state], state => {
  const ipAddressesToQuery = getIpAddressesToQuery(state)
  const ipAddressResponses: Record<string, IpInformation> = {}
  ipAddressesToQuery.forEach(ipAddress => {
    const { data } = ipLookupApiSlice.endpoints.getIpAddressInformation.select(ipAddress)(state)
    if (data) ipAddressResponses[ipAddress] = data
  })
  return ipAddressResponses
})

Unfortunately, the selector above is problematic. It obviously doesn't reap any of the benefits that Reselect is supposed to provide because it's subscribed to the entire application's root state. This selector will recompute any time the state changes anywhere in the entire application.

As far as I can tell, there is no type-safe way to improve the selector above to scope closer into the piece of state we are interested in (RTKQ's cache entries). The problem is that RTKQ's endpoint select function needs root state as an input.

---

Third attempt

After giving up on the last approach, we decided to call it a day and store the responses in a manually-maintained RTK slice.

Here is how we grab the data and put it into our slice.

export default function IpAddressDataFetcher() {
  const ipAddressesToQuery = getIpAddressesToQuery(state)
  return ipAddressesToQuery.map(ipAddress => <IpAddressDataFetch key={ipAddress} ipAddress={ipAddress} />)
}

function IpAddressDataFetch({ ipAddress }: {ipAddress: string}) {
  const dispatch = useDispatch()
  const { data } = useGetIpAddressesInformationQuery(ipAddress)

  useEffect(() => {
    if (data) dispatch(appendIpAddressResponses({ ipAddress, results: data }))
  }, [data])

  return null
}

Here is some code from the slice itself:

interface SliceState {
  ipAddressesToQuery: Set<string>
  ipResponses: Record<string, IpInformation>
}

const initialState: SliceState = {
  ipAddressesToQuery: new Set()
  ipResponses: {}
}

And this is the reducer to put responses into our slice as they come in:

appendIpAddressResponses(state, action: PayloadAction<{ ipAddress: string; results: IpInformation }>) {
  const { ipAddress, results } = action.payload
  if (!state.results[ipAddress]) {
    state.results[ipAddress] = results
  }
}

This obviously isn't ideal because we lose out on many benefits of RTKQ and now have a mirrored source of truth for fetched data.

---

I don't feel great about the final result and hope we get first-class useQueries support at some point in the future 🙏

[agusterodin]

Didn't realize you could use the thunks like that. Thought it would cause some sort of circular dependency issue. Surely enough, it worked :)

Type-safety is way better and I don't have to redefine the Zod schema under extraOptions. I had to set forceRefetch to false btw, otherwise it defaults to true and will refetch everything any time the query hook input parameter changes.

getMultipleIpAddressResults: builder.query<Record<string, IpInformation>, string[]>({
  async queryFn(ipAddresses, queryApi) {
    const responses = await Promise.all(
      ipAddresses.map(async ipAddress => {
         const result = await queryApi.
           .dispatch(ipLookupApiSlice.endpoints.getIpAddressResult.initiate(ipAddress, { forceRefetch: false }))
           .unwrap()
         return { ipAddress, data: result }
      })
    )

    const results: Record<string, IpInformation> = {}
    responses.forEach(({ ipAddress, data }) => {
      results[ipAddress] = data
    })

    return { data: results }
  },
})

[markerikson]

Y'know, this is actually a pretty useful recipe. Probably worth adding to the docs.

[wchargin]

I see that this recipe calls initiate, whose docs say that you need to call unsubscribe. Is there a downside to not doing so in this case, or is it fine because subscribe: true is not passed? Should this recipe collect all the unsubscribe callbacks and just call them immediately before returning from the queryFn?

[markerikson]

That thought did cross my mind the other day, and I'm not sure off the top of my head :)

Conceptually I think you'd want the subscription, in order to keep the individual cache entries around. (After all, if your item set goes from [1, 2] to [1, 2, 3], you wouldn't want 1 and 2 to have gone out of the cache and need to be refetched.)

But I also suspect this ends up with multiple subscriptions to the same entry, and those never get removed.

[agusterodin]

I hadn’t really considered that.

The most complete and declarative solution would probably be to use subscribe: false in the queryfn. You could then write a custom hook that wraps your getMultipleIpAddressResults RTKQ hook but also contains the additional declarative logic for the initiate/unsubscribe stuff (doesn’t actually do anything with the data here) on all uses of getIpAddressResult.

One downside to wrapping your RTKQ hook with a custom hook is that preserving ability to pass RTKQ hook options through your custom hook is not TypeScript friendly in my experience.