| Eh... a thunk could absolutely call `dispatch({type : "SOME_ACTION"})` rather than doing `dispatch(anotherActionCreator())`. It also allows consistent use of binding to `dispatch` in conjunction with `connect`, per my post "Idiomatic Redux: Why Use Action Creators?" [0]. The canonical explanation for why middleware is the place for async logic is in a couple of SO posts by Dan Abramov [1] [2]. Quote: > So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators. In other words, a component simply calls `props.someFunction(someData)`, and it doesn't care where the function came from, or exactly what it does. It could be a plain action creator, a thunk, or a spy in a test. If there's asyncness that needs to happen, that can be handled outside the component in a reusable fashion. There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises. I understand your points, but very much disagree with your conclusions. (In a slight appeal to authority: I'm one of the current maintainers of Redux, and keep a list of links to React+Redux resources [3].) [0] http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why... [1] http://stackoverflow.com/questions/35411423/how-to-dispatch-... [2] http://stackoverflow.com/questions/34570758/why-do-we-need-m... [3] https://github.com/markerikson/react-redux-links |
What if I put a 'createFoo' function in my component that creates a foo action, and call dispatch(this.createFoo()) from elsewhere in the component? Now what is the action creator? Is it the function, or is it the component? Because going by the terminology in the redux docs it'd be the function, and going by the terminology in the redux-thunk docs, it'd be the component.
That's the ambiguity I'm talking about. I'm sure Dan Abramov has a consistent logical model in his head for reasoning about this, but it hasn't been properly divulged to the community. I could find you at least 5 devs I've met IRL that think it's the function, 5 that think it's the component, and 5 that think it's both.
> So the benefit of using middleware like Redux Thunk or Redux Promise is that components aren’t aware of how action creators are implemented, and whether they care about Redux state, whether they are synchronous or asynchronous, and whether or not they call other action creators.
No, the mapDispatchToProps pattern is what provides this layer of abstraction. If a component calls 'this.props.doFoo', why does it care whether doFoo starts an asynchronous process by calling an overloaded 'dispatch' function that could mean one of two completely different things, or using the same thunk pattern with a less confusing name?
I'm not disagreeing with anything you're saying in this post. What I'm saying is that the choice of API for redux-thunk is ambiguous and confusing, not that the pattern itself is bad (in-fact I think it's very good).
> There's also precedent for overloading `dispatch` and "teaching" it to understand parameters other than plain action objects, such as promises.
There's precedent for murdering people too, it happens a hundred times a day across the country. Doesn't make it a good idea.