What’s the future of Redux?

What awaits Redux in terms of the React ecosystem? Could the rise of new libraries, tools and the upcoming changes in React itself put the future of the library in jeopardy? Let’s find out!

**TL;DR:**The short answer is that Redux isn’t going anywhere. It is more than just a library, it’s an ecosystem of tools that have been adopted by the community due to the problems they solve. It’s going to take a long time for another library to reach Redux’s level of maturity and possibly take its place. So if you are just starting out, a knowledge investment in React and Redux is still your best choice.

Now that we’ve got this out of the way we can dive into the current alternatives and see what the recent talks are all about.

The Context API

React 16.3 introduces a new and more powerful Context API. Up until now, Context has been used more as an experimental feature and its usage has been highly discouraged. Essentially, it provides you with a way to pass some value globally or to a specific subtree of components without explicitly passing it down with props.

This is extremely useful when you want your components to be aware of what theme is currently active for the app, some user specific setting or perhaps the active language.

Creating a context with createContext gives us a pair of Consumer and Provider. The Provider is used to wrap the component tree that we want to give access to the value it provides — this can be the whole app or some small part of it. The Consumer on the other hand is the component which is used to actually consume the value of the Provider.

If you’re interested in learning more about Context you can do so here.

This new API is powerful and I can see how it can be beneficial in some smaller apps which need to have some global data, flag or value. However, if all you’ve needed Redux so far is to keep track of a few global properties you haven’t really needed it anyway.

Redux is supposed to solve your state management problem — keeping track of the data and state of your UI and how they change over time. It’s meant to be highly scalable so you can use it in projects with growing size. Not to mention the development and debugging tools that a big single page app can take advantage of by using Redux.

If you look back at how the Context API is implemented can you imagine building a rich single page application with vast interactions and multiple screens using Consumers and Providers? Imagine that you will need to keep track of what each provider wraps and how it modifies its data. In the end you may end up with a large amount of Providers sitting at the top level of your app.

Context and Redux solve entirely different problems and are meant to be used differently.

Using one where the other was a better choice will ultimately lead to bad architecture. The same way a small app gets bloated by adding Redux to it, a large application will not be sufficiently managed with Context.

To summarise this part — Context is really powerful for the problem it solves but Redux is still a better tool for larger applications.

React Apollo

React Apollo or just Apollo for short is a GraphQL client that can be integrated in your React app and used to bind GQL data to your application. Undoubtedly you have heard about it, tested it or seen some tutorial videos because those tools are under the spotlight at the moment.

There is an abundance of tutorials on YouTube that give in depth explanations on setting up a GraphQL server and consuming its data with Apollo. In my opinion this is not just a fad and in the next years this set of tools can prove to be reliable and take its piece from the pie.

It is used to provide more declarative data fetching and solve a lot of problems out of the box for you. In most of your reducers you have probably implemented the common pattern of adding loading and successful properties to show different components under those conditions.

These are the kinds of problems that Apollo takes care of for you so you can focus more on how the actual data is bound to the UI of your app. It also deals with caching and normalizing data, saving you coding time in the process.

There are alternatives to Apollo such as Relay Modern but its ease of use and lower learning curve may be enough for it to cement its spot as a #1 React Client framework when it comes to GraphQL.

Redux and Apollo rely on different tools and ecosystems.

While Apollo is described as working with any GraphQL server it still requires a GraphQL standard compliant endpoint. Personally, I am a big fan of the technology but it will take quite some time for the majority of companies to adopt a new tool to their stack and use it as commonly as Redux is currently used.

The biggest worry of most experienced developers when it comes to working with new tools is that it can often change which lead to more time being invested in upgrading versions and removing deprecated functions from the codebase, for example. Using the newest tools is often a blessing but sometimes a curse. You may hit showstopper issues that have not been addressed yet or bugs that are still not widely discussed by the community.

The additional ecosystem of Redux also tilts the weights in its favour. Despite the fact that there is a proven way to use it you can structure your code and add additional libraries any way you’d like. I can think of at least three ways to handle asynchronous operations when dispatching actions — thunks, sagas and observables.

It will take at least a couple more years to see in what direction the GraphQL related tools will head to and see how they are adopted in companies that don’t realise the need of them yet.

To summarise — Apollo is looking great so far but due to GraphQL it will take time until it’s widely adopted. With that said even if at one point it becomes a strong competitor I imagine it to coexist with Redux, not push it out of the spotlight.

Redux is not going anywhere

At this moment, investing into the Redux ecosystem is your safest bet as a developer. Something that is often neglected is that a technology switch of any kind needs to also make sense business wise. And switching a library that performs well and solves the problem it was supposed to does not sound that appealing.

Redux has been around for around 3 years and in JavaScript years this is a lot. In this time there are a lot of companies that have invested in it and React and a lot more will follow in their steps. If there is one solid stack at the time of this writing then that is React and Redux.

What else to learn

Learning Redux and its related libraries and tools is what I’d suggest to everyone new to front end development, but if you are already familiar with those and are looking for other ways to advance your career I’ve got some suggestions for different skill levels.

In the JavaScript world if you want to learn new libraries and frameworks you can have one for each day of the year. My advice would be to focus on the fundamentals of the language and have an in depth understanding of it. After that something that I find extremely beneficial is diving into functional programming and learning at least its basic principles.

When it comes to tools and libraries I believe that learning Observables and RxJS in particular will have the most impact on your understanding of programming and the possibilities of front-end development. It may be mind wrenching at first but it will drastically improve your software development skills. Also observables have been adopted by the React, Angular and Vue ecosystems so it’s not a skill that you can only practice in side projects.

If you are already confident in your fundamental JavaScript skills and the flatMap function is no stranger to you then taking up GraphQL and related tools. It’s a technology that was created with the purpose of solving a particular problem and it will just take time before companies start to widely experience the problem that GraphQL solves. I’m confident that it will be adopted in the future, but to what extent only time can tell.