How do you lazy-load slices where its extraReducers listen to a thunk's payload and the thunk is fulfilled before the slice is injected?

[TimeDropsSB]

I have a thunk, thunkA, which contacts a REST API. I also have a traditional Redux slice with an extraReducers where it responds to the thunkA and its payload when it is fulfilled.

When trying to make this slice lazy-loaded, the slice doesn't exist immediately. So when thunkA is dispatched while this slice is unavailable, the state in this slice cannot be updated; consequently, when the lazy-loaded slice loads, it will just only have the initial state.

Is there a way to resolve this so that the lazy-loaded slice can contain the relevant state updates from the action? Do I just need to dispatch the thunk and make another API call again? Is there a solution without doing another API call?

[markerikson]

In one sense, there isn't a solution here. If that reducer isn't loaded when the fulfilled action is dispatched, then no, it wasn't around to handle the action (aka the "tree falling in a forest and no one's around to hear it" scenario).

If there's some other section of the reducer logic that is also listening for this action and does handle it, you could in theory write logic to grab some value from slice B and dispatch another action when slice A gets loaded. But it's also likely that this was the only slice of state that cared about that action, in which case nothing else saved any values from that action at all.

A rarely used alternative might be to use a special middleware that watches for that action, and only passes it onwards to the store + root reducer if the slice has been loaded. If not, it could hold the action in a queue, and then actually re-dispatch it once the slice is loaded. Some of the packages I have listed at https://github.com/markerikson/redux-ecosystem-links/blob/master/middleware-async.md#timeouts-and-delays might give you some inspiration there.

Out of curiosity, what are the general behavior steps that lead to the thunk being dispatched, and to the slice getting loaded?

[TimeDropsSB]

Out of curiosity, what are the general behavior steps that lead to the thunk being dispatched, and to the slice getting loaded?

We have an app where the same app is used to serve content for a handful of sites that we have. Each site has different content so serving content is done by from fetching config data from an API on initial load which is what the thunk is. Config payload is sent to multiple reducers/slices but some slices are not needed on the initial load hence why we are lazy-loading them. So aside from the thunk itself which is the critical part of updating the state first, no other aspect of these slices is required on initial load.

If there's some other section of the reducer logic that is also listening for this action and does handle it, you could in theory write logic to grab some value from slice B and dispatch another action when slice A gets loaded. But it's also likely that this was the only slice of state that cared about that action, in which case nothing else saved any values from that action at all.

We actually do have this architecture but our primary fear is that this singular slice is bloating itself by becoming the "core slice" to all the other slices which is why it would have been preferable to just simply send down the payload from the original thunk and the slice managing its own state, a.k.a. "slim actions, heavy reducers" model. Not that we can't have this core slice but we really want to decrease our first load JS used and this didn't seem a viable idea for scaling purposes.

I'll take a look at your link just in case there are any new ideas I'm missing but I think I got a way to move forward for the time being. I appreciate the insight.

[markerikson]

This also may not answer your question directly, but: have you looked into using RTK Query to do the fetching and caching instead of writing thunks yourself?

[TimeDropsSB]

We are actually in the midst of trying to set RTK Query up but we have a roadblocker on setting it up and making it work for us so we're trying to get that sorted out.