You should probably stop using Redux

This is a follow-up post to Why use React/Redux, where I outlined the benefits of using Redux in your React applications. Even after Dan Abrimov’s popular post You Might Not Need Redux, I felt that Redux added enormous value in applications at scale. However, that was back in August 2017, and a lot has changed since then.

My intention here will be to briefly describe why you really don’t need Redux, and dive into how thinking differently about your architecture can have huge benefits. In its prime, Redux solved the very real problem of scaling out state management in large, and complex, React applications. However, if you have the luxury of being in control of the integration layer, I highly recommend that you set up a GraphQL server to sit between your React application and the REST API. Then, install react-apollo and start hacking.

Let me take a step back and say that if you’re not using GraphQL, you should definitely give it a try. I’ve always been a big fan of micro-services. However, the complex deployments, fractured APIs, and general cost of maintenance was sometimes a deterrent. GraphQL helps you neatly organize your services behind one schema-based API. This is very beneficial for front-end applications since it can focus on integrating with just one API, and leave the vast majority of that complexity to the GraphQL implementation.

Once you are convinced that GraphQL is the way to go, you will quickly realize how much more powerful GraphQL + React Apollo is over a typical REST API + Redux implementation. You’ll find that the GraphQL implementation has much less boilerplate code and is more concise. State management feels natural since you’re not doing anything extra. React Apollo handles caching the data for you. And if you need to update the cached data because of a mutation, that’s easily taken care of as well. I’ll get into more of these details in a later post.

If you have no control over the integration layer, then take a look at React Hooks. Actually, you should be using React Hooks regardless :). Hooks don’t directly replace Redux, but they do make it far less appealing. Together with React’s Context, you can easily find yourself building scalable front-end applications without Redux.

In conclusion, the React ecosystem has matured beyond Redux. Consider leveraging the power of GraphQL together with React Apollo.

Why use React/Redux?

These are a few points of why I continue to choose React/Redux for new projects and not <insert popular JavaScript library here>. I’ve given other tools a try, and can’t find a good reason to switch to something else, yet :).

React and Redux have a large ecosystem

When evaluating tools, it helps not to view them in isolation. Just as important as the tool itself, is the ecosystem that surrounds it and how active the community is. Avoid statements like, “Vue is smaller than React and performs better”. That may be true, but it’s unfair to base your decision on a few quantitative metrics, unless they’re extremely important to you. Most of the time, it’s the stuff that can’t be quantified that really matters in your every-day development cycle.

There are hundreds of libraries within the React and Redux ecosystems. Someone has already created a component for almost anything that you can imagine. There are also a number of UI component libraries with large catalogs of common components. Some of these libraries can help you get up and running quickly without the need for a designer. Along with the number of libraries available, the React/Redux communities are also very active and try to keep things up-to-date.

React’s large ecosystem can also be a disadvantage, however. It can lead to a fragmented set of tools that make it hard to decide when to use one and not the other. Vue.js has a smaller ecosystem, making it a bit easier to know which additional library to use at the appropriate time. However, it still has a long way to go before achieving the level of maturity that React currently has.

Angular, on the other hand, is a framework that provides much of what you need to build an application. Some developers see this as a major benefit, since they don’t have to run around looking for additional tools that play nice with Angular. This is the old “framework vs library” argument. I prefer to use a library, over a framework, because it grants me much more flexibility and freedom.

React uses JSX

JSX empowers developers to approach building web applications in a modular and composable way. Modularity is not unique to React and, in fact, some developers prefer using templates to build components. Templates are nothing new and are the default way of creating components in other popular libraries, and frameworks, such as: Vue.js and AngularJS. However, what I like about JSX is the detachment from standard HTML practices. Building an application with JSX feels more like you’re creating a desktop, or mobile application, than a web application.

Using templates does have its advantages as well. For example, developers can integrate with a designer’s HTML/CSS deliverable far easier using templates than with JSX. This, however, is not enough to convince me to stop using React, since it has been my experience that this is not a very common practice anymore. Most designers deliver Adobe Illustrator or Sketch output instead, requiring developers to start from zero and build up the application.

It’s also worth mentioning that while JSX is a language that ultimately compiles down to JavaScript, it is still very similar to HTML in its syntax. For example, this is valid HTML code: `<div class=”header”></div>`; and this is valid JSX code: `<div className=”header”></div>`. The difference is that in JSX, `class`, is a reserved word so you have to use `className`.

React/Redux scales nicely

It has been my experience that writing a small application in React/Redux is just as complex as writing a very large application. This is both a gift and curse. Setting up a React application requires a significant amount of configuration and knowledge of build tools. Ensuring that you get everything in order can slow down the initial phases of a project. Recently, however, React has helped mitigate this complexity by creating “create-react-app” - a simple tool for creating React applications with no build configuration.

Once your application build is configured and you’re comfortable with the tools, it does not get any more complicated. This is an important point that I think is often overlooked. As your application scales out, and more and more requirements start coming in, it can get overwhelming if you don’t have a great foundation. React, and Redux, provide a platform to scale out applications easily by providing a consistent set of practices that developers unknowingly follow. The React/Redux functional programming paradigm enforces a modular and loosely coupled codebase. This not only encourages consistency, but also code that is much easier to test.