4 ms·

Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you b

Hi, I'm a Redux maintainer. If you've got any specific concerns I can help with, I'd be happy to try to offer advice. Out of curiosity, what issues have you been seeing with using thunks? I'd specifically encourage you to check out our new official Redux Toolkit package. It includes utilities to simplify several common Redux use cases, including store setup, defining reducers, immutable update logic, and even creating entire "slices" of state at once: https://redux-toolkit.js.org https://redux-toolkit.js.org You might also want to look at the new "Style Guide" page we've added to the docs, which lists our recommended patterns and practices for using Redux: https://redux.js.org/style-guide/style-guide https://redux.js.org/style-guide/style-guide

dudus 7y ago
I'm still new to redux and I'm learning using angular ngrx. I realize ngrx is just inspired by redux. What's the team relationship? Are these the same maintainers, is there a ngrx toolkit?
- acemarke 7y ago
  No, the Redux and NgRX teams are completely separate. We've occasionally chatted briefly online, but that's it.
TimMurnaghan 7y ago
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.
isubasinghe 7y ago
Hey thanks for reaching out, that's very nice of you :), I have no specific concerns atm but will reach out I do need help. Issues with thunks are maybe(?) due to our implementation again, but we have way too many dispatches being called (100s of lines of dispatch calls for one action sometimes). It becomes quite hard to trace what happens when a certain business logic is executed because of this. For example, say we have an action to delete a domain level entity, lets say this is a book, well books can have paragraphs, paragraphs can have sentences and sentences can have words (normalized state, terrible example I know, but all I could think of atm). Well the action to delete a book, has dispatches to delete all children entities as well. These dispatches actually may have other dispatches as well for ui stuff etc. Doing redux this way really didn't scale well for us, but I suppose we have very very unique, complex business logic compared to other projects. The style guide looks excellent, I think this would have made the codebase easier to follow. I will defs be following this for my personal projects. Thanks
- acemarke 7y ago
  Yeah, it sounds like the issue here is that you are trying to dispatch a single action per tiny state update. This is why we now recommend "modeling actions as 'events' instead of 'setters'". See the links I posted in this sibling comment for suggestions on how to change your conceptual approach: https://news.ycombinator.com/item?id=21853160 https://news.ycombinator.com/item?id=21853160 Also, note that our new Redux Toolkit package will at least help simplify your existing logic, and you can begin migrating to it incrementally: https://redux-toolkit.js.org https://redux-toolkit.js.org

dudus 7y ago

I'm still new to redux and I'm learning using angular ngrx. I realize ngrx is just inspired by redux. What's the team relationship? Are these the same maintainers, is there a ngrx toolkit?

acemarke 7y ago
No, the Redux and NgRX teams are completely separate. We've occasionally chatted briefly online, but that's it.

TimMurnaghan 7y ago

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.

isubasinghe 7y ago

Hey thanks for reaching out, that's very nice of you :), I have no specific concerns atm but will reach out I do need help. Issues with thunks are maybe(?) due to our implementation again, but we have way too many dispatches being called (100s of lines of dispatch calls for one action sometimes). It becomes quite hard to trace what happens when a certain business logic is executed because of this. For example, say we have an action to delete a domain level entity, lets say this is a book, well books can have paragraphs, paragraphs can have sentences and sentences can have words (normalized state, terrible example I know, but all I could think of atm). Well the action to delete a book, has dispatches to delete all children entities as well. These dispatches actually may have other dispatches as well for ui stuff etc. Doing redux this way really didn't scale well for us, but I suppose we have very very unique, complex business logic compared to other projects. The style guide looks excellent, I think this would have made the codebase easier to follow. I will defs be following this for my personal projects. Thanks

acemarke 7y ago
Yeah, it sounds like the issue here is that you are trying to dispatch a single action per tiny state update. This is why we now recommend "modeling actions as 'events' instead of 'setters'". See the links I posted in this sibling comment for suggestions on how to change your conceptual approach: https://news.ycombinator.com/item?id=21853160 https://news.ycombinator.com/item?id=21853160 Also, note that our new Redux Toolkit package will at least help simplify your existing logic, and you can begin migrating to it incrementally: https://redux-toolkit.js.org https://redux-toolkit.js.org