12 Things NOT To Do When Building React Apps With Redux

jsmanifest on June 09, 2019

Find me on medium. When you're building out a react application, small projects can often be a little more flexible than large projects when it co... [Read Full]
markdown guide

Great article, I agree on every point!

Could you explain more in using accessor functions and what by your opinion is the upside of using them. Is it only in terms of the code structure and avoiding mapStateToProps or is there another benefit that you encountered.

I believe that first example of the arrow function is the accessor function vs the two following examples of using connect, or maybe I got it wrong? It would be great if you could expand on the example and part with accessor functions to make it clear.



In addition to tests I'd also recommend TrackJS, because it catches errors encountered in the wild.

Another thing that I've noticed people to do is to rename a thing, super minimal example:

function Component1({ currency }) {
    return <Component2 money={currency} />

function Component2({ money }) {
    return <Component3 price={money} />

I think the worst I've had to refactor had three or four different names, while not being the only thing changing it's name as data was passed on.

A third point I've noticed in larger apps is that people seem to develop their own solution each time they can't find something using keywords that pop into their mind. This is one of the reasons naming is important to spend time on. However this is also a communication issue.


Those points are right on! Miscommunication should have made it into this list. Miscommunication causes duplicate component implementations because it wasn't visible to the developer at the time. After the issue occurs sometimes we won't have enough time to merge them together because we're being pressured to finish another thing within the end of the day. This causes two separate implementations that practically do the same thing except a tiny change somewhere, like a different named prop for example.

Those of you reading this please make a mental note that communication with your teammates saves time and progress.


IMO another thing that's easy to do "wrong" is to abandon a core idea of Redux / Elm -- that your app has a single set of named behaviors drawn from a "menu" of action constants. In Elm, you're basically forced to stick to that architecture, but in Redux, the side effect libraries offer various escape hatches.

Once you drop in redux-thunk, you get another place to stick app logic. That logic can be composed of multiple actions firing, with time-dependent (can't think of a better way to say it) data being passed between them.

With redux-saga, since the sagas are long-running, values living in the generators can act as implicit app state.

The closest thing to Elm's ideal that enables side effects is redux-loop. While it may not be the best choice for every app, IMO it's generally good to be cautious around things like: logic moving out of named actions, unnamed "meta-actions," and app state that lives outside of the store.

I'd argue that things like which files code lives in, or what variables get named, while good to get right, are less costly to fix than runtime behavior that works but is hard to reason about. Which is something that the combo of discrete, named actions & immutable state is meant to avoid.

code of conduct - report abuse