Disclaimer: this article targets developers that are using Redux with React. If you are using Redux with another Framework, this article might not be important for you.

Last thursday, Dan Abramov gave a talk on JSConf Iceland called „Beyond React 16“. A few hours later, react-etc.net featured an article titled RIP Redux: Dan Abramov announces future fetcher API. While I agree with almost nothing that article has to say about Redux, the article got one thing right: Somewhere between 6 or 12 months from now, the way we are using Redux (at least when starting a new project) will be drastically different from the way we are using it today.

But before we take a gaze into the crystal ball, let’s take a step back and see what happened.

What happened so far?

At the end of January, Andrew Clark announced that they had just merged a new Context API. That API will be available in React 16.3 which will probably be released next week.

As a follow-up, Dan Abramov twittered „I hope that with the new context API less people will use Redux because they need a global subscription mechanism, and more because they actually need Redux.“

Last week, Dan Abramov held the aforementioned talk at JSConf Ireland. In that talk, he showcased the new „Time Slicing“ and „Suspense“ features. For the latter, he had an interesting showcase: API Requests. If you have the time for it right now, you should go see the talk. This tab will wait for you ;)

Okay, but what does it mean?

A new Context API

Context is a feature that allows components to share information with other components further down the component tree without explicitly passing it down to the properties of every intermediate child. If you ever used a ThemeProvider or Redux’s Provider , those internally used Context.

But the old Context API had its problems, and the Documentation on Context was prefixed with a paragraph labeled „Why Not To Use Context“ that warned that this API could change at any given moment.

Obviously, it did.

The new version of Context is considered stable and if you want to play with it, get yourself an experimental build of React and take a look at the RFC.

If you’re going to be stuck on an older version of React for the near future, but want to use this feature, you might want to take a look at react-broadcast which provides a very similar API.

Suspense

With Suspense, React is breaking with quite a few paradims that up until now were taboo. It allows to call asynchronous methods in a synchonous way from the render method. React detects that a child is in a „blocking“ state and you may choose component borders which hang in a „waiting for that blocking component“ state while everything outside of that border continues to render normally.

Looking at this demonstrative source code, it becomes clear how this is accomplished: By throwing a Promise from the render function, cancelling the execution of the render function until the asynchronous action has finished and render() is going to be called again.

While this absolutely breaks with the purity a render function should have had until now, it introduces a new requirement for the render function: Idempotency. It mustn’t really matter how many times the render method is called and cancelled right in the middle, as long as the result when it finally completes is what we wanted to have from the beginning.

What will happen?

We (hopefully) will stop using Redux in a few ways that it never really was intended to.

Want to share some global configuration with your whole application? Use Context.

Need to perform an API call and caching of previous API calls? There will be some new library using Context and Suspense to do this in a smart way.

Need to do anything asynchronous? As long as it doesn’t really affect application state, you now can use Suspense instead of fiddling with Thunk, Saga or a self-written middleware.

Redux will hopefully go back to what it was intended to be in the first place: A great way to move your business logic away from your representational logic, keeping your components clean and your business logic testable.

If you want a refresher on where Redux actually shines, there is a great article by Simon Schwartz.