The future of React is not another state manager
Dan Abramov demoed awesome UX improvements coming to React, but no new state management approach. There was some confusion that the declarative data fetching shown was somehow an alternative to Redux.
I'm cracking up 😂https://t.co/ZRGdhnV248
Folks, this is totally not true and is based on a joke tweet I tweeted. And I can't stop laughing. 🤣
— Kent C. Dodds (@kentcdodds) March 1, 2018
Dan did demo how React will give a better user experience by rendering asynchronously. React will no longer block the main JS thread when doing expensive DOM operations. It can prioritize rendering important updates over less important ones. This means that updates caused by user interactions will be performed before other updates. I recommend watching the demo.
This approach can also be leveraged to suspend rendering when waiting for IO operations. In the talk Dan showed how you can suspend rendering by using
Promises inside the render loop. This can look like a new approach to state management, but it was just showing how you can pause rendering in your own code as well.
The code for the demo was using
setState to store which movie was clicked.
The data fetching was performed by a regular fetch call. The
createFetcher method from
../future was just a way to cache a function that returns a
Promise. It also suspends React rendering while the
Promise is pending. See this thread for more details on the cache:
createFetcher from @dan_abramov's talk is this thing:
We're calling it simple-cache-provider (for now). It's a basic cache that works for 80% of use cases, and (when it's done) will serve as a reference implementation for Apollo, Relay, etc.https://t.co/elI6YFco0A
— Andrew Clark (@acdlite) March 1, 2018
Using cached data fetching in React is something you can already do. Using a component like
react-promise also leverages setState.
This is not a full state management approach, just a way to do declarative data fetching. Declarative data fetching gives you a nice abstraction to display the loading, error and response state of an ajax call, but it doesn't allow you to store user input.
Caching the ajax calls in a global cache is a nice addition to make it possible to reuse the same server data across the application. You could implement this yourself. You could even use the browsers own response caching or use the Cache API inside a service worker. However, it is not something new.
Overall I'm excited about the new UX improvements coming to React. I'm less excited about the bikeshedding regarding state management.