Best practices for: useQuery + possibly undefined parameters + strict typescript.

[valerioleo]

Thanks to all the creators and maintainers of this amazing library. I'm using it since a few months and there is no looking back.

However, as my use cased become more advanced, I have some questions about best practices. In particular, how to best handle useQuery when for queries that require parameters that could be undefined. Here is an example.

import React, { useState } from "react";
import { useQuery } from "@tanstack/react-query";

const fetchItem = async (itemId: string) => {
  if (!itemId) {
    throw Error("Must pass item id!");
  }

  return Promise.resolve(`Visualising data from item: ${itemId}!`);
};

export function App() {
  const [selectedItem, setSelectedItem] = useState<string>();

  const { data, error } = useQuery({
    queryFn: () => fetchItem(selectedItem),
    enabled: !!selectedItem,
    retry: 0
  });

  return (
    <div>
      <button onClick={() => setSelectedItem("1")}> Fetch 1 </button>
      <button onClick={() => setSelectedItem("2")}> Fetch 2 </button>
      <button onClick={() => setSelectedItem("3")}> Fetch 3 </button>

      <br />
      <br />
      <br />

      {data ? (
        <div>
          {data}

          <button> Deselect all </button>
        </div>
      ) : (
        "Select an item first"
      )}

      <br />
      {error?.message}
    </div>
  );
}

export default App;

In this snippet, the queryFn expects a string, but when we load the component it is still undefined. I know that I can prevent the fetching by using the enabled option (as I do there) but typescript still complains about selectedItem being possibly undefined.

I have noticed that this happens only when I have the strict: true enable in my tsconfig.json, but that is an option I am not willing to disable because of all the positive guarantees it adds.

Some solutions I have found are:

• override the undefined with queryFn: () => fetchItem(selectedItem!),, but this is very ugly and undermines the advantages of typescript in the first place
• I could use useMutation, but it doesn't feel right and lacks many retry, caching mechanisms of useQuery
• I could move the useQuery into a new component that takes a {selectedItem: string} prop and that is rendered only when the parent selects one item. This seems the most react-query-ish of them, but of course the most cumbersome

Is there any other solution I have missed?

FYI: here is the codesandbox link for the above example: https://codesandbox.io/s/tanstack-react-query--query-parameters-s9nhqn?file=/src/containers/App/App.tsx

[TkDodo]

I'd change fetchItem to allow passing undefined. You're handling that case with the falsy check already:

- const fetchItem = async (itemId: string) => {
+ const fetchItem = async (itemId: string | undefined) => {
  if (!itemId) {
    throw Error("Must pass item id!");
  }

  return Promise.resolve(`Visualising data from item: ${itemId}!`);
};

see also: https://tkdodo.eu/blog/react-query-and-type-script#type-safety-with-the-enabled-option

[valerioleo]

thanks for quick reply.
probably I didn't make the best case for it with fetchItem, where as you noted I handle the undefined case.
However, that's not the case for times when we don't handle the queryFn. For example, if I have a trpc client like apiClient.comments.loadComment({id}), the id cannot be undefined.

I could do something like

queryFn: (itemId: string | undefined) => {
  if (itemId) return apiClient.comments.loadComment({id})
}

but it's really not that elegant IMHO (e.g. because it would undermine the whole point of using enabled: !!itemId) and I wonder if there is any better solution

[TkDodo]

yeah, I'm afraid there is no better solution. You can:

• use the bang operator !. I think Alex from trpc says this is one of the cases where he uses it
• check it in the queryFn
• maybe, but I probably wouldn't do it, provide the queryFn conditionally:

  const { data, error } = useQuery({
-    queryFn: () => fetchItem(selectedItem),
+    queryFn: selectedItem ? () => fetchItem(selectedItem) : undefined,
    enabled: !!selectedItem,
    retry: 0
  });

This works on type level, and RQ is fine with it, because queryFn is technically optional (it could be defined globally). But you really have to make sure that that the queryFn doesn't run any other way, or you get a Missing queryFn error.

[valerioleo]

I guess this is the answer then. Has it been discussed the idea of having something in the middle between useQuery's declarative style and useMutation imperative style? Something for non-mutating queries that need to be triggered imperatively? As mentioned above, I could use useMutation but I would lose some of the advantages that useQuery offers. Maybe something in the middle could keep those advantages (cache, refetch, etc...).

[TkDodo]

You can use await queryClient.fetchQuery(options) to trigger a fetch, but it won't re-render your component unless you are subscribed to it with useQuery.

[John-Paul-R]

With TanStack Query v5, there is finally a fully TypeScript-supported way to avoid firing a query if you don't have all your params yet: skipToken

Usage, for the example above:

  import { skipToken, useQuery } from '@tanstack/react-query';
  // ...
  const { data, error } = useQuery({
-    queryFn: () => fetchItem(selectedItem),
+    queryFn: selectedItem ? () => fetchItem(selectedItem) : skipToken,
    enabled: !!selectedItem,
    retry: 0
  });

[khsily]

With TanStack Query v5, there is finally a fully TypeScript-supported way to avoid firing a query if you don't have all your params yet: skipToken

Usage, for the example above:

  import { skipToken, useQuery } from '@tanstack/react-query';
  // ...
  const { data, error } = useQuery({
-    queryFn: () => fetchItem(selectedItem),
+    queryFn: selectedItem ? () => fetchItem(selectedItem) : skipToken,
    enabled: !!selectedItem,
    retry: 0
  });

Also, you don't need to use enabled property when using skipToken property.

IMPORTANT: refetch from useQuery will not work with skipToken. Other than that, skipToken works the same as enabled: false.