Code Splitting challenges with auto-generated action types

[EvHaus]

I'm currently working through some challenges with large bundle sizes and the impact Redux code has on bundle size in our case is quite large. I'm familiar with the docs around code splitting but I have a more specific question around the recommended best practices of using auto-generated action types.

When using Redux Toolkit, when you define an action creator, you get these nice action types that get auto generated for you which you can pass to a reducer:

// FILE: /actions/counter.js

export const increment = createAction('counter/increment')

console.log(increment)
// => 'counter/increment'

This makes it handy for passing the action directly to the builder in createReducer():

// FILE: /reducers/counter.js

import {increment} from '../actions/counter';

const counterReducer = createReducer(0, (builder) => {
  builder.addCase(increment, (state, action) => state + action.payload)
})

Note how /reducers/counter.js is importing the action from /actions/counter.js in this case so that it can pass the auto generated action type to .addCase(). This all works great, but in a more realworld scenario you will have a lot of actions and (more important) complex actions which may require large third-party libraries.

Reducers need to get loaded on initial page load, but actions only need to be loaded when invoked by users. But since reducer files import action files, they import all the dependencies of those action files. So in the real world it might look more like this:

// FILE: /actions/counter.js

// Note how we might be importing some large files here
import someGiantApiLibrary from '../apis/someGiantApiLibrary';

export const increment = createAsyncThunk(
  'counter/increment',
  async (name) => {
    const response = await someGiantApiLibrary(`https://pokeapi.co/api/v2/pokemon/${name}`)
    return await response.json()
  }
);

So then because /reducers/counter.js imports that action file, and the reducers need to be loaded on initial app load, the initial app bundle can get really huge.

The most obvious solution to this seems to be to NOT use the auto-generated action types and remove the action file import from the reducer, ie:

// FILE: /reducers/counter.js

const counterReducer = createReducer(0, (builder) => {
  // Just use the action type string here and no imports.
  builder.addCase('counter/increment', (state, action) => state + action.payload)
})

But this is against the best practices defined here and also means the lose the type safety in the reducer. Which is a total bummer.

Any advice on how to preserve the benefits of auto-generated action types without bloating the initial JS bundle?

[markerikson]

It's always tradeoffs.

The action creators do generate predictable action names. Worst case, you decide that the bundle size aspect is too much of an issue, and hand-write the action type strings and manually annotate the TS types yourself.

That said, I'm curious - just how big are the action-related files that you're pulling in? How much are they actually adding to the bundle size in practice?

Also: how many of those async thunks could actually be replaced by use of RTK Query?

[EvHaus]

just how big are the action-related files that you're pulling in

It's a cascading sort of thing. No one is that big on its own, but there's like 40 in our app. And some of them import a bunch of other files that are pretty large. And those import a few others, etc... It would require some untangling of spaghetti and I'm thinking of cutting it off at the root instead (ie. just replacing the action types with strings).

How much are they actually adding to the bundle size in practice?

In our case, loading just the reducers takes ~120ms. Tough to say exactly how much it adds to the bundle size as we're doing a lot of code splitting already.

Trying to determine what is the better path forward -- lazy loading reducers vs. removing action imports from reducers and using plain strings for action types. Both should have a big impact but the later is likely less work.

Thanks as always for your super speedy response.

[EskiMojo14]

also reducers can be lazy loaded, which is what our combineSlices util is for

reduxjs/redux-toolkit#4064
#4665