Redux-toolkit: ReferenceError: can't access lexical declaration before initialization when using createAsyncThunk with createReducer

[msutkowski]

Hi there!

Fun stuff first... here is a working version of your repro: https://codesandbox.io/s/nifty-morning-5nndm?file=/src/store/index.ts

With a service like this, it's recommended to inject it into the ThunkApiConfig via extraArgument. You can do this by customizing getDefaultMiddleware

As a side note, you'd want to consider adding types for AppDispatch, as well as using a typed selector hook.

[markerikson]

Yeah, the real problem here is directly importing store into your Axios config file, and also import the Axios config into other files.

As a general rule, never import the store instance directly into other files besides the app root/index.

This does bring up the question of how you _can_ get the store instance for use in that interceptor. A couple possibilities:

• Have the interceptor file export a function that accepts store and creates the interceptor, and import and call that in index.js. Alternately, just create the interceptor in the index.
• Have the interceptor file export a setStore() or setupInterceptor() function, and have the index call that and inject the store after creation.

[msutkowski]

I can't believe I forgot to show that as well 🤦 . I updated that CSB I linked with those points - thanks @markerikson

[ghostwriternr]

Thank you so much for the pointers @msutkowski and @markerikson! Importing state to setup Axios was indeed the issue.
I went ahead and removed direct imports of store everywhere except root & index in my project (as well as the repro) and my issue is resolved 🎉

Just in case anyone stumbles onto this issue in the future, here's the gist of changes I needed:
axiosHelper.ts

import axios from "axios";
import { Store } from "@reduxjs/toolkit";

let defaultAxiosInstance = axios.create({
    baseURL: "https://pokeapi.co/api/v2/",
});

const setupInterceptors = (store: Store) => {
    defaultAxiosInstance.interceptors.request.use((config) => {
        // Real application modifies the header based on environment (sandbox/prod) present in Redux state
        if (!store.getState().dummySlice.pokemon) {
            console.log("No pokemon yet");
        }
        return config;
    });
};

export { defaultAxiosInstance, setupInterceptors };

index.tsx

...
import { store } from "./store";
import { setupInterceptors } from "./helper/axiosHelper";

setupInterceptors(store);

ReactDOM.render(
    <Provider store={store}>
        <App />
    </Provider>,
    document.getElementById("root")
);
...

Sidenote: @msutkowski special thanks for re-creating on CSB & pointing me towards typing dispatch & selectors better. I have incorporated those in our codebase as well :grin:

[ghostwriternr]

Hey @markerikson @msutkowski, in the joy of finally seeing my view render again with the above fix after a full day of breaking my head, I missed noticing one of the main reasons why the solution isn't ideal. setupInterceptors is called only at the time initialization, so the interceptors are configured with the default Redux state.

But the main reason why we use state in axiosHelper.ts is so that we can dynamically set our headers based on some state value. To be more specific, the simplest use case we have is where we set a x-env header with value sandbox or prod based on the corresponding environment state set in Redux. We have several axios instances with more state-specific interceptor logic defined and exported from the same axiosHelper.ts file.

If I had to expand on the current proposed solution, I'd have to export a function to update each of these interceptors whenever the corresponding state values change, which becomes very tedious and easy to miss. Similarly, middleware isn't ideal too since I'd then have to set the interceptor based on the action type - which can again lead to errors if new action types aren't added to the list constantly.

I extended the sample project to reflect the issue again as below.

With the setupInterceptors solution, if my initial state is {isEvolved: false, pokemon: undefined}, I get "pikachu" on first render but the interceptor will never update even after I toggle isEvolved.

axiosHelper.ts

import axios from "axios";
import { store } from "../store";

let defaultAxiosInstance = axios.create({
    baseURL: "https://pokeapi.co/api/v2/pokemon",
});

defaultAxiosInstance.interceptors.request.use((config) => {
    // Real application modifies the header based on environment (sandbox/prod) present in Redux state
    const { isEvolved } = store.getState().dummySlice;
    if (isEvolved) {
        config.url = "/raichu";
    } else {
        config.url = "/pikachu";
    }
    return config;
});

export { defaultAxiosInstance };

[markerikson]

@ghostwriternr I'm not sure I exactly understand the issue at this point.

The original problem you described was a cyclical dependency issue. Switching to exporting and calling setupInterceptors fixes that.

I'm not familiar with how Axios interceptors work, but my assumption looking at your example defaultAxiosInstance.interceptors.request.use() sets up something akin to an Express middleware, where the function runs for every API call made.

In that case, the store.getState() call _should_ be getting run for each API call as well, and thus the interceptor is able to make decisions based on the current state at the time of the API call.

Can you clarify what the intended behavior is here, and what you're seeing happen instead? What do you mean by "the interceptor will never update" ?

[msutkowski]

To tack on to ☝️ , I just tested this and it behaves as you're describing your desired outcome, and works as @markerikson explains. The interceptors are run on every request, so the store.getState() will be at it's the latest snapshot on execution. To demo, search for pikachu, click 'Set evolved', search again.

https://codesandbox.io/s/nifty-morning-5nndm?file=/src/helper/axiosHelper.ts

Note: it is broken due to config.url not being valid, but shows it reacting to store changes

[ghostwriternr]

I embarrass myself, you guys are absolutely right. Switching to exporting and calling setupInterceptors does indeed fix the cyclic dependency and also works as I expect it to in my re-opened comment. I let an unrelated bug slip-in while testing the solution and correlated it back to this.

My fundamental understanding of the initialization order + how imports & functions work in Javascript are incorrect and I'll use this exercise as an excuse to go back and read more about these now. Thank you so much being patient enough to reproduce the behaviour and explain it in depth ^ . ^

[markerikson]

You're welcome, and no worries :) Glad this is working for you!