query client persister doesn't work when immediately navigating to another page

[dwene]

We're using react-query with localstorage as a persistent cache and gatsby as our framework.

We encountered an issue today where we were optimistically updating a query key, and immediately navigating to another page. The data was not getting persisted into local storage because that seems to be an async operation, and the page we navigated to had stale data.

We were able to hack it into working by wrapping our navigate function in a setTimeout

      queryClient.setQueryData(['Orders'], (query: OrdersQuery) => {
        if (query?.me?.subscription?.current_order?.medusa_cart) query.me.subscription.current_order.medusa_cart = cart;
        return query;
      });

      // NOTE: setTimeout is needed to ensure the swapMealInCurrentOrder is completed before the page is changed (issue with data Persistor)
      setTimeout(() => {
        navigate('/');
      }, 10);
      

and setting a really low throttle timeout

  const localStoragePersistor = createWebStoragePersistor({ storage: window.localStorage, throttleTime: 1 });

  persistQueryClient({
    queryClient,
    persistor: localStoragePersistor
  });

`

It would be really nice if there was a hook into the queryClient that allowed us to tell it to persist the data immediately, before navigating to another page.

[TkDodo]

Are we talking about a hard page reload / navigation here?

[dwene]

@TkDodo That right there was the question I needed.

We had setup react query wrong with our project. On every page navigation, it was re-rendering one of the base App components that setup the reactQuery instance, which re-initialized the state from local-storage. There was a race condition that was sometimes saving the local storage in time and often times not.

For anyone else who runs into this issue, here's how we fixed it for gatsby.

const PageWrapper = ({ children }) => {
  const { handleQueryError } = useHandleQueryError();

  const [queryClient] = useState(
    new QueryClient({
      queryCache: new QueryCache({
        onError: (error, query) => {
          // SEE: https://tkdodo.eu/blog/react-query-error-handling#the-global-callbacks
          // 🎉 only show error snackbars if we already have data in the cache
          // which indicates a failed background update
          handleQueryError(error);
        }
      }),
      mutationCache: new MutationCache({
        onError: (error, query) => {
          // SEE: https://tkdodo.eu/blog/react-query-error-handling#the-global-callbacks
          // 🎉 only show error snackbars if we already have data in the cache
          // which indicates a failed background update
          handleQueryError(error);
        }
      })
    })
  );

  useEffect(() => {
    const localStoragePersistor = createWebStoragePersistor({ storage: window.localStorage });
    persistQueryClient({
      queryClient,
      persistor: localStoragePersistor
    });
  }, []);

  return (
    <Store providers={[IconProvider, DrawerProvider]}>
      <QueryClientProvider client={queryClient}>
        {children}
        <ReactQueryDevtools initialIsOpen={false} />
      </QueryClientProvider>
    </Store>
  );
};

[TkDodo]

oh that's nice. in case you have a hard page reload for some reason, like document.location = someUrl after a muatation, I think your issue is a legit one. persistence happens asynchronously, so it might not be "done" when the browser redirects.

What you can do in v4 (currently in alpha) is to use the separate persistQueryClientSave method to trigger a save. It is async, so you can await it, and then trigger the redirect.

[DenIrkhin]

Yes indeed, that's exact case we have on our side we are setting document.location = someUrl on navigation and loosing sporadically because of race conditions between saving the state into localStorage and switching to new Url.

Is there a solution for it in v4?
I see the answer that throttle is used anyway no matter what's throttleTime provided, but maybe there is a workaround about?

Using await on persistQueryClientSave as describe in https://tanstack.com/query/v4/docs/react/plugins/persistQueryClient#api
doesn't help because setTimeout is still happening. It's a side effect and doesn't influence persistQueryClientSave promise resolving

[TkDodo]

Using await on persistQueryClientSave as describe in https://tanstack.com/query/v4/docs/react/plugins/persistQueryClient#api
doesn't help because setTimeout is still happening. It's a side effect and doesn't influence persistQueryClientSave promise resolving

hm, would you say this is a bug? I would expect await on a save function to return once everything has been saved 😅

[inquiztr]

I know this is an old discussion but I ran into the same issue. I feel like it is a bug. While persistQueryClientSave is throttled 1000ms default, I didn't expect it to have to wait 1000ms for the first call to go through. The setTimeout in presists' throttle function makes it mandatory for that delay to happen on first call.

For my use case, when adding a product to cart we store in React Query/Local Storage. Upon navigating to the checkout page we do another api call to check the cart if items are in stock. In my case the product was out of stock, and when I update the cache and navigate the user back to the shopping bag page I was finding the cache had not saved to local storage. The inital 1000ms delay from the peristor is unavoidable with the synchronous persistor.

I did get it working using createAsyncStoragePersister. This persistor uses a leading edge throtter, and I can await its call before directing users away to the shopping bag. I am not sure if I will run into any sideffects using asynchronous wrapper around the synchronous localstorage calls?

[TkDodo]

I am not sure if I will run into any sideffects using asynchronous wrapper around the synchronous localstorage calls?

no, this is fine. I plan to deprecate the synchronous persister because as you said, you can just use the async one. There’s no need for this separation, as restore is always an async process.