why Recall initiate causes previous api to be called together?

[dev-splin]

I'm using next.js and RTK Query together.
I initialized the global data in getInitialProps using initiate.
And when I enter url directly into the address bar and access it, I have to change the global data.
So, after changing the argument, the API used to initialize the global data using initiate was called again.

It works well when accessing url directly, but there was a problem when moving the browser back or forward.
The api called using init in getInitialProps was called again when using init in getServerSideProps. (argument is different.)

What is the cause of this problem??

example code

// getInitialProps
MyApp.getInitialProps = wrapper.getInitialAppProps((store) => async (context) => {
  ...


  // initialize data from getInitialProps
  await store.dispatch(fetchMyInfo.initiate(1, { forceRefetch: true })).unwrap();

  ...
})

// getServerSideProps 
export const getServerSideProps = wrapper.getServerSideProps((store) => async (context) => {
  const { userNo } = context.query;

  ...

  // Recall after changing argument
  await store.dispatch(fetchMyInfo.initiate(userNo , { forceRefetch: true })).unwrap();

  ...
});

Thank you for your reply. :)

[phryneas]

I have to admit, from the description I don't really understand what problem you are describing here, I'm sorry. Could you maybe explain that in more detail?

Generally: when getInitialProps or getServerSideProps are executed is a next.js thing, we can't really influence that.
I don't think you need the forceRefetch here (this will always be executed with a new empty store on the server) and you probably also don't need the unwrap (you only need that to access the result after the call, but here you're just prefilling the cache?).

[dev-splin]

I have to admit, from the description I don't really understand what problem you are describing here, I'm sorry. Could you maybe explain that in more detail?

Generally: when getInitialProps or getServerSideProps are executed is a next.js thing, we can't really influence that. I don't think you need the forceRefetch here (this will always be executed with a new empty store on the server) and you probably also don't need the unwrap (you only need that to access the result after the call, but here you're just prefilling the cache?).

The exact flow is as follows.

1. Call fetchMyInfo endpoint from getInitialProps to initiate
2. Slice Internal ExtraReducers save data on Redux when fetchMyInfo.matchFulled in addMatcher
3. Initiate fetchMyInfoApi from getServerSIdeProps to another argument (to replace the data save in redux)
4. Same as number 2

I expected the data in redux to change if I re-initiate fetchMyInfoApi in getServerSideProps. (corresponding to the argument of getServerSideProps)
However, often when you run fetchMyInfo initiate on getServerSideProps, the api that you ran on getInitialProps will run once more.
Therefore, the problem occurred because the data did not fit correctly.

I've been googling hard, but I can't find a reason, so I'm leaving a question like this :(

[phryneas]

Honestly, I'm not sure if Next.js will even execute gSSP for something like a browser navigation, yet alone actually transfer that data over.
Assuming they would: Since you work with extraReducers here, our normal RTKQ SSR strategies also don't apply (since those transport over RTKQ internal state) and you will probably have to integrate some kind of extra merging logic with next-redux-wrapper.

[dev-splin]

I'm sorry for the delay in answering.

After debugging, it seems that the side that saves data with extraReducers is saved without any problems.
I looked at init internal logic because I was wondering why API was also called previously cached API.
I don't know all the internal method behavior, but is there a case where the old API is called together because of the last promise state promise part in the logic below?

        const thunkResult = dispatch(thunk)
        const stateAfter = selector(getState())

        middlewareWarning(dispatch)

        const { requestId, abort } = thunkResult

        const skippedSynchronously = stateAfter.requestId !== requestId

        const runningQuery = runningQueries.get(dispatch)?.[queryCacheKey]
        const selectFromState = () => selector(getState())

        const statePromise: QueryActionCreatorResult<any> = Object.assign(
          forceQueryFn
            ? // a query has been forced (upsertQueryData)
              // -> we want to resolve it once data has been written with the data that will be written
              thunkResult.then(selectFromState)
            : skippedSynchronously && !runningQuery
            ? // a query has been skipped due to a condition and we do not have any currently running query
              // -> we want to resolve it immediately with the current data
              Promise.resolve(stateAfter)
            : // query just started or one is already in flight
              // -> wait for the running query, then resolve with data from after that
              Promise.all([runningQuery, thunkResult]).then(selectFromState), ...)

[dev-splin]

Restarting the project will not reproduce.
Thank you for your kind reply!