You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My team has used this library on a couple of small projects and really loved it but now we have started using it on a bigger project and the issue is that the size of the reducerMap passed to handleActions can get to be unwieldy.
My first idea was to split the actions into separate files calling handleActions with categories of reducers and their related defaultState, and then use reduceReducers to string them together. The problem is that the first handleActions will apply its defaultState and then the subsequent ones will drop their defaultState because there is a state already defined. For this usage it would be ideal if they checked the individual keys of the defaultState and applied them as needed.
There are multiple workarounds, including writing our own version of handleActions or merging the reducerMaps and defaultState into a single call of handleActions. However, I thought I would raise the issue to see what you think and if it makes sense for the library's own version of handleActions to have a composable defaultState. If so I could put together a PR for you.
Edit: Just thought of another solution. Using combineReducers from redux rather than reduceReducers should allow each slice to have its own defaultState. This seems like a pretty good approach, except that a "misc" slice of the store is an inevitable wart.
The text was updated successfully, but these errors were encountered:
My team has used this library on a couple of small projects and really loved it but now we have started using it on a bigger project and the issue is that the size of the
reducerMap
passed tohandleActions
can get to be unwieldy.My first idea was to split the actions into separate files calling
handleActions
with categories of reducers and their relateddefaultState
, and then usereduceReducers
to string them together. The problem is that the firsthandleActions
will apply its defaultState and then the subsequent ones will drop their defaultState because there is a state already defined. For this usage it would be ideal if they checked the individual keys of the defaultState and applied them as needed.There are multiple workarounds, including writing our own version of
handleActions
or merging the reducerMaps and defaultState into a single call of handleActions. However, I thought I would raise the issue to see what you think and if it makes sense for the library's own version ofhandleActions
to have a composable defaultState. If so I could put together a PR for you.Edit: Just thought of another solution. Using
combineReducers
from redux rather thanreduceReducers
should allow each slice to have its own defaultState. This seems like a pretty good approach, except that a "misc" slice of the store is an inevitable wart.The text was updated successfully, but these errors were encountered: