[TimMurnaghan]

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]

> "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]

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

[1] https://github.com/dmmulroy/talks/blob/master/event-driven-r...

[2] https://youtu.be/K6OlKeQRCzo?t=2626 / https://rangle.slides.com/yazanalaboudi/deck#/

[Izkata]

> "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]

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]

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.