blog/breaking-react-querys-api-on-purpose

[giscus[bot]]

blog/breaking-react-querys-api-on-purpose

Why good API design matters, even if it means breaking existing APIs in the face of resistance.

https://tkdodo.eu/blog/breaking-react-querys-api-on-purpose

[Faithfinder]

So, with the meta.errorMessage approach, how will that behave if there are two instances of the query specifying different messages?

[TkDodo]

Probably the same as if you specific two different query functions for the same key. Each key should likely only have one message defined.

[Faithfinder]

Would the global callbacks fire for prefetching as well? I might want to show a toast when the query is rendered, but not when it failed in the background.

[TkDodo]

Yes, they fire for all requests. The meta field can help here, too.

[hamitaksln]

Last time, I had similar need and try onSucces with useQuery but as you said, it was not what I need :) My issue was I need to use query data with additional fields that I should be able to update. It was like articles that I'm showing them on home screen with cards. However I need some additional fields like isActive and order. Also I'm hydrating state on serverside so there is no loading etc. So what is the best way doing that and how would you approach it? Thanks for great article.

[TkDodo]

I would need to see a minimal example to understand the question I believe

[hamitaksln]

Sure I will provide the example.

[laurentDellaNegra]

I felt exactly in the onSuccess > dispatch issue. We are still juggling with redux on our project and I didn’t get why my action was triggered 20 times 😅

[literalpie]

Please provide a good migration path 🙏 Mark the APIs as deprecated or give us linting rules so we can address the breakage in our large project before without needing to do it all at once when upgrading.

[TkDodo]

happy to accept PRs to our eslint plugin. I'm thinking all callbacks on useQuery / useQueries could be marked as warning?

[dadamssg]

Is there a way to use meta to add contextual data from the error? For example, if my query failed because the api responded with a specific error i'd like to show the users. Would this be something better suited for a catch around the request itself?

[TkDodo]

you also have access to the error itself in the global event handlers, so yes, I would just make sure that error.message is whatever I want it to be in the queryFn and then show that. The meta trick is nice for static messages, unless you want to go into dynamically replacing placeholders inside of it, which you can, but I don't see a need for that tbh

[dadamssg]

that makes sense. I guess if i want to make it opt-in on a request by request basic i could do something like:

meta: {
  displayApiError: true
}

And then use that in the query cache onError.

[TkDodo]

absolutely 👍

[tielushko]

The current use case I have for onSuccess, is invalidating other queries in the cache. For example, I know in my code any time the data is fetched from a certain set of useQuery hooks, i call invalidateQuery() on a particular useQuery instance. It's not a mutation that happens, just any time I fetch certain data, I need to make sure I refetch another useQuery and have the freshest instance of it. Going through the article, I haven't found a good replacement option yet. How might one handle such a use case, would you be able to provide a suggestion please?

[dsacramone]

@tielushko, did you solve your issue, if do, how?

[tielushko]

@dsacramone, I used the onSuccess in the queryClient that I pass to the QueryClientProvider. Whenever the request that need to trigger the additional requests are executed ( I do that by filtering by the queryKey) I can invalidate the particular useQuery with the linked request. I believe the onSuccess in the queryClient will not be eliminated, so I went with that.

[tielushko]

export const queryClient = new QueryClient({
queryCache: new QueryCache({
onSuccess(_data, query) {
if (listOfQueryKeysToTriggerAnotherFetch.indexOf(query.queryKey[0]) !== -1) {
queryClient.cancelQueries({
queryKey: [queryKeys.YOUR_KEY_YOU_WANT_TO_REFETCH],
});
queryClient.invalidateQueries({
queryKey: [queryKeys.YOUR_KEY_YOU_WANT_TO_REFETCH],
});
}
}
})
});

[dsacramone]

export const queryClient = new QueryClient({ queryCache: new QueryCache({ onSuccess(_data, query) { if (listOfQueryKeysToTriggerAnotherFetch.indexOf(query.queryKey[0]) !== -1) { queryClient.cancelQueries({ queryKey: [queryKeys.YOUR_KEY_YOU_WANT_TO_REFETCH], }); queryClient.invalidateQueries({ queryKey: [queryKeys.YOUR_KEY_YOU_WANT_TO_REFETCH], }); } } }) });

I dig this. But this is sorta what I was afraid of "if" You have dozens of useQuery's in the app, and most of them have side effects.. it all gets garbage dumped in this one place. I guess you "could" normalize it, like you have here - to some extent. Thanks for sharing.

[tielushko]

Yeah, I used to have it individually for the queries that really needed it. I am not a fan of the dumping like this, just like you said...

[nkeyy0]

I found one example when I used the onSuccess callback inside the query. And it was completely wrong 😫. I wondered how best to do this in the tanstack/query. On our project, we have a tracker, and I have to track search text with a number of found results for the search query. I use search text as part of the query key. Example of tracking function:

function trackSearch(text: string, totalCount: number) {
  track('eventName', text, totalCount)
}

And I need somehow detect that the query function triggers by searchText changing and waiting for the request result. What is the best way to do this with tanstack/query?

[TkDodo]

oh, you can still do that in the queryFn:

async function getRows(searchOptions) {
  const data = await fetchRows(searchOptions)
  trackSearch(searchOptions, data.totalCount); // track search text and count of found rows for this search text.
  return data
}

const { data } = useQuery({
    queryKey: ['table', searchOptions],
    queryFn: () => getRows(searchOptions),
 });

[nkeyy0]

I apologize one more time, but probably you didn't get me correctly. I've created a repository to explain some things. link to repo
In this repo, I fetch the data inside event handlers, and I track how many todos have been found for the passed user ID. I ignore the title filter and page changes. I track results only in case the user ID filter has been changed. I'm trying to understand what is the best way to do this with react-query. And I can't find a good way to do this with react-query. Maybe I'm missing something.
P.S. I know that this code is really poor, but it was something like this in my Vue project before migration to vue-query. I just tried to repeat this code in the "react" world.

[nkeyy0]

UPDATE: I solved the problem and completely removed all onSuccess and onError callbacks from my codebase. 2 of the 4 use cases were wrong, and this article helped me find these issues, so I don't see much value in using these callbacks after refactoring the code. Thank you to the author for an excellent article and explanation!

[dsacramone]

Nkeyy0, can you show or link, to how you solved your issue?

[nkeyy0]

I have only Vue example, but I'll try to describe it, it's a simple solution. I have to track the search on each request, so I decided to add an additional field in my response object.

interface SearchOptions {
  filters: Filter[];
  sort: SortModel[];
  searchText: string;
}

declare function fetchTable(
  page: number,
  pageSize: number,
  searchOptions: SearchOptions
): { data: any[]; dataCount: number };

export async function fetchTableData(page: number, pageSize: number, searchOptions: SearchOptions) {
  const data = fetchTable(page, pageSize, searchOptions);

  return { data: data, meta: { searchText: searchOptions.searchText, dataCount: data.dataCount } };
}

function useTableQuery({
  page,
  pageSize,
  searchOptions,
}: {
  page: number;
  pageSize: number;
  searchOptions: SearchOptions;
}) {

  const { data: tableData, ...queryResult } = useQuery({
    queryKey: ['table', page, pageSize, searchOptions],
    queryFn: () => fetchTableData(page, pageSize, searchOptions),
  });
}

  const searchResultsToTrack = ref<{ totalCount: number; searchText: string }>({
    searchText: '',
    totalCount: 0,
  }); // it's a state init 

  // watch in vue is something like useEffect in React, this function accepts the first argument as a reactive variable we have to watch, and the second argument is a callback function with an action to do on state change.
  watch(tableData, newData => {
   // In case data is "undefined" don't do anything
    if (!newData) {
      return;
    }

    // In other cases update the reactive variable with new request results.
    searchResultsToTrack.value = {
      searchText: newData.meta.searchText,
      totalCount: newData.meta.totalCount,
    };
  });

  // watch the search results 
  watch(searchResultsToTrack, (newResult, oldResult) => {
    // If searchText is empty or old text is the same as new - don't do anything. 
    if (!newResult.searchText.trim() || newResult.searchText === oldResult.searchText) {
      return;
    }

   // In other cases track the search results.
    trackSearch(newResult.searchText, newResult.dataCount);
  });

I guess you can do something similar in React with useState and useEffect, but I don't know how to access the previous value in React, so I leave the Vue example here and hope that the main idea is clear. If you have any questions I'll be happy to answer any of them.

[ShravanSunder]

I've reposted this from the RFC: TanStack/query#5279 (comment)

---

@TkDodo So currently we use the callbacks to update query parameters after making sure that it won't create a rendering loop.

/**
 * Query repeating template from the API
 */
export const useLoadeQuery = (
  paginationQuery: Partial<IPagination>
): QueryObserverResult<IRepeatingTemplateTableResponse> => {
  const { searchQuery } = useTableSearch();
  const { filterQuery } = useTableFilter();

  const client = useQueryClient();
  const { updateSearchParams } =
    useNavigationSearchParams<Partial<IPagination>>();

  const apiResult = useQuery(
    [
      "useLoadRepeatingTemplateQuery",
      searchQuery,
      paginationQuery.orderBy,
      paginationQuery.orderDirection,
      paginationQuery.pageNumber,
      paginationQuery.pageSize,
      filterQuery,
    ],
    queryApi(() => {
      return apiRequests().getRepeatingTemplateListAsync(
        searchQuery,
        paginationQuery,
        filterQuery
      );
    }),
    {
      notifyOnChangeProps: ["data", "isLoading"],
      refetchOnMount: "always",
      onSuccess: (result: IRepeatingTemplateTableResponse) => {
        const isSame =
          paginationQuery.orderBy === result.pagination.orderBy &&
          paginationQuery.orderDirection === result.pagination.orderDirection &&
          paginationQuery.pageNumber === result.pagination.pageNumber &&
          paginationQuery.pageSize === result.pagination.pageSize;

        if (!isSame) {
          // the array below should be the same order as above cache key used in react query
          client.setQueryData(
            [
              "useLoadRepeatingTemplateQuery",
              searchQuery,
              result.pagination.orderBy,
              result.pagination.orderDirection,
              result.pagination.pageNumber,
              result.pagination.pageSize,
              filterQuery.searchWithin,
              filterQuery.startDate,
              filterQuery.endDate,
            ],
            result
          );
          //update the url params with the result pagination from the back end to make sure the data and url parms are in sync
          updateSearchParams(result.pagination);
        }
      },
    }
  );
  return apiResult;
};

We also use it to update our redux store when certain data is required by client side state or thunks

For example organisation data that we need in redux state

/**
 * Calls the organization info API
 * Should use hook directly in react components or in things in the react lifecycle.
 * Access to org info in redux store should only be within thunk calls. If not use this hook!
 * @returns
 */
export const useOrganisationInfoQuery =
  (): QueryObserverResult<IOrganisationInfo> => {
    const dispatch = useDispatch();

    const apiResult = useQuery(
      ["getOrganizationInfoAsync"],
      queryApi(apiRequests().getOrganisationInfoAsync),
      {
        onSuccess: (result: IOrganisationInfo) => {
          dispatch(commonActions.setOrganisationInfo(result));
        },
        onError: () => {
          dispatch(commonActions.setOrganisationInfo(undefined));
        },
      }
    );

    return apiResult;
  };

Do you think there are better ways to do these? The useEffect loop ads more render cycles and dependency gotcha's to this whole process. How else would you recommend to do this?

[TkDodo]

answered over there :)

[Gusis93]

So if I need the data from the query in order to perform other actions such as a mutation, the best way to do it is with an useEffect now?

I saw your response in a comment from nkeyy0 where you advice to do a side action in the fetch function. So could something like this work? Or even be good practice?

async function getArticle(onRead) {
  const data = await fetchArticles();

  markAsReadMutation({ article: data.articleId }, {
       onSuccess: () => {
           if (onRead) { onRead(); }
       },
   });

  return data
}

const onRead = () => invalidateQueries(articleDashboardQuery);

const { data } = useQuery({
    queryKey: ['article', 1]
    queryFn: () => getArticle(onRead),
 });

[TkDodo]

it's a bit weird to me that fetching a resource would also trigger a mutation. In your example: did the user indicate that they really read it, like scrolled to a certain paragraph, or maybe spend x seconds on that page?

if you want: once the user visits the page, mark it as read immediately, you could do this on the server, when the route is visited.

Just like the useEffect, onSuccess has the drawback of executing after each fetch, for each observer, so you would get potentially too many mutations fired. If that's not a problem, sure, the useEffect works, and the code above where you fire the mutation from within the queryFn will also work.

[ChambreNoire]

I have a use-case where the user can optionally fill a form using external data (fetched from an external rest api). So they click a button which sets a value using the first form field, thus enabling the query. If the query is successful I set the form fields accordingly.

export const useExtData = (name) => useQuery({
    enabled: !!name,
    queryKey: ['externalData', name],
    queryFn: fetchExternalData,
    onSuccess: (extData) => {
      form.resetFields();
      form.setFieldsValue(extData);
  }
})

So replace this with a useEffect on useExtData's { data } ?

[ChambreNoire]

(onSuccess is passed as an arg to the custom hook - thus has access to form - but you get the gist...)

[TkDodo]

if you only use the query to set form fields, you can do this with fetchQuery in the onClick handler, roughly like this:

onClick={async () => {
  const extData = await QueryClient.fetchQuery({
    queryKey: ['externalData', name],
    queryFn: fetchExternalData
  })
  form.resetFields();
  form.setFieldsValue(extData);
}}

otherwise, I'd say this depends on the form lib you're using. If it's a separate component, you can give it a key to re-mount:

const extData = useExtData(name)

<Form key={name} initialData={extData} />

But yes, you can also make a useEffect.

[Hyodori04]

I am using useQuery with wrapper like

export const useGetUser = () => {

  return useQuery({
    queryKey: getUserKey.user,
    queryFn: () => getUser(),
  });
};

In this case, we don't have severals callback in other component. Global queryClient is hard to handle mutilple error case
I agreed with your opnion in this posts. But I think that there should be a way to handle callback per one userQuery key.
Is there any way to handle callbacks in my example with queryClient?

[TkDodo]

In this case, we don't have severals callback in other component.

if you add a callback in useGetUser, and you then call the hook multiple times in different components, you will again have several callbacks.

But I think that there should be a way to handle callback per one userQuery key

That's really what the QueryFunction is, because there, we can enforce that you don't dangerously close over things (with our eslint rule). If the onSuccess callback were only called once, in which component would we call it?

function Component(props) {
  useQuery({
    queryKey: getUserKey.user,
    queryFn: () => getUser(),
    onSuccess: () => console.log(props.foo)
  });
}

function App() {
  return (
    <main>
      <Component foo={1} />
      <Component foo={2} />
    </main> 
  )
}

I hope this illustrates the problem: Would this example log 1 or 2 ? Right now, it does both. That is correct, but also confusing. However, if you do:

useQuery({
  queryKey: getUserKey.user,
  queryFn: async () => {
    const user = await getUser()
    console.log(props.foo)
    return user
  }
})

our lint rule will complain and tell you to add props.foo to the QueryKey, in which case they become separate queries.

[coryhouse]

What's the recommended approach for populating an editable form?

Should I set separate state via useEffect by watching the query's data?

Something like this?

  const [products, setProducts] = useState(emptyProducts);

  // Assume this is a simple react-query wrapper 
  const { data } = useProducts();

  useEffect(() => {
    if (data) setProducts(data);
  }, [data]);
``

[TkDodo]

Hi Cory 👋

The useEffect is not a good idea because it will overwrite your products when a background refetch comes in. That would be devastating if I edit a form, switch tabs, come back and my input will be overwritten by the effect. Generally, useEffect to sync data between two sources that already are inside react is an anti-pattern.

I have a blog post specifically for working with forms that shows two approaches: https://tkdodo.eu/blog/react-query-and-forms

[jakubfiglak]

I find myself quite tempted to try and sync state with onSuccess callback 🙈

I'm building a chatbot feature in my application and the flow looks like so:

• the app calls the /initialise endpoint with the user id and some additional data
• chatbot api passes back a session id (temptation no. 1 - sync the sessionId)
• for the remainder of the session the app calls the /transactions endpoint with the session id and the text input
• as a response, it receives plain text answer and some additional data, basically the guides for next possible question/action (temptation no. 2 - I need to have an array of messages which consists of both the bot responses, and user input, stored somewhere to render the chat)

Does it even make sense to use RQ for this? I don't need any caching but I'd like to use loading and error state management. How would you approach it? Thanks upfront!

[prateek3255]

Great blog as usual @TkDodo 🎉. I just wanted to suggest one thing, for the onDataChanged thing, I think we can skip the useEffect by updating the data during rendering. Like this:

export function useTodos(filters) {
  const { dispatch } = useDispatch()

  const query = useQuery({
    queryKey: ['todos', 'list', { filters }],
    queryFn: () => fetchTodos(filters),
    staleTime: 2 * 60 * 1000,
  })

  const [prevData, setPrevData] = useState(query.data)

  if (query.data !== prevData) {
    setPrevData(data)
    dispatch(setTodos(query.data))
  }

  return query
}

Updating state during rendering might look like an anti-pattern, and even I used think that useEffect was the only way to handle such situation until I read the You might not need an effect guide on the new React docs, which explains how it is more efficient then doing this via en effect:

When you update a component during rendering, React throws away the returned JSX and immediately retries rendering. To avoid very slow cascading retries, React only lets you update the same component’s state during a render.

And docs also mentioned the things you already mentioned which is state syncing is bad anyways and should be avoided unless absolutely necessary.

[TkDodo]

I think we can skip the useEffect by updating the data during rendering

maybe you can do that in user-land, but from the lib's perspective, we cannot invoke an onDataChanged callback during render, because we don't know what is going to happen inside of it.

Also, while you can definitely do that with calling setState of the same component, I'm not sure if calling dispatch during rendering is allowed. dispatch writes to an external store and triggers all subscribers. The guide also mentions this (emphasis mine):

To avoid very slow cascading retries, React only lets you update the same component’s state during a render. If you update another component’s state during a render, you’ll see an error.

[prateek3255]

Oh okay makes sense 👍🏻

[hadson172]

We were using onSuccess callback in queries to remove existing data from cache if there were any with length bigger than 100 items.
So i was wondering, if onSuccess will be removed, how do you propose to do something like this ? Is there any mechanism inside react-query that protects user from Out of memory error ?

[TkDodo]

technically, everything that you did in onSuccess you can do in the QueryFunction after you make the request.

Is there any mechanism inside react-query that protects user from Out of memory error ?

React Query has auto garbage collection for unused data. If you use data, react needs it anyways to render it, so it needs to be in memory

[jermainemercado]

Hi TkDodo,
I have a use case where the query should be fired as a callback in order to validate some FE form values on the server side.
After the query is called, upon success a notification should be shown, on error a different type of notification.

E.G:

useValidateForm = (payload) => {
    queryFn: async () => Promise<boolean>,
};

const { data: isValid, refetch: validateForm } = useValidateForm(payload);

useEffect(() => {
    if (isValid) {
        // Do stuff when isValid
    } else {
        // Do stuff when !isValid
    }
}, [isValid])

return <button onClick={() => validateForm()/>

My issue is that the useEffect runs on initial render which I do not want, which is why it would be better to have the onSuccess callback available. Am I writing an anti-pattern?

[jermainemercado]

@chiptus -- thanks.

@TkDodo -- I've attempted to do this however for some reason the error is not being shown correctly. I've attempted to work around it by explicitly handling the error on the component level, where usually the global QueryClient settings would handle the error.

However doing this makes it so that the error is shown whenever the user navigates back to the screen that is rendering the component. I only want it to show once. Is it possible to remove the errored query from the cache after catching it?

[jermainemercado]

  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: false,
      }
    },
    queryCache: new QueryCache({
      onError: handleError,
    }),
    mutationCache: new MutationCache({
      onError: handleError
    }),
  });

const useValidatePayload = (payload) => useQuery({
		queryKey: [payload.code],
		queryFn: async () => {
				const res = await validate(payload);

				 if (isValid) {
                     // Do stuff when isValid
                 } else {
                    // Do stuff when !isValid
                 }
        },
		enabled: false,
	});

The global onError is not being triggered here. The async method is a native fetch, I can see in the Networking tab that I receive an error 400 from the server but it is not getting handled correctly. Could it be due to nothing being returned if there is an error?

[TkDodo]

if you're using fetch, erroneous status codes are not automatically rejected promises:

• https://tanstack.com/query/v5/docs/react/guides/query-functions#usage-with-fetch-and-other-clients-that-do-not-throw-by-default
• https://tkdodo.eu/blog/react-query-fa-qs#the-fetch-api

[jermainemercado]

Thanks for the help so far. --

Is it incorrect to be initializing QueryClient within the <App/> component? I'm finding the global error handling to be inconsistent. Or is it just that I'm incorrectly relying on the providers to display the error notification?

  const { handleError } = useErrorHandler(); // Uses Notification Provider to display the error.

  const queryClient = new QueryClient({
    defaultOptions: {
      queries: {
        retry: false,
        staleTime: 1000 * 60 * 60, // 1 hour in milliseconds
        refetchOnWindowFocus: false,
      }
    },
    queryCache: new QueryCache({
      onError: handleError,
    }),
    mutationCache: new MutationCache({
      onError: handleError
    }),
  });

  const router = createBrowserRouter([ 
      // routes
  ]);

  return <NotificationProvider> // Displays the error
    <QueryClientProvider client={queryClient}>
      <RouterProvider router={router} />;
      <ReactQueryDevtools initialIsOpen={false} />
    </QueryClientProvider>
  </NotificationProvider>;
  };

const SomeComponentDownTheTree = () => {
    const useDeleteCloudUser = (retailer: string) => useMutation({
        mutationFn: (ids: number[]) => deleteUsers(ids), //http request
        onSuccess: async () => await queryClient.invalidateQueries({ queryKey: [USERS_QUERY_KEY, someDependency] }),
    });

    const { mutate: deleteUsers } = useDeleteUsers(someDependency);
    const { handleError } = useErrorHandler();

    deleteUsers(rowsSelected.map(row => row.id), {
        onSettled: () => // close the modal
            // Does not throw error unless explicitly stating onError here even though the globals have been set.
            onError: handleError
    });
};

[Newbie012]

You can read about proper QueryClient initialization here - https://tanstack.com/query/v4/docs/react/eslint/stable-query-client

[AndrewCudworthAB]

Is there a reason something like the following would not work? I notice none of the examples use console logs on error. We wish to log the errors a certain way. I'm debating if this is an issue with our setup or console logs should not be used in queryCache this way.

  queryCache: new QueryCache({
    onError: (error, query) => {
      console.log("file: QueryClientConfig.tsx:52 error ~ error:", error);
    },
    onSuccess: (data, query) => {
      console.log("file: QueryClientConfig.tsx:52 success ~ data:", data);
    },
  }),

[AndrewCudworthAB]

Note the above is an example not the exact way we're logging.

[TkDodo]

this should work, please show a reproduction if it's not working for you

[AndrewCudworthAB]

Thank you. I'll investigate non react-query causes first then.

[arslonbekXX]

Hi @TkDodo
Is it OK to use this custom hook ?

import React from 'react';
import { DefaultError, QueryKey, useQuery as useBaseUseQuery, UseQueryOptions as BaseUseQueryOptions, UseQueryResult } from '@tanstack/react-query';

interface UseQueryOptions<TQueryFnData, TError, TData, TQueryKey extends QueryKey = QueryKey> extends BaseUseQueryOptions<TQueryFnData, TError, TData, TQueryKey> {
  onError?: (error: TError) => void;
  onSuccess?: (data: TData) => void;
}

export const useQuery = <TQueryFnData = unknown, TError = DefaultError, TData = TQueryFnData, TQueryKey extends QueryKey = QueryKey>({
  onError,
  onSuccess,
  ...args
}: UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>): UseQueryResult<TData, TError> => {
  const query: UseQueryResult<TData, TError> = useBaseUseQuery({ ...args } as any);

  React.useEffect(() => {
    if (query.data && onSuccess) onSuccess(query.data);
  }, [query.data]);

  React.useEffect(() => {
    if (query.error && onError) onError(query.error);
  }, [query.error]);

  return query;
};

[TkDodo]

it violates the exhaustive-deps lint rule and can therefore suffer from stale closure problems

[pablojsx]

Using trpc with onSuccess, works great if you know what you are doing. You can also refetch.

[talha6sensehq]

const { data, isLoading, isFetching } = useQuery<GetChargerDetailsSuccessType, unknown, GetChargerDetailsSuccessType>({
queryKey: ["chargerDetails"],
queryFn: () => getChargerDetails(chargerId ?? ''),
onSuccess: (success: GetChargerDetailsSuccessType) => {
const formFields: (keyof GetChargerDetailsSuccessType)[] = ['numberOfPlugs', 'chargerPointSerialNumber', 'idTag', 'unit', 'displayId'];
formFields.forEach((field) => {
if (success?.[field] == null) {
setValue(field, '')
} else {
setValue(field, success?.[field])
}
});
}
});

I am using react-hook-form to get the details from an API and populate an edit form. For that I used the setValue of react-hook-form in the onSuccess callback. What should be the approach now in v5?

[TkDodo]

https://tkdodo.eu/blog/react-query-and-forms

[betoobernal]

Nice explanation and It really make sense. I've read it and i understand why you did it. Thank you for be a excellent developer.

[liby]

I'm currently facing an issue with my implementation using React Query where unnecessary API requests are being triggered due to the way dependencies are set up in my queries. Here's the situation:

When the organizationId changes, it triggers both useOrganizationQuery and useBillingPlansQuery to fetch data from the API. The data fetched by useOrganizationQuery includes a couponCode, which then causes useBillingPlanWithCouponQuery to make its first API request. This initial request is actually unnecessary in our scenario. Following this, a change in the billingPlans leads to a change in the planId, prompting useBillingPlanWithCouponQuery to make a second API request.

Here's a summary of the problem: I want to prevent the first unnecessary request made by useBillingPlanWithCouponQuery when organizationId changes, aiming to trigger it only once under specific conditions.

Below are the relevant parts of the code for context:

// API fetch functions
export const fetchOrganization = ({ userId, organizationId }) => { /* Fetch logic */ };
export const fetchBillingPlans = ({ userId, organizationId }) => { /* Fetch logic */ };
export const fetchBillingPlanWithCoupon = ({ couponCode, planId }) => { /* Fetch logic */ };

// Custom hooks using React Query
export const useOrganizationQuery = (params) => { /* Query setup */ };
export const useBillingPlansQuery = (params) => { /* Query setup */ };
export const useBillingPlanWithCouponQuery = (params) => { /* Query setup */ };

// Component that uses the above queries
export const CreateSubscriptionForm = ({ userId, organizations }) => {
  // State and effects to manage organizationId, planId, couponCode, etc.
};

For a more complete view of the code and its context, please find it here.

The core of the issue lies in managing dependencies and triggering useBillingPlanWithCouponQuery optimally. Does anyone have suggestions on how to optimize this to ensure useBillingPlanWithCouponQuery is triggered only once, and only when necessary, avoiding the initial unnecessary request?

[TkDodo]

disable the useBillingPlanWithCouponQuery while a query it depends on is in isFetching state

[liby]

Thank you very much, I will go and try it.

[liby]

Hi again,

Following your previous suggestion, I disabled useBillingPlanWithCouponQuery while any of its dependent queries are in the isFetching state. This resolved the double-fetching issue for subsequent organization switches but not for the initial switch after a page refresh.

// Custom hooks using React Query
export const useOrganizationQuery = (params) => { /* Query setup */ };
export const useBillingPlansQuery = (params, isDependentDataFetching) => useQuery({
    // ...
    enabled: !isDependentDataFetching,
});
export const useBillingPlanWithCouponQuery = (params, isDependentDataFetching) => useQuery({
    // ...
    enabled: !isDependentDataFetching && !!params.couponCode && !!params.planId,
});;

export const CreateSubscriptionForm = ({ userId, organizations }) => {
  const { isFetching: isOrganizationFetching } = useOrganizationQuery({
    userId,
    organizationId,
  });

  const { isFetching: isBillingPlansFetching } = useBillingPlansQuery({
    userId,
    organizationId,
  }, isOrganizationFetching);

  const { isFetching: isBillingPlanWithCouponFetching } = useBillingPlanWithCouponQuery({
    couponCode,
    planId,
  },  isOrganizationFetching || isBillingPlansFetching);
}

Here's what's happening:

1. On the initial organization switch, fetchOrganization completes, but fetchBillingPlans has not started yet. During this time, couponCode updates (but planId does not), causing useBillingPlanWithCouponQuery to trigger.
2. This results in an unnecessary request by useBillingPlanWithCouponQuery.
3. For subsequent switches, there's no issue, and no unnecessary requests are made.
   It seems there's an intermediate state on the first switch where the dependencies are partially updated, leading to an early trigger of useBillingPlanWithCouponQuery. Any thoughts on how to prevent this initial unnecessary request?

Thanks!

[christyantoun]

Small question, i am using isError in my component, once the isError is true even if the component unmounts and mounts again, the state of isError remains true and the toast message is reappearing. Any idea how to go about such a situation ?

[christyantoun]

I followed your approach to add a check to the data changing but why is the isError state persisting is my question

[TkDodo]

I fixed a bug around this last week:

• Typescript incorrectly narrows error based on isLoading TanStack/query#7105

if you can still reproduce something with the latest version, please show a reproduction and file an issue.

[timkishkin]

Hi all! I know I might be late, but I would really appreciate a piece of advice for my use case which seems to be quite simple and common, but difficult to solve without onSuccess or useEffect.

Let's say I have a dialog with several sections and "Submit" button at the bottom. Each section is represented by a child component, e.g. component Products renders a selectable list of products. On Submit all user's selections are sent to the server.

In my Products child component, I fetch products (server state) using useQuery. By default, all products are selected. The user can change the selection.

How can I pass the eventual selection from the child component to the parent? An obvious idea is to have [products, setProducts] = useState([]) in the parent and pass setProducts to the child which is called on user's interaction. But then, what if there is no user interaction? How can I init products with the default state (all products) without onSuccess or useEffect?

Sorry if I've missed or misunderstood something. I've read through most of comments here and different approaches suggested in the "Practical React Query" blog, but still cannot find an elegant solution.

Thanks!

[TkDodo]

How can I init products with the default state (all products) without onSuccess or useEffect?

Derive state:

const productsQuery = useQuery(...)
const [selectedProducts, setSelectedProducts] = useState(undefined)

const products = selectedProducts ?? productsQuery.data ?? []

[timkishkin]

@TkDodo thanks! I agree that this is the ideal approach as we are not mixing states and have no extra rerenders. And I've actually started with this idea, before I've reorganized the code into parent and child components.

But after the separation I stumbled into the issue: I need the derived state both in the parent component (to submit it) and in the child component (to display the initial selection). Which seems to be a problem, because I didn't want to overload the parent with all the 3 states (server, client, derived); and if I put it all into the child - how do I "return" the derived state back to parent?

After my yesterday's post I've actually come up with a sort of an answer to that question. I cannot "return" a value from a component, but I can do it from a custom hook. I've extracted all the 3 states (basically the 3 lines from your comment) into a custom hook which returns the query object, the state setter and the derived state:

export function useProductsState() {
  const productsQuery = useQuery(...)
  const [selectedProducts, setSelectedProducts] = useState(undefined)
  const selectedOrDefaultProducts = selectedProducts ?? productsQuery.data ?? []

  return {
    productsQuery,
    setSelectedProducts,
    selectedOrDefaultProducts 
  }
}

I then use that hook in my parent component which can use selectedOrDefaultProducts for submission. The parent component forwards the returned value of the hook into the child component as props, which renders and handles user's interaction.

In other similar cases I have a more complex logic of the default selection (e.g. pre-select the top 5 recent products), which seems to fit nicely into the hook.

Do you think it's a valid approach?

[TkDodo]

because I didn't want to overload the parent with all the 3 states (server, client, derived)

your state still lives in the parent component, you've just extracted it to a custom hook. this is fine.

[tapsouza]

Thanks for another amazing post TkDodo! 😁

I'm just a little bit worried about the meta object allowing any entry, so I was thinking about extending QueryMeta on global.d.ts and declaring all entries I will allow on my application. I'm thinking about doing this since I have not seen any other way of making QueryMeta to be infered while creating the new QueryCache. Do you think this is a good idea!? Or am I missing something!?

declare module '@tanstack/react-query' {
  interface QueryMeta {
    errorMessage?: string;
  }
}

Thanks!

[TkDodo]

you can actually use the Register interface to provide types for meta:

https://tanstack.com/query/v5/docs/framework/react/typescript#registering-global-meta

[tapsouza]

Oh! That's awesome! Thank you very much! 💪

[ImBard]

What should i do if i'm using Zustand to store the data, i was using the onSuccess to save this data in Zustand, i realized that it's not good, but it was someone more experienced than me who told me to use onSuccess, but now i'm having a lot of rerendering cycle because of this, does anyone know how can i save the data in the zustand store without onSuccess?

[TkDodo]

there is no reason that you have to put data from react-query into a zustand store - react query has it's own store that is globally available. I was hoping that the article made that clear 😅

[ImBard]

I am using react-native.
I'm using Zustand because I need to persist some data to my local storage and this data comes from an API.
Am I doing this in a very wrong way?

[TkDodo]

you can persist the QueryClient: https://tanstack.com/query/v5/docs/framework/react/plugins/persistQueryClient

[tkfmed]

How to use error meta approach when I would like to display error message differently, depend on the particular error context (I want to display one query error in toast, different one in banner etc)

[TkDodo]

ideally the error that is thrown would contain all the necessary information

[linyawun]

I’m using dispatch to show my error message, how can I use dispatch in my global onError function when my useDispatch should be in component function?

const queryClient = new QueryClient({
  queryCache: {
    onError: (error) => {
      const { dispatch } = useAppDispatch(); //error: hooks can only be called inside of the body of a function component
      const errorMessage = error.response.data;
      void dispatch(createAsyncMessage(errorMessage));
    },
  },
});

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

[TkDodo]

create the QueryClient in useState inside App so that you can close over dispatch:

function App() {
  const { dispatch } = useAppDispatch();
  const [queryClient] = React.useState(() => new QueryClient({
    queryCache: new QueryCache({
      onError: (error) => dispatch(...)
    })
  }))

  return (
    <QueryClientProvider client={queryClient}>
      <Example />
    </QueryClientProvider>
  )
}

This assumes App has access to the redux context, so you need to nest your providers accordingly

[linyawun]

It works! Thank you very much! 💪

[Faithfinder]

In most cases it's safe to just import store from wherever you have it defined and do store.dispatch as well. Unless you have multiple stores and all that, but typical redux setups dont do anything like that.

[TkDodo]

breaks things where you want a different store e.g. in testing

[linyawun]

I currently only have one store, but I plan to add it to the test in the future. I will study it to see which method is more suitable. Thank you for your suggestions!💪

[arpithagowdagm]

Is onSuccess being deprecated from useInfiniteQuery as well?

I have a scenario where I need to dispatch an action after receiving data. What is the recommended approach if onSuccess is deprecated?

[krzysztofMlczk]

I fully understand the motivation behind this. I am wondering what would be a go to way of handling things when data returned from query needs to be used to do some imperative operations (e.g. create elements on a "board"). This is a case for me as as the "board" component is not capable of working in a declarative manner due to performance issues. Is there any other way to handle such use cases other than using custom useEffect? If not what actually should be placed in the dependency array of such useEffect - query.data, query.isSuccess or maybe even something else?
Thanks in advance, this blog helped mi migrate to React Query whole codebase in a week!

[TkDodo]

what does "creating a board" mean? Is it making a POST request to /api/board/new, or is it just calling const board = new Board() ?