5 ms·

Thunks can be an anti-pattern. They encourage multiple dispatches to redux which can leave people designing "set data" style reducers rather than more meaningfu

Thunks can be an anti-pattern. They encourage multiple dispatches to redux which can leave people designing "set data" style reducers rather than more meaningful ones. Parent comment suggests sagas and that's much better. An action in a component dispatches one thing and the saga can co-ordinate all of the logic.

ng12 7y ago
> "set data" style reducers I've heard this before but don't really understand it. Most of my reducers are storing and maybe updating data loaded from the server. What's wrong with this pattern?
- acemarke 7y ago
  Our new "Style Guide" docs page gives a recommendation to "model actions as 'events', not 'setters' [0], and there were two recent talks on this topic that go into a lot more detail [1] [2]. [0] https://redux.js.org/style-guide/style-guide/#model-actions-as-events-not-setters https://redux.js.org/style-guide/style-guide/#model-actions-... [1] https://github.com/dmmulroy/talks/blob/master/event-driven-redux/slides.pdf https://github.com/dmmulroy/talks/blob/master/event-driven-r... [2] https://youtu.be/K6OlKeQRCzo?t=2626 https://youtu.be/K6OlKeQRCzo?t=2626 / https://rangle.slides.com/yazanalaboudi/deck#/ https://rangle.slides.com/yazanalaboudi/deck#/
  - Izkata 7y ago
    > "model actions as 'events', not 'setters' I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
    - acemarke 7y ago
      That's actually kind of the point. When you mentally model an action as a "setter", like `SET_PIZZAS_ORDERED`, the reducer usually has almost no logic and just blindly accepts whatever value was in the action. The work of calculating the value was done before the action was dispatched. If you model actions conceptually as "events", the corollary is that the work of calculating the new state typically ends up in the reducer.
      - Izkata 7y ago
        Again no, these are modeled as events around a thunk: dispatch START_SEARCH, -> ajax -> any necessary complex logic -> dispatch RESULTS_RECEIVED or QUERY_FAILED. Multiple reducers listen to the same events, acting as simple setters.

ng12 7y ago

> "set data" style reducers I've heard this before but don't really understand it. Most of my reducers are storing and maybe updating data loaded from the server. What's wrong with this pattern?

acemarke 7y ago
Our new "Style Guide" docs page gives a recommendation to "model actions as 'events', not 'setters' [0], and there were two recent talks on this topic that go into a lot more detail [1] [2]. [0] https://redux.js.org/style-guide/style-guide/#model-actions-as-events-not-setters https://redux.js.org/style-guide/style-guide/#model-actions-... [1] https://github.com/dmmulroy/talks/blob/master/event-driven-redux/slides.pdf https://github.com/dmmulroy/talks/blob/master/event-driven-r... [2] https://youtu.be/K6OlKeQRCzo?t=2626 https://youtu.be/K6OlKeQRCzo?t=2626 / https://rangle.slides.com/yazanalaboudi/deck#/ https://rangle.slides.com/yazanalaboudi/deck#/
- Izkata 7y ago
  > "model actions as 'events', not 'setters' I don't think actions are what they're talking about, but reducers as setters vs reducers with more complex logic. I stumbled against the same thing last week, and rather than duplicating the logic in two reducers I settled on putting the logic in the action and turning both reducers into simple setters.
  - acemarke 7y ago
    That's actually kind of the point. When you mentally model an action as a "setter", like `SET_PIZZAS_ORDERED`, the reducer usually has almost no logic and just blindly accepts whatever value was in the action. The work of calculating the value was done before the action was dispatched. If you model actions conceptually as "events", the corollary is that the work of calculating the new state typically ends up in the reducer.
    - Izkata 7y ago
      Again no, these are modeled as events around a thunk: dispatch START_SEARCH, -> ajax -> any necessary complex logic -> dispatch RESULTS_RECEIVED or QUERY_FAILED. Multiple reducers listen to the same events, acting as simple setters.