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.

[bam]

Just found your question because I have similar situation: I want to guarantee the loading of lazy slice before the thunk will be fulfilled...
So I research for your problem too. If I understand you right you call thunk always (so there is no optimization in number of calls). And then you decide what the site to load (with or without slice) depending on the received data. If so seems you can use dynamic import of the slice in thunk, before fulfil it:

export const thunk = createAsyncThunk('typePrefix', async (params)=>{
  try {
    // ...
    const data = await request()
    if(data.success){
      await import('/path/to/slice.js') // <-- Here your slice will be requested and loaded (but you will lose some time for loading)
      return data // <-- Fulfil the thunk
    }
    // ...
  }
  // ...
})

Maybe something is out of my sight, but I tested and it works in my project.

P.s. And I realised it's not a risk for me (and there is no problem at all), because I import selector from slice always before thunk call.

[TimeDropsSB]

As I could understand, you mean initial data is the data from request, but you can read it right inside your thunk after receiving, why do you need a slice for this? I thought you need a slice in the future, don't see the problem to read raw data in thunk instead of selecting it from slice.

I mentioned this in my original opening post. thunkA which bootstraps the app invokes a REST API call. But I don't need something like e.g. a blog page's slice state data on the home page. However, thunkA when fulfilled contains data shared between the two pages but the data on the blog page slice can't be updated while on the home page (and vice-versa) because the slice doesn't exist at that point in time. The part you are missing is that there is an AJAX fetch request needs to be done again so even if you dispatch thunkA again so that the lazy-loaded slice can be dynamically imported, another AJAX call needs to be made which is wasteful. My original opening post specifically questions this part.

I'm not saying dynamic import slice inside the thunk is bad in certain use cases but the subsequent repeated unnecessary AJAX requests is why it's a problem and wouldn't work for my case. For the regular import the slice at the component and dynamically import (suspend) the component matter, the slice will only be injected when the component is ever used due to the dynamic import which achieves the same effect but has arguably better code splitting results.

That said, I didn't realize slices come with a selectors key that guarantees the state is available so I will be trying that more in the future.

[bam]

Have you tried my code in your thunk?
It doesn't call your api one more time. It just guarantees that slice will be ready at the time of data's been dispatched to reducer.

[TimeDropsSB]

What do you mean? const data = await request() is the AJAX call line. The if block after just dynamic loads the slice after but it's strictly for one slice that you know should be loaded. But I mentioned in my comment above describing my scenario that there are multiple slices involved. So dynamically importing just one slice is inadequate.

[bam]

Well, now I see. You have got all the data in your initial request for all possible slices and sites. And want to optimize loading and creating of slices (which is actually a JS object with some "functional" sugar = not so expensive at least). Even if you will (then) use only one site (from your handful) and 90% (e.g.) of data is not needed, you must store it or refetch every time you need it (there is no magic, it's a price for such solution). Seems this storing is more expensive than creating another one slice.
Back to your title question: put RTK allows such feature and you will have active reducer before slice is created, it must store the data somewhere (in a JS object?). If you will never need the slice, data will be stored permanent (actually, though named "temporary until slice is created"). What is the difference with creation of slice at the moment of receiving of the data? Rhetorical question...
But OK, it's your app, your decision whatever you (not me) did it and are responsible for the app's stability and developing!
So you want to request the initial data once for all slices and have to keep it until it will be used. Here I see something like this solution:
Store initial data at closure (initialData const, which you use at slice creation) or even at session storage and then put it in lazy-loaded slice with initialState property with const or function of createSlice().

// lazySlice.js
import store from 'store';
const initialState = ()=>{
  const necessaryData = getStoredData() // get from session, closure etc.
  // if you want to get data from main slice and put in site's one, you have to do it in an 'init' thunk with further cleanup at main... but i didn't test it
  return necessaryData
}

const lazySlice = createSlice({
  name: 'lazy',
  initialState,
  // ...
})

But all such solutions are just putting same thing at another place. I can't figure any performance or other gains. Making a number of closured consts you get an alternative store managed by you. The only reason i saw is your desire to lightweight core slice, again, just managing internal structure — I don't know the boundaries of acceptable modifications you can do in your app and architecture. Also you can create just separate slice with initial data and don't join it with core slice. At the end of the day if you need to store data you have to store it. And seems we are talking longer than implement any of the cases)))))))
Have a good time and a good luck with your project!

[TimeDropsSB]

All good. It's like markerikson said and there isn't quite a solution but I appreciate the thought.

Because of the nature of Redux, importing a slice means you have to import all of the actions that come with it and that leads to file size bloat and high First Load JS if the action files (as well as selectors) aren't properly organized or split. A bit difficult to deal with it but it is what it is.