Option to provide an initial data to the query endpoint

[duskpoet]

Option to provide an initial data to the query endpoint

[phryneas]

The fallback option would be absolutely not fitting here, and regularly go against user expecations.

We have cache collection of data that's not used anymore.

Imagine your hook starts out with initialData from 3am.
Then you fetch and get data from 5pm.
Then your component unmounts for a minute, the new data gets removed from the cache.
The next moment your component mounts again you are back at data from 3am.
Your data would go backwards in time.

[duskpoet]

Like what? The initial state can behave like the request successfully made behind the scenes, so it should be the same as the current behavior.

[duskpoet]

Is there any example of how to achieve this with rehydration? The docs on the topic are very scarce, and the API is complicated.

[phryneas]

That was my step 1 above, yes. "Dump your api slice..." ;)

[amitdahan]

1. On the server, make all requests with RTK Query

In my case, the server is written in Go, is this the only option for using extractRehydrationInfo?

[phryneas]

Unless you have a custom middleware that is async, the reducer will always execute synchronously on dispatch and the store will be populated with the required data to fulfill any request.

[hardikhere]

@duskpoet
you can give a default value when using this hook, useGetUsersQuery()
const {data = initialState} = useGetUsersQuery()

[duskpoet]

But that would unwillingly trigger the api request

[hardikhere]

yeah makes sense to have an initial state but might create some confusion in error cases and refetching cases

[markerikson]

You should be able to do this via the hydration process:

https://redux-toolkit.js.org/rtk-query/usage/persistence-and-rehydration

[hardikhere]

Yes hydration is fine but useSWR has better way, they take fallback object, maybe we can take some inspiration from there
https://swr.vercel.app/docs/advanced/understanding.en-US#fallback

[duskpoet]

I can try to prepare a PR if this feature does seem reasonable.

[phryneas]

Like I said, I'd rather avoid it - it can be quite confusing. I'd assume that for what you want right now, you could use rehydration.

[DaniAcu]

@duskpoet Maybe you are looking for something like api.util.updateQueryData

https://redux-toolkit.js.org/rtk-query/api/created-api/api-slice-utils#updatequerydata

[duskpoet]

@DaniAcu yea, that's a possibility, though it complicates the usage - need to issue this call and wait for its effects before attaching the store to react, otherwise, there will be an unnecessary API call.

[phryneas]

Is there any example of how to achieve this with rehydration? The docs on the topic are very scarce, and the API is complicated.

Sorry I didn't get around to answer back then.

1. On the server, make all requests with RTK Query. Dump your api slice into a script tag or something that will end up in a window.foo global in the browser.
2. In your api:

createApi({
  // ...
  extractRehydrationInfo(action) {
    if (action.type == "rehydrateMe") return action.payload
  },
})

3. In the browser

store.dispatch({ type: "rehydrateMe", payload: window.foo })

[DaniAcu]

@duskpoet I found that extractRehydrationInfo should return the state structure specifically for a createApi slice, maybe the case that @phryneas shared is not enough for your case. I found this work around checking the internals of the library, maybe it could helps you in this case.

import { nanoid } from "@reduxjs/toolkit";

createApi({
  // ...
  extractRehydrationInfo(action) {

    if (action.type === "rehydrateMe") {
      return {
        queries: {
          "getUser()": {
            status: 'fulfilled',
            endpointName: 'getUser',
            requestId: nanoid(),
            originalArgs: "",
            startedTimeStamp: Date.now(),
            data: action.payload,
            fulfilledTimeStamp: Date.now()
          },
        },
        mutations: {},
        provided: {},
        subscriptions: {}
      }
    }
  },
})

Then you could dispatch:

store.dispatch({ type: "rehydrateMe", payload: window.foo })

[phryneas]

@amitdahan
You can also dump an api slice once, look at it's shape and replicate that in go, but you might need to re-do that at one point in the future if we change our spi slice shape.

[duskpoet]

This approach still requires to hold off react mounting store to avoid the api request, right?

[phryneas]

How else would you provide "initial data"?
Yes, you have to know the initial data before you mount your React component that needs that initial data.

The example you gave in the initial post would require that, too.

[duskpoet]

in our case we have it injected into the page by server renderer, so we can access it like a global variable anytime in the javascript code

[DaniAcu]

@phryneas Ou I didn't get well then, sorry. I hope the example helps in some way at least.

@duskpoet I think depends on what you mean by "hold off", the dispatch should run before render. But doesn't need to wait for anything.

In my exploration I did:

dispatch({ type: 'Hydrate', payload: window.foo })


const root = createRoot(document.getElementById('root'));

root.render(<App />);

And didn't throw the request because it was already in the store. I would recommend pay attention to parameters of the endpoint but you don't have params in you getUser endpoint.

[duskpoet]

Right, in our case, the store is created inside the react tree cause it depends on the routing, so it goes deeper than the react router. And I think the following wouldn't work too:

  const store = createStore(...);
  store.dispatch({ type: 'Hydrate', payload: window.foo });
  return (
    <Provider store={store}>
       {children}
    </Provider>
  );
}

because of the thunk middleware

[phryneas]

because of the thunk middleware

What do you mean by that?

[duskpoet]

If the chain of reaction to this action will emit an async action, then the react effect may fire first, initiating the API request

[duskpoet]

Ok, thanks! Let's close the issue then