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.

• Q: What Is React Suspense?
  • A: A generic way for components to suspend rendering while they load async data.
• Q: What Does That Really Mean?
  • 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: No.
• Q: Really?
  • A: Yup. If you don't like any of this you don't have to change the way you do things one bit. React really values API stability.
• Q: Then why should I care?
  • A: It will probably make your life a lot easier.
  • 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.
  • btw by cascading spinners we mean all unintentional loading states
• 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 fetcher throws 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):

• Q: More!?
  • A: Then check the followup where he just talked Suspense:

• Q: More!??
  • A: Then have a play of the Movie demo here
  • A: Then check out the implementation pull request, the tests and the async react demo (check out the deployed app here, that's what made async rendering really click for me)
• Q: Ok, too long, didn't read. Spell it out for me, what concretely can I use React Suspense for?
  • A: deep breath
  • Data fetching
  • Code Splitting
  • Image loading
  • CSS loading
  • Debouncing
  • Streaming Server Rendering
  • Loading without Race conditions
  • Intentional loading states
  • Eager Loading/Prefetching
  • "Speculative Rendering" aka Rendering components before you actually need them
  • "Transparent Asynchrony" aka Rendering child components without worrying if they're ready to be rendered
  • ... (we're still figuring out how this works)
  • all with less boilerplate!
  • If that sounds like a lot, its because it is.
• Q: Wow. How did Dan Abramov do all this?? He's a beast?
  • A: Dan worked really, really hard on the (super awesome) demo. The entire React team worked on React Suspense, with feedback from the community.
• Q: SO COOL! I want to use it in production now!!
  • A: That is a very bad idea and you should be ashamed of yourself.
• Q: But when can I have it?
  • A: Just mentally peg it "by end 2018" and you won't be too disappointed.
• Q: What should I read next?
  • A: If you want to walk through some code demos, here's one I did of the (warning once again: Unstable!) low level API.
  • Edit: I also made a more in depth React Suspense Cheat Sheet presentation, check it out!