[BigJono]

This is a very good way to go. In my experience, adding a new tool can take a day or two of refactoring in a medium sized project; but removing one can take a week. Removing a bunch because you completely over-engineered the solution and can't maintain it can often take a month, or even get dangerously close to "scrap it and rewrite" territory, which is a complete death sentence for a small company.

Unless I'm working with people I know well, I'll often elect to start off a fresh project with just React and maybe Redux, and build from there. Even if I know full well that we'll need some stuff like thunk and react-router, my preference is to leave them out and let the team run into the problems they solve before we introduce them.

IMO even if just one team member gains a new understanding about why their tools exist and why they're using them, it's worth a bit of refactoring.

[mnutt]

I can see where you're coming from, but I tend to bucket apps I write into either general use case, mostly business-logic apps, or highly specific services. (say, a network proxy or compositor or something) The general use case apps all tend to share a good deal of requirements (multiple pages, authentication, forms, etc) and while it would certainly be possible to pick and choose each component, it's nice to have a shared set of functionality that is well-tested together and that stays the same between multiple projects and teams.

I think adopting something like ember is pretty much the opposite of "can't maintain it" since while I understand how it works internally, I don't actually have to maintain it myself. In my experience I've seen more instances where we ended up ripping out a homegrown library to replace with a community-supported solution than the other way around.

[BigJono]

Oh, absolutely. I wasn't trying to comment on the difference between the monolithic and modular approaches of Ember and React respectively. I think the monolithic approach actually solves the problem I'm describing to some extent, because developers in those ecosystems are forced into using these tools and patterns, which gives people a vested interest in making sure they're actually good before going into the next release and seeing widespread adoption.

redux-thunk is a great example of what I'm talking about. The design pattern prescribed by it is confusing in subtle ways. They're basically overloading the terminology of "action creators" to mean two wildly different things. The main benefit is solid (it provides a way for controllers/business logic functions to access the data store through dependency injection rather than closures, making them easier to test) but the implementation isn't well thought out, the terminology surrounding it is confusing, and it provides rookie developers more ways to shoot themselves in the foot (see getState abuse).

If any of this craziness was proposed as a core part of Angular or Ember there would be enough sane devs speaking out against it and it would be changed. But since in a modular system in React you are free to choose parts as you please, everyone that knows what they're doing just elects not to use stuff like this, until it builds up enough of a cargo cult following that it becomes standard and starts infiltrating your work place, and suddenly you're outnumbered 20 to 1 by people that have just "always done it that way".

[acemarke]

Can you clarify what you mean by "the implementation isn't well thought out"? It's a 10-line function that basically just checks to see if the argument is a function, and if so, executes it.

Thunks _are_ "action creators", in the sense that they are given `dispatch` and allowed to dispatch things. The word "thunk" is a long-standing CS term, per [0].

I addressed the `getState` question in my blog post "Idiomatic Redux: Thoughts on Thunks, Sagas, Abstraction, and Reusability" [1]. As a summary, yes, thunks (and sagas) give devs complete freedom to do what they want, and more "convention-driven" middleware can be useful, but they're also a level of abstraction that's not necessary, and sometimes you _need_ to execute arbitrary logic that doesn't fit a specific pattern like "REQUEST_START/SUCCESS/FAILED".

[0] https://en.wikipedia.org/wiki/Thunk

[1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...

[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.