I've built a lot of apps with React/Redux, both complex and simple ones. At first there were lots of boilerplate code, and lots of kind-of-similar-but-differen

I've built a lot of apps with React/Redux, both complex and simple ones. At first there were lots of boilerplate code, and lots of kind-of-similar-but-different code all around. After each project, I extracted and generalised the helper components/methods/systems to create my own 'framework', and now I have a foundation that eliminates most of the pain points that people experience with react/redux, that's specific to the way I develop software. Thats why I love React and surrounding ecosystem, it allowed me to choose the relevant libraries/solutions that fits my workflow. Here is my thoughts about the points in the article: 1. Reacters load data on mount In my components, I just declare the data that it needs, and the relevant system loads the data and sends it to the component via props. (like Relay) No requests happen in the component directly. When you have only a few components that needs data in your app, fetching it in the component works, but when you have a complex app (I build ERP systems) you need a centralised way to handle data fetching. 2. Reacters register a bunch of event handlers in their components Declarative event-binding works great for me (similar to react-event-listener[0]). Instead of adding the subscribe/cleanup logic to every component, I just declare the events I'm interested in, and just add the relevant handling code to my component. 3. Reacters optimize when to render Using redux and never overwriting the store takes care of this for me. 4. Reacters load data when stuff changes Same as 1., yon can declaratively state what you need, and the relevant system can handle the rest of the logic without changing anything in the component. 5. Reacters worry about when to set state I'm not sure if this is really a problem, especially when you learn how the lifecycle hooks work. 6. Reacters use a lot of Redux boilerplate Redux has a goal to keep things simple, and let users choose the relevant 3rd party solution to your needs. It means that you need to do some work to create a no-boilerplate solution, but in the end it will work flawlessly according to your needs. In my 'framework', I generate the store definitions and action handlers for my database models automatically from SqlAlchemy model definitions, thus eliminating 95% of the boilerplate. I know that there are frameworks out there that eliminates the need to create your own solutions to most of these problems, but I've found out that, when you try to go out of the 'blessed' path, you will be banging your head to the wall more times than you want. With building my own solutions around the react/redux, I'm in control of the things that I care about. When you control the 'magic' part of the stack you use, you have a lot of power in your hands when problems arise. [0]: https://github.com/oliviertassinari/react-event-listener https://github.com/oliviertassinari/react-event-listener