[BigJono]

'implementation' was probably the wrong choice of word there. 'design decisions' is probably better.

I'm not sure we're working with the same definition of 'action creator' here, because redux-thunk completely moves the goal posts. In redux, an action creator is a utility function which takes some parameters and creates an action, returning it. This is rather intuitive. It's purpose is to allow functions that dispatch actions to build their actions using a common interface, with little risk of generating an action in a format the dispatcher is not expecting.

In redux-thunk, an action creator is a function which takes some parameters and executes a bunch of business logic, dispatching actions created by OTHER action creators along the way. It does not create any actions and does not return any actions. It's a misnomer.

The only thing a redux-thunk action creator has in common with an actual action creator is they both implement the dispatch interface. This is not at all intuitive for new developers.

Moreover, it's completely unnecessary. What do you gain by overloading the dispatch function to do two completely unrelated things? Nothing. You could just as easily create a differently named higher order function that passes dispatch and getState into whatever function is passed into it, and it would be functionally identical.

[acemarke]

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

[BigJono]

Anything can dispatch a hard coded action though. By that logic if I elect not to use the common action creator pattern (without thunk, i.e just standard action creators that return an action), does that make my React components action creators?

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.