reduxjs / redux

A JS library for predictable global state management
https://redux.js.org
MIT License
60.88k stars 15.27k forks source link

Is it possible to add reducers after the store is already initialized? #1249

Closed gitnik closed 8 years ago

gitnik commented 8 years ago

I am currently using redux trough ngRedux in an angular application. Instead of having the reducers in some reducers directory at the top level of the app, I would prefer to have them in their respective components. This means they would have to add themselves to the store. Is this somehow achievable?

simplesmiler commented 8 years ago

@gitnik reducer hierarchy is not necessarily mapped 1:1 to the view hierarchy.

Regarding reducers for smart components. Redux does not care where the files are. You can have your reducer code placed alongside the rest of the smart component code, and import such reducers into the root reducer.

Regarding reducers for dumb components. I believe the best approach is to write a higher order reducer per such component, use them to produce "instance reducers" and compose those into smart component reducers. Another approach is to have a reducer that keeps track of list of instances of the dumb component.

Hope this helps.


Reference: Smart and Dumb Components

gitnik commented 8 years ago

You can have your reducer code placed alongside the rest of the smart component code, and import such reducers into the root reducer.

That's exactly what I'm trying to avoid because then I will end up with import statements like this: import fooReducer from 'modules/form/sections/quality/fooReducer'

tracker1 commented 8 years ago

You could rollup your reducers per component, and export a getReducers method that you can test for... it would take some manual curation and require you to put those methods at each stage...

import {getReducers} from '../components';

from there, components/index.js could simply combine the reducers for it's children, and so on...

gaearon commented 8 years ago

That's exactly what I'm trying to avoid because then I will end up with import statements like this: import fooReducer from 'modules/form/sections/quality/fooReducer'

What is the problem with this statement? It makes the dependency explicit. You can even put reducers in the same files as your components, and have parent components export their parent reducers, up to the root component. Then it's not really different from how you import child components.

If you really feel you must add them dynamically see this SO question. But I wouldn't recommend doing this unless you're actually using code splitting, as this complicates the simple ideas of Redux.

gitnik commented 8 years ago

ok, thanks for your input everyone :+1: guess I'm going with the long import statements for now

gaearon commented 8 years ago

Why should they be long? If you use relative paths it's all about how you group files by feature.

zerobytes commented 6 years ago

What is the problem with this statement? It makes the dependency explicit.

It's not a dependency until you need it. Dynamic = Independent. Currently if i have a big application and a Person store i would have to import lots of reducers and they would be processed every time i need something really specific. Adding and removing reducers would be the most professional way of working. Currently redux does not apply to big softwares

markerikson commented 6 years ago

@zerobytes : I'm not sure why you say that. FWIW, there's plenty of examples of dynamically adding reducers at runtime (see the articles listed here ), and there's also several existing libraries to help automate that process.