To improve modularity Erik Rasmussen came up with Ducks: Redux Reducer Bundles. You can read the proposal here. A quick view at the rules:
A module...
- MUST
export defaulta function calledreducer()- MUST
exportits action creators as functions- MUST have action types in the form
npm-module-or-app/reducer/ACTION_TYPE- MAY export its action types as
UPPER_SNAKE_CASE, if an external reducer needs to listen for them, or if it is a published reusable libraryThese same guidelines are recommended for
{actionType, action, reducer}bundles that are shared as reusable Redux libraries.
What do you think of Redux Ducks? Would you use them yourself?
I' use with 'normalizr'. This was really helpful. Especially more peaceful when I implement asynchronous logic.
I've been using this style of organizing my Redux code ever since I started using React about a year ago, so I don't have a perspective from both sides but it has treated me very well so far. I work for an agency, our projects are typically only a few months long so maybe I haven't run across the issues that come with a massive application using this approach. I say go for it and split things up if they get too overwhelming.
It is a good approach. I haven't got a chance to use it in a real project.
But, when you use it in a real-world project, these module files may become huge which will be a pain. Then, you may have to refactor it into smaller modules.
But, it also has its advantages. With the normal multi-folder approach, there is an overhead of switching between multiple actions and reducers files. Usually, I define the constants in the actions file itself. I also got pretty comfortable with this approach and don't see a real problem with this approach.
I will try to use ducks approach in a future project. Maybe after that, my opinion may change.
Maybe? It depends on your teams' requirements and how the project will be developed over time. For instance, if many small, rapidly-changing components will be added over time this kind of organization might be beneficial to keep git logs simple and readable. On the other hand, if you have fewer but larger components that, say, heavily depend on each other and/or mandate heavy use of async data fetching or side-effects (redux-saga) then this approach might lend itself to fragmentation and many implicit inter-dependencies that would be difficult to track down.
I'll have to think about this more...
I'm still trying to wrap my head around Redux itself. But generally, I think simplification is always a good thing and modularizing this whole action, action-creator, reducer stuff into easily shareable components (pardon the pun) seems like a worthwhile goal.
Standardization is always welcome, especially when the sheer number of conventions are starting to introduce difficult to understand complexity. To me, Redux is such a case. It is hard to convince new developers of the benefit versus the massive learning curve, so this proposal seems like it could help us out here.
Thanigainathan
Program and develop
This is very good proposal and I would definitely agree with that. In a large enterprise project this will be very helpful to avoid confusions and bring modularity.