My mistakes with React and Redux

Written by

Web Frontend Development. Loathe it or like it. I can’t say that I like it but with React and Redux a bit more than I used to. All is not gold that glitters, though, the React stack being no exception, and there’s indeed much that we did wrong in our React application. This post is my personal top three of React mistakes:

  1. Traditional CSS. We were building isolated and encapsulated UI components with well-defined interfaces, and trashed the arduously erected boundaries with global pervasive styles and classes.
  2. Object Spread. Redux has a recipe which recommends the Object Spread Operator to update state in reducers. It looked so nice in the example that we super-hipsterized our babel configuration with all the latest ES7 stuff, but as our application grew and with it its state the pattern started to fall apart. Our discipline left us and we were lumping all sorts of objects together with Object Spread until our reducers had become a large mess that no one understood anymore.
  3. No Typescript. All these mistakes would have been curable with some deep refactoring, but in the absence of types that catch simple mistakes we did not dare to refactor. We felt that our application was impossible to refactor mechanically, so untangling even a single reducer was a large effort that we naturally avoided until it was too late.

The application is not in production anymore, but had I to write it again, I’d have done a couple of things differently:

  1. Use Typescript. From the first line of code. With full type checking and strict null checks, and zero compromises. As an application grows I believe types offer the freedom to refactor at need, serve as a good tool for communicating structure and intent, and enforce a certain discipline.
  2. Proper classes for reducer state, with strictly defined update methods for state transitions. In other words, write a proper state machine with clear transitions and types for every single reducer, and split reducers as soon as their state starts to grow.
  3. A better approach to CSS. I’ve heard some folks using inline styles, ie, define styles as JS objects and add them to the style property of React components, and I used to think that this was a good idea, but of late Webpack’s CSS Modules caught my attention—they can even have types. I don’t know what’s the better idea, and it looks as if there’s no clear direction in the community either. I’m curious where this is going.

The worst mistake though is to use React when React has nothing to give, and just takes a toll in complexity.

In the end our application was just a dead-simple CRUD application, with little to no user interaction and no need for client side state. In the end, a dead-simple old-school server-side rendering thing would have been much easier, much faster, and much less work, with no loss of functionality and features.

I’ve seen this “React fever” in other projects as well and like the gold fever it’s doing a lot harm.

Sometimes it’s best to leave the glitter aside, and build your house with solid rock.