4 ms·

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 monolith

by BigJono 10y ago

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 10y ago
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 https://en.wikipedia.org/wiki/Thunk [1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...
- BigJono 10y ago
  '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 10y ago
    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-use-action-creators/ http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why... [1] http://stackoverflow.com/questions/35411423/how-to-dispatch-a-redux-action-with-a-timeout/35415559#35415559 http://stackoverflow.com/questions/35411423/how-to-dispatch-... [2] http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34599594#34599594 http://stackoverflow.com/questions/34570758/why-do-we-need-m... [3] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links

by BigJono 10y ago

acemarke 10y ago

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 https://en.wikipedia.org/wiki/Thunk [1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...

BigJono 10y ago
'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 10y ago
  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-use-action-creators/ http://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why... [1] http://stackoverflow.com/questions/35411423/how-to-dispatch-a-redux-action-with-a-timeout/35415559#35415559 http://stackoverflow.com/questions/35411423/how-to-dispatch-... [2] http://stackoverflow.com/questions/34570758/why-do-we-need-middleware-for-async-flow-in-redux/34599594#34599594 http://stackoverflow.com/questions/34570758/why-do-we-need-m... [3] https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links