Closed gitnik closed 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
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'
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...
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.
ok, thanks for your input everyone :+1: guess I'm going with the long import statements for now
Why should they be long? If you use relative paths it's all about how you group files by feature.
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
@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.
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?