redux-zero / redux-zero

A lightweight state container based on Redux

Home Page:https://matheusml1.gitbooks.io/redux-zero-docs/content/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Managing large stores

repomaa opened this issue · comments

Hey, I was wondering if there is a go-to solution how to manage large stores. In redux this would've been done by combining reducers. the combineActions function is useful but it keeps the actions at top level and doesn't allow for splitting the global application state into smaller chunks. If this is already possible, maybe adding it to the readme would be a good idea.

Hi @jreinert

What do you mean exactly with this? Can you provide some code examples on what would that be?

I think the idea is that an action would only have access to one slice of the state as opposed to the entire state. In redux this is accomplished by composing multiple reducers where each reducer is only responsible for one slice (top-level key in state object) and can only access its own slice of the state when reducing.

import { combineReducers } from 'redux';
const user = (state = {}, action) => action.payload;
const todos = (state = [], action) => action.payload;

const rootReducer = combineReducers({
  user,
  todos,
});

the user reducer cannot access todos and vice-versa.

The reason why this might be favorable is to ensure that one action does one thing and one thing only. Theoretically if one action can access/modify the entire state, I could create an action that modifies everything which could have unintended side-effects and arguably be less maintainable over time.

https://redux.js.org/recipes/structuringreducers/splittingreducerlogic

By forcing reducers to only be able to modify one slice of the state, we force developers to think about the problem they are trying to solve before overwriting majors parts of the application with one action/reducer.

exactly @neurosnap. I couldn't have explained it better 👍
the great thing about this pattern is that it doesn't have to stop at top level. So if you at some point realize your todos reducer is doing too much you can easily further split it into "sub reducers". It's a great refactoring tool.

Thanks for the explanation @neurosnap

Answering your question @jreinert, right now we don't have a 'scoped state', but I would be open to discuss this.

I'm closing this for now, but if you have more to add to this discussion, please feel free to

still open to discussing this? I think without the scope state, things can get messed up very easily over time