The Future of Redux

Let’s have a look at how redux will evolve in the coming years.

We'll cover the following

A word from our friend Mark EriksonRedux co-maintainer and author of the Redux FAQ and several of the Redux ecosystem resources :
In many ways, Redux has been “done” since its initial 1.0 release in August 2015. The 2.0 and 3.0 releases less than a month later cleaned up a few bits of the public API, and 3.1 in January 2016 allowed passing an enhancer as the last argument to createStore(). The changes since then have mostly been small internal tweaks and minor cleanups that aren’t meaningfully visible. Even the recent 4.0 release is primarily about updating TypeScript typings and smoothing out edge cases.

So, where is Redux going in the future? There are a few different answers to that question.

Redux roadmap

First, the core Redux library will remain stable, with some additional tweaks around the edges. For example, users frequently ask for combineReducers() to allow scenarios like passing additional arguments to slice reducers or skipping warnings when state slices exist without a slice reducer to handle them. We may try breaking up the combineReducers() functionality into smaller functions to allow users to supply their own implementations for iterating over state values and combining them, or allow options to turn off warnings, then reimplement the internals of combineReducers() to use those customizable options. Overall, the core API will stay the same.

React-Redux, on the other hand, will see some major changes in the near future. React-Redux 5.0 was already a complete internal rewrite that moved the subscription logic out into memoized selector functions and added top-down subscription behavior to ensure that parent components are updated before their children. With the release of React 16, the React team is pushing forward with changes to React’s API and behavior that will require corresponding changes to the internals of React-Redux. In particular, the React team has proposed a replacement for the existing context API, which React-Redux currently uses to make the store instance accessible to nested components.

The upcoming work on async rendering will also require changes and adaptation by all state management libraries in the React ecosystem. Ideally, the public API will remain the same regardless of any changes. Otherwise, your application code would have to change as well.

Growth of the Redux ecosystem

The other big area of change is the growth of the Redux ecosystem. The React Boston 2017 presentation covered some of the stats and trends showing Redux use, and the wide variety of Redux-related addons. Some highlights:

  • Redux is used in an estimated 55-60% of React apps, and Redux or Redux-inspired libraries are frequently used in the Angular, Vue, and Ember ecosystems.
  • Redux addons catalog currently lists over 2,000 Redux-related addons, tools, and libraries.
  • While there are many side effects libraries available, the four most popular are:
    • redux-thunk as a starting point for simple async logic
    • redux-saga for complex async logic using generators
    • redux-observable if you prefer to use observables
    • redux-loop for those who want to emulate Elm-style side effects in reducers
  • There are many different approaches for fetching data and making network calls; everyone seems to be doing it differently.
  • Store state persistence is widespread.
  • Redux-based routing is attracting interest as an alternative to React-based routing.

In addition, the Redux community continues to build valuable tools to solve a variety of use cases, from generating reusable action creators and reducers to tools for data fetching and network behavior to higher-level abstractions on top of Redux.

Get hands-on with 1200+ tech skills courses.