18

I've been using @connect annotation for some time and decide to switch to mapStateToProps and mapDispatchToProps.

I can mapStateToProps to map store to component's props fine but wondering what's the point of mapDispatchToProps when I can just call this.props.dispatch( xxx ) anywhere.

I also see some react repos and they also do not use mapDispatchToProps

Sorry if it sounds like a beginner question.

Pongsakorn Semsuwan
  • 367
  • 2
  • 11

1 Answers1

13

Yes, you can certainly use props.dispatch() directly in a component. However, that component now "knows" that is part of a Redux application, because it's explicitly trying to "dispatch" things.

On the other hand, if you consistently use action creator functions, now the component is just calling things like this.props.doSomeThing(). It doesn't actually "know" that it's in a Redux app, and is more reusable as a result.

I just answered a similar question at When would bindActionCreators be used in react/redux? , and wrote a longer blog post on the topic at Idiomatic Redux: Why use action creators?.

Community
  • 1
  • 1
markerikson
  • 63,178
  • 10
  • 141
  • 157
  • 1
    This answer would make more sense to me if the file itself wasn't exporting a connected version of the component. The pattern I've mostly seen is a file declaring a component and exporting a connected version of it. Is this not the predominant usage? – aaaaaa Sep 28 '17 at 14:00
  • Not sure I understand your question. If you `connect()` without passing in a `mapDispatch` function or object of action creators as the second argument, your component will be given `this.props.dispatch`. – markerikson Sep 28 '17 at 15:48
  • I'm responding to your comment "the component now 'knows' it is part of a redux application". If you're connecting the component in the same file the component is declared in, then I don't see why using `mapDispatchToProps` is useful. Just seems like more redux boilerplate. – aaaaaa Sep 28 '17 at 15:53
  • 6
    You should feel free to follow whichever approach works better for you. But, as an example: perhaps you have a component that needs to be connected to Redux in one place, and used as the child of a non-connected component in another place. If the component directly dispatches actions itself, then it'll be harder to reuse it. As always, the amount of abstraction you use with Redux is entirely up to you. I find action creators to be a reasonable level of abstraction, but your situation may be different. – markerikson Sep 28 '17 at 15:56
  • Yeah - what you just described is what I meant. The reason I searched this is I kept seeing examples of single components being declared, connected, and exported. You obviously understand this though, so I appreciate your response. And I appreciate all the work you've put into the open source libraries - it's humbling. – aaaaaa Sep 28 '17 at 16:03
  • 1
    To maybe answer your question a bit better: yes, I do find that most "plain" components are only connected and used in one place. Using `dispatch()` inside them doesn't break things or make them completely un-testable. However, I think that keeping the "plain" components unaware of Redux is a good pattern and principle to follow. The other aspect is that perhaps the process of dispatching that action may need to be reused in other places as well, not just this one component, and action creators encapsulate that work. – markerikson Sep 28 '17 at 16:51
  • I understand habitualizing a broader pattern such as that can have benefits. I tend toward a minimally readable code to represent the problem at hand. It prevents the question "but why?" when looking at a new code base that follows a contextually unnecessary pattern. – aaaaaa Sep 28 '17 at 18:09