This is the repo for swyx's blog - Blog content is created in github issues, then posted on swyx.io as blog pages! Comment/watch to follow along my blog within GitHub
source: devto
devToUrl: "https://dev.to/swyx/react-suspense-qa-28lc"
devToReactions: 19
devToReadingTime: 5
devToPublishedAt: "2018-03-27T21:02:17.881Z"
devToViewsCount: 1267
title: React Suspense Q&A
published: true
description: a friendly cheat sheet for those wondering what React Suspense is and if they should care
category: note
tags: react, tech, javascript
Why we want React Suspense, in a GIF
Q&A
Disclaimer: I do not speak for the React team, this is just what I, a regular React user, have learned over dozens of hours of studying the information available.
A: React is getting 2 new primitive capabilities that give you a lot more control over loading anything, while staying interactive. A lot of boilerplatey things (e.g. fetching data without race conditions) will become much simpler to write, and some previously impossible things (e.g. partially rendering components while waiting for data) become easy.
Q: I'm fatigued already. Do I really have to learn this?
A: Also its frickin cool'. You like cool things, right?
Q: How does it make my life easier?
A: Anytime you need to display something that needs to be loaded, you create a fetcher for it and just use the fetcher inside your render method.
If React tries to render something that hasn't been fetched, it stops the render and goes to fetch it.
If something was previously fetched before, it is cached and renders immediately.
If you want a Placeholder (eg spinner) to show if a fetch takes too long, thats just a couple lines of code.
If you want to avoid cascading spinners as different things are fetched, that's how Suspense works by default. We really don't like cascading spinners.
Q: Isn't that a job for Redux or a lifecycle method?
A: Not anymore, if you don't want it. No need to use componentDidMount or dispatch a Redux action just to fetch data. No need to define extra state variables like isLoading or pastDelay and deal with the state explosion that can come from multiple things loading at various different times. And did I mention that your UI stays interactive throughout this whole thing?
Q: Doesn't react-loadable already do this?
A: Only kind of. The focus on keeping things interactive while loading (by rendering on a "separate thread"... we'll explain later) cannot be done in "userland" and requires handling in React's (coming) AsyncMode.
Q: Cool so this fetcher and Placeholder are the new parts of React?
A: Nope. That's the "High Level API", and you're going to see a bunch of these come out over the next year as people experiment with them. Don't worry about the low level APIs for now, those are unstable.
Q: Are you trying to make fetch happen? It's never going to happen.
A: Everyone's already tired of that joke and its only March. Please be more original. Great movie tho.
Q: Why's it called Suspense?
A: That's a reference to how it works internally. When you try to render something that requires data, your fetcherthrows a promise up to React, and React suspends the rendering (within limits) while the data is being fetched. While the fetch is ongoing, your UI is still interactive, as though the fetching is on a different thread (note: not technically true).
Q: Is it safe to throw things willy nilly like that?
A: It was supposed to be controversial, but so far nobody's found a real objection to it. And extensive tests have been written. You'll see the words "algebraic effects" a lot, but for our purposes you can think of them as resumable exceptions. As a user, you'll probably never actually write this yourself.
Q: What's this about a cache? Is React getting a cache?
A: Caching is great and kinda central to the whole "do I fetch or not" thing. React provides the ability for users to make caches, and we're gonna see a whole lot of innovation there too. The React team has provided a simple-cache-provider which will probably be very popular for basic apps, but they don't handle a lot of nuance, such as fine-grained cache invalidation. You may have heard that's a hard thing.
Q: Enough talk. Where do I see some code?
A: First check out Dan's JSConf talk on Time Slicing + Suspense (the official video is here but I can't embed it):
{% youtube v6iR3Zk4oDY %}
Q: More!?
A: Then check the followup where he just talked Suspense:
source: devto devToUrl: "https://dev.to/swyx/react-suspense-qa-28lc" devToReactions: 19 devToReadingTime: 5 devToPublishedAt: "2018-03-27T21:02:17.881Z" devToViewsCount: 1267 title: React Suspense Q&A published: true description: a friendly cheat sheet for those wondering what React Suspense is and if they should care category: note tags: react, tech, javascript
Why we want React Suspense, in a GIF
Q&A
Disclaimer: I do not speak for the React team, this is just what I, a regular React user, have learned over dozens of hours of studying the information available.
fetcherfor it and just use thefetcherinside yourrendermethod.Placeholder(eg spinner) to show if a fetch takes too long, thats just a couple lines of code.componentDidMountor dispatch aReduxaction just to fetch data. No need to define extra state variables likeisLoadingorpastDelayand deal with the state explosion that can come from multiple things loading at various different times. And did I mention that your UI stays interactive throughout this whole thing?react-loadablealready do this?AsyncMode.fetcherandPlaceholderare the new parts of React?fetcherthrows a promise up to React, and React suspends the rendering (within limits) while the data is being fetched. While the fetch is ongoing, your UI is still interactive, as though the fetching is on a different thread (note: not technically true).throwthings willy nilly like that?{% youtube v6iR3Zk4oDY %}
{% youtube 6g3g0Q_XVb4 %}