3 ms·

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 a

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

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.