Redux Eggs: alternative for Redux Dynamic Modules

[fostyfost]

Most likely redux-dynamic-modules is no longer supported.
I could not find any other similar library.
Therefore, I created a library that makes it easy to dynamically add reducers and middleware to Redux store.
https://github.com/fostyfost/redux-eggs
I'm actively developing this library and it already has support for React (React Strict Mode is also supported), Next.js, Redux Toolkit, Redux and Redux-Saga.
You can also extend the functionality through the built-in extension mechanism.
It has a very small size and zero-dependencies and offers similar API to redux-dynamic-modules.
I would be glad if Redux community pays attention to this library.

[phryneas]

Hm, looking at the Redux Toolkit module, I have some serious concerns about the TypeScript types though - as using that approach essentially erases all information about middleware from the result, since the resulting WithEggExt will pretty much always fall back to being a WithEggExt<DefaultEnhancedStore> - while a RTK Store is something with very complex typings.

Could this be implemented as a wrapper or store enhancer and thus have less influence on the types that way?

As for usage, I can't really comment on that since I never had the need of splitting up Redux logic.

[markerikson]

@fostyfost Yeah, I skimmed through the redux-eggs source and examples for a bit. My initial thoughts:

• I see where you're going with this in general, and I definitely agree that redux-dynamic-modules seems to be mostly dead at this point
• I think it's great that you've tried to cover so many different use cases. At the same time, some pieces feel a bit over-engineered at first glance.
• tbh the term "egg" just does not sound appealing to me. (yes, I know we're the library that already has the term "ducks" in widespread use :) ) I would personally just go with "Module" or something.
• As Lenz said above, the fact that this requires its own separate store setup function seems like it makes things more complicated. If this could be written as a standard Redux store enhancer, that would make it easier to slot into something like configureStore, although that might not help with middleware setup (?)
• When you say "React Strict Mode is supported", what exactly does that involve?

[fostyfost]

@phryneas @markerikson thank you for your comments.

Could this be implemented as a wrapper or store enhancer and thus have less influence on the types that way?

I don't think so, because the whole sense of this library will be lost. Packages like @redux-eggs/redux and @redux-eggs/redux-toolkit create a repository for you with all the necessary set of extensions for dynamically connecting middleware, reducers, etc.
Users can easily create a store with the correct types by specifying them at the time of creation.

const createAppStore = () => {
  return createStore<DefaultEnhancedStore & { test: number }>({
    // extensions: [...],
    // combiner,
    // ...
  })
}

export type AppStore = ReturnType<typeof createAppStore>

I'm still looking for a good solution to automatically save typing.

tbh the term "egg" just does not sound appealing to me. (yes, I know we're the library that already has the term "ducks" in widespread use :) ) I would personally just go with "Module" or something.

You're right. But I did not want to operate with the concept of "module", because I primarily associate it with ES-modules.
The slogan of my library is "Manipulate your store like an egg tray". It means you can add to and remove eggs (modules) from the egg tray (store) whenever you want.

As Lenz said above, the fact that this requires its own separate store setup function seems like it makes things more complicated. If this could be written as a standard Redux store enhancer, that would make it easier to slot into something like configureStore, although that might not help with middleware setup

I will be glad if you have any advice on how it can be organized =)

When you say "React Strict Mode is supported", what exactly does that involve?

In Redux Dynamic Modules, in order for modules to be correctly removed in React Strict Mode, you need to explicitly pass corresponding prop, which changes the behavior of component even in production mode. In my case, everything works without need to change behavior of component or pass special props to it.

[markerikson]

@fostyfost that's kind of my point. A Redux store enhancer can add any additional fields that it wants to the final store instance:

return {
  ...originalStore,
  dispatch: overriddenDispatch,
  getMeaningOfLife: () => 42
}

So, the logic should be doable as a store enhancer, I'm just not entirely sure how they affect things at the type level.

I get what you're trying to say visually with the "egg tray" thing, but I myself just really don't find that to be a helpful name/metaphor.

[Saoirse-Derry]

@fostyfost Interesting library and thank you.
I'm currently looking at adding Redux Eggs in a micro frontend architecture. I already have a few redux toolkit apps (using createSlice and createEntityAdapter) that use RTK Query a lot but am finding the pattern for doing this a bit hard to understand, which perhaps reflects the eggsperiences (sorry) above.

For example, here's my current createStore function for adding the RTK api middleware(s):

export const createStore = (
  options?: ConfigureStoreOptions['preloadedState'] | undefined
) =>
  configureStore({
    reducer: rootReducer,
    middleware: (getDefaultMiddleware) =>
      getDefaultMiddleware().concat(emptySplitApi.middleware),
    ...options,
  });

The redux eggs next/redux toolkit documentation means I must produce something like the below. Question is how to include api definitions with your eggs stuff? Is there an example for this scenario?

  const combinedReducer = combineReducers(reducersMap)

  return (state: any = {}, action: AnyAction) => {
    if (action.type === StoreActionType.HYDRATE && action.payload) {
      return combinedReducer({ ...state, ...action.payload }, action)
    }

    return combinedReducer(state, action)
  }
}
const createAppStore = () => {
  return createStore({
    extensions: [getApiExtensions()],
    combiner,
  })
}

[fostyfost]

@Saoirse-Derry hello! Thank you for choosing Redux Eggs.

If you need a middleware that is initialized along with Redux store, then I recommend using the following approach:

import { HYDRATE_ACTION_TYPE } from '@redux-eggs/next'
import { createStore } from '@redux-eggs/redux-toolkit'
import type { AnyAction, ReducersMapObject } from '@reduxjs/toolkit'
import { combineReducers } from '@reduxjs/toolkit'

import { emptySplitApi } from '@/api'

const getApiExtension = (): Extension => {
  return {
    middlewares: [emptySplitApi.middleware]
  }
}

const combiner = (reducersMap: ReducersMapObject) => {
  const combinedReducer = combineReducers(reducersMap)

  return (state: any = {}, action: AnyAction) => {
    return combinedReducer(action.type === HYDRATE_ACTION_TYPE ? { ...state, ...action.payload } : state, action)
  }
}

export const createAppStore = () => {
  return createStore({
    extensions: [getApiExtension()],
    combiner,
  })
}

If you need a middleware that connects to Redux store when a specific egg is added, you can try the following approach:

import type { Egg } from '@redux-eggs/core'

import { emptySplitApi } from '@/api'
import type { AppStore } from '@/store'

export const getSplitApiEgg = (): Egg<AppStore> => {
  return {
    id: 'split-api',
    middlewares: [
      emptySplitApi.middleware,
    ],
    // other stuff
  }
}

[Saoirse-Derry]

@fostyfost thanks for getting back. I'll have a look asap and let you know how we get on.

[fostyfost]

@Saoirse-Derry any news?

[Saoirse-Derry]

Still playing around with it and so far all good for splitting and reducing initial payloads. Still need to review it with Module Federation....