Support nesting for connect mapDispatchToProps?
See original GitHub issueExample:
connect(() => {...}, {
noteActions: {
create: createNote,
update: updateNote,
...
},
laneActions: {
create: createLane
}
})(Demo);
// at component
this.props.noteActions.create();
This would allow you to namespace actions better. You could even do
connect(() => {...}, {
noteActions,
laneActions
})(Demo);
if you want to be terse and don’t mind connecting each action. This isn’t as maintainable, though.
Issue Analytics
- State:
- Created 8 years ago
- Reactions:2
- Comments:6 (2 by maintainers)
Top Results From Across the Web
Connect | React Redux
Overview. The connect() function connects a React component to a Redux store. It provides its connected component with the pieces of the ...
Read more >react redux connect in nested components - Stack Overflow
When nesting the SubCategoryDropDown in the CategoryTypeDropDown Component only the CategoryDropDown connect() method gets triggered. // This is ...
Read more >How to Nest Smart Components in Redux | Pluralsight
Nesting smart components is a popular design pattern for building ... the connect() method and secure its props using mapStateToProps() .
Read more >A Look at the Redux connect() Function | by Akhil Reddy Mallidi
Redux's connect() function is a Higher-Order Function that takes two functions as parameters (mapStateToProps and mapDispatchToProps), and it also returns a ...
Read more >Why using nested connect(react-redux) components is good?
Now to help parent you can connect a child and let it extract its own props and props for its children. That way...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’d be wary of including too many convenient opinionated defaults. I generally agree namespacing is nice, but there are potential unwanted side effects too (e.g. an export of some unrelated object from
actions.js
that we begin to iterate over because ofimport * as actions
—or a recursive object we get stuck on).The example in API docs actually shows namespacing:
I don’t think it’s too much typing, and the upside is it’s explicit and non-magic. I’d prefer to keep it that way.
I think the way it is right now is perfect.
This of
mapDispatchToProps
as factory.You can do something like this:
You can achieve a cleaner code with currying. That’s the way I try to write all my apps. I try not to create objects out of nowhere. only functions that reduce other objects.
This gives you the advantage of separating reducers.
For example you’d be able to have book reducers and author reducers.
All contained in the same module. Each module would have it’s factories. Or whatever functions that are related to the logic of the reducer.