3 ms·

Async middleware is an anti-pattern. Take care of async stuff in mapDispatchToProps. Actions are ALWAYS action(payload) => { type: action, payload } There's n

Async middleware is an anti-pattern. Take care of async stuff in mapDispatchToProps. Actions are ALWAYS action(payload) => { type: action, payload } There's no reason to call a function everywhere you need a new action. Just define all of them in one place by listing the types. You can easily write a function that looks like createActions(['TODOS/ADD', 'TODOS/DELETE', ... ]}) That returns all your action creators and types in one place. Import them as needed. The above single call function to create a todo action is verbose without achieving any efficiency. It's bad design. Don't get rid of the switch statements at all. Use them. They're clear. If you need to slice things up, just use child reducers in the switch branches. Lookup tables are less performant and don't buy you anything. Sorry to be so harsh but this kind of cargo-cult best practice stuff is how you end up with Javascript that feels like Enterprise Java™ from back in the 00s.

acemarke 7y ago
Yeah, we'll have to disagree here. We officially recommend consistently using action creators [0], and I talked about the reasons to use them in a blog post [1]. Switch statements and lookups are almost completely equivalent (except for fall-through and default case handling) [2], and "performance" is irrelevant here. In this case, use of `createSlice` means that writing the lookup table object generates the resulting action types and action creators for free, which drastically reduces the amount of code you have to write. I am strongly against defining async logic inside of `mapDispatch`. It's similar to writing thunks in the first place (an arbitrary function that has access to `dispatch`), but it's less testable, not reusable, _and_ doesn't have access to `getState`. In fact, you should be using the "object shorthand" form of `mapDispatch` [3] to pass action creators into connected components, like `const mapDispatch = {addTodo, toggleTodo}`. The advice to put async logic in `mapDispatch` also does not help if you're using our new React-Redux hooks API [4], where you just have `const dispatch = useDispatch()`. The Redux Toolkit API is specifically designed to remove as much as possible of that incidental complexity from your Redux code, and move it _away_ from being that "Enterprise Java" feel. [0] https://redux.js.org/style-guide/style-guide#use-action-creators https://redux.js.org/style-guide/style-guide#use-action-crea... [1] https://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why-use-action-creators/ https://blog.isquaredsoftware.com/2016/10/idiomatic-redux-wh... [2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#switch-statements https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [3] https://redux.js.org/style-guide/style-guide#use-the-object-shorthand-form-of-mapdispatch-with-connect https://redux.js.org/style-guide/style-guide#use-the-object-... [4] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks
- weeksie 7y ago
  You misread. I wasn't railing against action creators, I was saying your method of generating them was bad. So yes. We disagree strongly but it's because you are outright wrong in your claims. Putting function calls in mapDispatch does not do anything to their reusability or their testability. They're still functions. You're making taste claims but treating them like they are factual. If you're wondering why my tone is so dismissive it's because yours is so prescriptive. I've worked on a lot of react and redux projects and I know my way around. If you're attempting to reify your development taste into a framework of "best practices" you need to be prepared for criticism. Responding to me with footnoted appeals to authority does nothing for your argument.
  - acemarke 7y ago
    FWIW, I'm the primary Redux maintainer, have written large chunks of the current docs (including the FAQ and the Style Guide), have overseen the development of the last three major versions of React-Redux (including writing v7 from scratch myself), and drove the entire development of Redux Toolkit. So yeah, I guess you could call that an "appeal to authority". The docs content and recommendations are based specifically on the questions I've seen asked, the ways I've seen Redux used, and the concerns I've seen expressed by users. My goal is to simplify how people learn and use Redux, and point them in directions that lead to better codebases. You're always welcome to use other approaches if they work better for you, but there's good reasons for all the patterns we're recommending.
    - weeksie 7y ago
      Exactly why I'm frustrated with you. You're doing more harm than good and you're able to do it because you are an open source maintainer. Redux is (state, action) => state Sure, wiring it up is clunky without a few helper functions and you're right there should be a set of reified best practices. Unfortunately, the ones you are holding up simply do not buy the developer anything and serve to make the js ecosystem even more impenetrable than it already is. I'm only angry because I know that I'll be wading through piles and piles of garbage as a result of this library. This gets to a bigger problem with the javascript ecosystem. Someone writes a useful library (s, a) => s, then a hundred other people decide to create "opinionated" frameworks to manage that library. What you're left with are hundreds of arbitrary practices yanked from inside development organizations. They almost always obscure the thing they're trying to illuminate. Opinionated frameworks are only effective if you get them as a whole package. Rails works because it's every single thing you need for a web app rolled up into one suite of libs. Opinionated Javascript frameworks have been unable to mimic this because the big ones are focused on narrow domains: ui rendering, state management, etc. This creates an explosion of cargo culted opinions-turned-libraries, which are basically what we had in the 00s with all the Java libraries that were design patterened to death. Believe me, there was a lot of citing going on in those discussions too. This library will do more harm than it does good if people buy in.

acemarke 7y ago

Yeah, we'll have to disagree here. We officially recommend consistently using action creators [0], and I talked about the reasons to use them in a blog post [1]. Switch statements and lookups are almost completely equivalent (except for fall-through and default case handling) [2], and "performance" is irrelevant here. In this case, use of `createSlice` means that writing the lookup table object generates the resulting action types and action creators for free, which drastically reduces the amount of code you have to write. I am strongly against defining async logic inside of `mapDispatch`. It's similar to writing thunks in the first place (an arbitrary function that has access to `dispatch`), but it's less testable, not reusable, _and_ doesn't have access to `getState`. In fact, you should be using the "object shorthand" form of `mapDispatch` [3] to pass action creators into connected components, like `const mapDispatch = {addTodo, toggleTodo}`. The advice to put async logic in `mapDispatch` also does not help if you're using our new React-Redux hooks API [4], where you just have `const dispatch = useDispatch()`. The Redux Toolkit API is specifically designed to remove as much as possible of that incidental complexity from your Redux code, and move it _away_ from being that "Enterprise Java" feel. [0] https://redux.js.org/style-guide/style-guide#use-action-creators https://redux.js.org/style-guide/style-guide#use-action-crea... [1] https://blog.isquaredsoftware.com/2016/10/idiomatic-redux-why-use-action-creators/ https://blog.isquaredsoftware.com/2016/10/idiomatic-redux-wh... [2] https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-tao-of-redux-part-2/#switch-statements https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta... [3] https://redux.js.org/style-guide/style-guide#use-the-object-shorthand-form-of-mapdispatch-with-connect https://redux.js.org/style-guide/style-guide#use-the-object-... [4] https://react-redux.js.org/api/hooks https://react-redux.js.org/api/hooks

weeksie 7y ago
You misread. I wasn't railing against action creators, I was saying your method of generating them was bad. So yes. We disagree strongly but it's because you are outright wrong in your claims. Putting function calls in mapDispatch does not do anything to their reusability or their testability. They're still functions. You're making taste claims but treating them like they are factual. If you're wondering why my tone is so dismissive it's because yours is so prescriptive. I've worked on a lot of react and redux projects and I know my way around. If you're attempting to reify your development taste into a framework of "best practices" you need to be prepared for criticism. Responding to me with footnoted appeals to authority does nothing for your argument.
- acemarke 7y ago
  FWIW, I'm the primary Redux maintainer, have written large chunks of the current docs (including the FAQ and the Style Guide), have overseen the development of the last three major versions of React-Redux (including writing v7 from scratch myself), and drove the entire development of Redux Toolkit. So yeah, I guess you could call that an "appeal to authority". The docs content and recommendations are based specifically on the questions I've seen asked, the ways I've seen Redux used, and the concerns I've seen expressed by users. My goal is to simplify how people learn and use Redux, and point them in directions that lead to better codebases. You're always welcome to use other approaches if they work better for you, but there's good reasons for all the patterns we're recommending.
  - weeksie 7y ago
    Exactly why I'm frustrated with you. You're doing more harm than good and you're able to do it because you are an open source maintainer. Redux is (state, action) => state Sure, wiring it up is clunky without a few helper functions and you're right there should be a set of reified best practices. Unfortunately, the ones you are holding up simply do not buy the developer anything and serve to make the js ecosystem even more impenetrable than it already is. I'm only angry because I know that I'll be wading through piles and piles of garbage as a result of this library. This gets to a bigger problem with the javascript ecosystem. Someone writes a useful library (s, a) => s, then a hundred other people decide to create "opinionated" frameworks to manage that library. What you're left with are hundreds of arbitrary practices yanked from inside development organizations. They almost always obscure the thing they're trying to illuminate. Opinionated frameworks are only effective if you get them as a whole package. Rails works because it's every single thing you need for a web app rolled up into one suite of libs. Opinionated Javascript frameworks have been unable to mimic this because the big ones are focused on narrow domains: ui rendering, state management, etc. This creates an explosion of cargo culted opinions-turned-libraries, which are basically what we had in the 00s with all the Java libraries that were design patterened to death. Believe me, there was a lot of citing going on in those discussions too. This library will do more harm than it does good if people buy in.