A hook to do querying as needed without useQuery / useQueries

[fjolliton]

Hi everyone,

I was looking for a way to simplify the logic of my code that need to perform a dynamic number of queries, without the burden of useQueries (for typing reason, and for code clarity).

What I mean, is that I was looking for a way to write the code like this:

type MyComponentProps = {
    extraQuery: boolean,
    names: Array<string>,
};

const MyComponent = ({ extraQuery, names }: MyComponentProps) => {
    //
    // Obtain a function to perform any number of queries
    // NOTE: `withQuery` would use the same interface as `useQuery`
    //
    const withQuery = useWithQuery();

    //
    // Do an unconditional query (similar to `useQuery` in this case)
    //
    const result = withQuery({
        queryKey: ['key1'],
        queryFn: async () => { ... },
    });

    //
    // Do a conditional query (no need to use `enabled: false`) 
    //
    if (extraQuery) {
        const extra = withQuery({
            queryKey: ['foo', 'bar'],
            queryFn: async () => { ...},
        ));
        ...
        // Do another query conditionally in turn
        if (shouldDoSomething(extra.data)) {
            const other = withQuery({
                queryKey: ['foo', 'other'],
                queryFn: async () => { ... },
            ));
            ...
        }
    }

    //
    // One query per entry in `names` (no need to use `useQueries`)
    //
    const results = names.map(name => withQuery({
        queryKey: ['user', name],
        queryFn: async () => { ... },
    ));

    return <>...</>;
}

I tried to write something matching this design, and below I put the corresponding code.

Internally, the queries are identified by their keys (using a very rough approach for the POC). New queries are automatically added. Any query that no longer appear in a subsequent render is discarded.

That seems to work pretty well, within the limitations of this implementation.

Is something like this already possible with React Query?

Here is the code for the proof of concept. Note that it is not fully compliant with React (because of side effect outside of useEffect) and TypeScript (because of the anys I put here and there).

import { useCallback, useEffect, useRef, useState } from 'react';
import {
    QueryKey,
    QueryObserver,
    useQueryClient,
    UseQueryOptions,
    UseQueryResult,
} from 'react-query';

type Fn<
    TQueryFnData = unknown,
    TError = unknown,
    TData = TQueryFnData,
    TQueryKey extends QueryKey = QueryKey,
> = (
    options: UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>,
) => UseQueryResult<TData, TError>;

export const useWithQuery = (): Fn => {
    // Note: no context here
    const queryClient = useQueryClient();

    // A state solely to trigger a rerender
    const [_forceRefresh, setForceRefresh] = useState(0);

    // The known queries from the previous render
    const known = useRef<Map<string, { observer: QueryObserver }>>(new Map());

    // Track which queries are still in use in this component
    const seen = useRef(new Set<string>());
    seen.current.clear();

    const withQuery = useCallback(
        <
            TQueryFnData = unknown,
            TError = unknown,
            TData = TQueryFnData,
            TQueryKey extends QueryKey = QueryKey,
        >(
            options: UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>,
        ): UseQueryResult<TData, TError> => {
            // For testing purpose. Would need to compare key as done
            // internally in React-Query.
            const key = JSON.stringify(options.queryKey);
            seen.current.add(key);
            let entry = known.current.get(key);
            const defaultedOptions: any =
                queryClient.defaultQueryOptions(options);
            if (entry === undefined) {
                const observer = new QueryObserver(
                    queryClient,
                    defaultedOptions,
                );
                observer.subscribe(() => {
                    setForceRefresh(d => d + 1);
                });
                entry = { observer: observer as any };
                known.current.set(key, entry);
            }
            const { observer } = entry;
            const optimisticResult: any =
                observer.getOptimisticResult(defaultedOptions);
            observer.setOptions(defaultedOptions, { listeners: false });
            return optimisticResult;
        },
        [queryClient],
    );

    // Cleanup previous queries that no longer appear in this
    // component
    useEffect(() => {
        for (const key of [...known.current.keys()]) {
            if (!seen.current.has(key)) {
                known.current.get(key)?.observer.destroy();
                known.current.delete(key);
            }
        }
    });

    return withQuery;
};

[TkDodo]

I don't think it's possible within the rules of react. As you said, you do lots of side-effects, like creating subscriptions and updating options, just inside the withQuery functions. These are all things we do in useQuery, too, but we use hooks like useSyncExternalStore and useEffect - things you can't use inside withQuery because it's not a hook. And if we make it a hook, it becomes ... useQuery again ...

[fjolliton]

Thanks for the feedback.

To me, that seems to pretty much follow the React rules. Admittedly, everything should be moved to the useEffect to avoid performing queries that would not be necessary if the render was discarded by React in the end (so far, to my knowledge, React doesn't do that, but might do it in the future). It was done directly in the useCallback to get the initial values in the first invocation of a withQuery, but technically everything could be moved to a useEffect.

From the React point of view, basically, what we have is:

const MyComponent = () => {
  const register = useRegister();
  const fooResult = register('foo');
  if (...) {
    const barResult = register('bar');
    ...
  }
  return <>...</>;
};

And useRegister would rely ultimately on a useEffect to trigger all the required actions. That looks safe, and this allows to manage a varying number of register.

That's why I've the feeling that React Query could provide something like this.

(edit: spelling)