My mistakes with React and Redux

3 minute read

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, only to trash the carefully 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 rapidly 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 really 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 became a huge effort that we naturally avoided until it was too late.

Luckily 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 provide 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 clearly defined update methods for state transitions. Essentially, write a proper state machine with clear transitions and types for every single reducer, and split reducers early if their state starts to grow.
  3. A better approach to CSS. I’ve heard some folks using inline styles, i.e. define styles as JS objects and add them to the style property of React components, and I used to think that this might be a good idea, but recently Webpack’s CSS Modules caught my attention—they can even have types. I don’t know what’s the better idea, and it seems there’s no clear direction in the community either. I’m curious where this is going.

The worst mistake however is to use React when React has nothing to give, but only 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-style request-response 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.


Leave a Comment