Let's Build Suspense 🥁

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

As the pendulum of web development swings back towards the server, streaming has become increasingly popular. Specifically, out-of-order streaming through features like React Suspense, the magical powers behind Server Components.

Let's build our very own simplified version to explore how it works, what problems we are trying to solve, and what this future of web development looks like.

This talk has been presented at React Summit US 2024, check out the latest edition of this React Conference.

FAQ

Suspense on the server is considered impressive because it is crucial for React server components, enabling them to function effectively by managing asynchronous tasks.

Suspense helps improve server-side rendering by allowing the use of streaming and out-of-order streaming, which enhances user experience by rendering components as they become available, rather than waiting for all data to load first.

Server components in React allow developers to specify which components are static and can be rendered once, and which components are dynamic and need client-side rendering and hydration, thus reducing JavaScript bundle size and improving performance.

Streaming allows the server to start sending parts of the response as they become available, rather than waiting for the entire response to be ready, thus improving the speed and user experience of web applications.

The main advantage is the reduction in JavaScript bundle size and the improvement in hydration performance, as Suspense allows components to render immediately once ready, without waiting for all components to load.

Suspense can handle asynchronous data fetching by allowing components to specify fallbacks, which are rendered while the asynchronous data is being fetched, improving the user experience by displaying loading states.

JavaScript is used to swap out loading states for actual content once it is available, employing techniques like custom elements to effectively manage the DOM elements.

By using the platform's native functionalities, server components and Suspense allow for effective caching of streamed content, enabling quick back and forth navigation in the browser history without re-fetching data from the server.

You can find more resources on Suspense, server components, and related topics through various recommended readings and links provided in the presentation, including code examples and slides.

Suspense allows you to render boundaries within your application to render fallback UIs like loading states whenever anything underneath those boundaries is still waiting for promises to resolve.

Julian Burr
Julian Burr
20 min
22 Nov, 2024

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Hi, my name is Julian and I am super excited to be speaking at React Summit this year. Today, I will be talking about Suspense on the server and its importance in React server components. React server components allow us to differentiate between static and dynamic components, improving performance and user experience. Suspense improves performance by introducing streaming and out-of-order streaming. We can implement suspense on the server by creating a suspended object to store the suspended children and swapping out the loading state for the actual content using custom elements. Multiple suspense boundaries can be used to render individual loading states for different sections, improving the user experience.
Available in Español: Construyamos Suspense 🥁

1. Introduction to Suspense and Server Components

Short description:

Hi, my name is Julian and I am super excited to be speaking at React Summit this year. Today, I will be talking about Suspense on the server and its importance in React server components. Let's take a quick look at how we got to server components, the history of web rendering, and the problems we encountered along the way - JavaScript bundle size, hydration, and slow server response time. Server components allow us to differentiate between static and dynamic components, improving performance and user experience.

Hi, my name is Julian and I am super excited to be speaking at React Summit this year. Now, 20 minutes isn't a lot of time, so let's get right into it because I want to talk about Suspense. I'm a huge fan of Suspense, basically ever since they started demoing early versions of it in 2016, so quite a while.

But for those of you who don't know, Suspense basically allows you to render boundaries within your application to then render fallback UIs like loading states whenever anything underneath those boundaries is still waiting for promises to resolve. So those could be API calls, but it could also be lazy little JavaScript chunks or any other asynchronous tasks that you're doing in your application. Now, that's pretty cool. But I think Suspense on the server is even more impressive, and I would even go as far as saying it's the unsung hero of React server components because without it, server components the way we know them wouldn't really be feasible. And today, I hope I can show why I think that is and also demystify a few things that are happening underneath the hood.

Now, before that, I want to take a quick look at how we even got to server components in the first place, how Suspense ties into all that just to get everyone on the same page. To do that, we have to take a quick look at the history of web rendering at the last 15 to 20 years. And now, this will make me sound like an old person, but I hope a lot of us still remember the days when we were writing plain HTML and then eventually dynamically creating it on the server with languages like PHP. Now, that came with a drawback, especially if we had to do a lot of work on the server to get that HTML, that initial server response time could be really slow. And that's obviously bad for user experience. So when we started introducing JavaScript to our apps to make them more dynamic, we also introduced concepts like AJAX.

So AJAX allows us to even after the initial server response is finished, to still go back to the server and do stuff. So that means we can offload a lot of that heavy lifting, still have a quick server response, initial server response, and render some kind of loading state while we're going back to the server and fetching more data or whatever we need to do. Right? And that was so convenient that we started doing it more and more until we eventually arrived at what we now know as single page applications. And with it came all the frameworks that we know and love like React, like Vue, like Angular. And to get the best of both worlds, those frameworks very quickly reintroduced the concepts of server-side rendering and static site generation. But we did carry over some of the problems that we had, namely, the first one being the JavaScript bundle size. So ever since single page applications, JavaScript bundles just kept increasing and increasing. And that's not great. And it also caused somewhat like the second problem, which is hydration. So even if your server side render your app, React still needs to send all of the JavaScript to the client and needs to run all of the JavaScript to then hydrate your whole application, just in case some parts of it need client side logic, be it state, be it effects, or event listeners and that kind of stuff. Now, hydration can be really slow. So in fact, that started becoming one of the performance bottlenecks that we're seeing in modern web applications. The third problem is we're back on the server now. So we have the original problem again, where if we're doing a lot of work on the server, that initial response time can get really sluggish. So introduce server components. The main point of server components is for us developers to be able to tell the bundler which components in our application are static, only ever need to be run at once and which components are dynamic and actually need to be run in our client and also need to be hydrated.

2. Understanding Suspense and Server-Side Rendering

Short description:

React server components don't address the third problem, which is where suspense comes in. We'll build our own simplified version of suspense on the server to understand its conceptual workings and the evolution of classical server-side rendering. This will demonstrate how suspense improves performance by introducing streaming and out-of-order streaming.

So realistically in a normal application, this can massively reduce your JavaScript bundle size and with it massively reduce the amount of hydration that needs to happen after the initial render. But on its own, React server components don't do anything about the third problem. So this is where suspense comes in.

To see how suspense solves the problem, we are going to build our own version of suspense on the server from scratch. Now I want to be very clear here. This is not how suspense is implemented in React. This is intentionally a very dumbed down, a very simplified version of it. The main point I'm trying to make here is to show how suspense works conceptually and also to go through the evolution of what I would call classical server side rendering and to show how we can improve it by introducing something like streaming and then further improve it by introducing what's called out of order streaming, which is what suspense allows us to do.

3. Building NotFlix Movie Application

Short description:

Let's look at some code for building a movie application called NotFlix. We have a straightforward page with a title section, cast members, and similar movies. The components fetch asynchronous data, but we don't control how long it takes. They are server components without state or effects, allowing convenient data fetching.

Alright, enough talking. Let's actually look at some code. And for that, let's pretend we're building a movie application because apparently that's what everyone seems to be doing these days, at least for the demos. And it's called NotFlix because it's definitely not like Netflix and I'm really bad at naming things.

But we can see the page that we're trying to build is pretty straightforward. So we have our logo at the top. Then we have a title section with a poster and the movie title and some meta information like year, genres, and a movie summary. Then we have a scrollable list of the cast members. And at the bottom, we have another list of similar movies because we definitely don't want the user to ever leave our application, right? Cool.

If we look at the code for that, or more specifically, if we look at the components, we can see a few things. So for one, this is the title component, which renders the poster and the summary and stuff. And this is a details component, which renders the customers. And in both, we can see the fetch there and data. So for the purpose of this talk, it doesn't really matter where that data comes from, whether it's a third party API or internally, it could be our own database. What matters is that it's asynchronous. So it will take some time for the data to be there. And we're not in full control over how long that takes.

The other thing that we can see is they're all basically server components. So again, for the purpose of this talk, we only really care about what's happening on the server. And what this means is they can't have anything like state or effects, but they can be asynchronous functions. And for that, it means we can do the data fetching like we do here, right inside of the component, which is convenient.

4. Improving Server-Side Rendering with Streaming

Short description:

Let's start with classical server-side rendering. We collect HTML by executing server components as functions and turning the results into strings. The browser's slow response time when navigating to new pages is a bad user experience. To improve it, we introduce streaming using the write method in Express. We no longer need to collect HTML in memory and can send the response incrementally, closing the connection when finished.

Now, let's start with what I call classical server-side rendering. And let's look at what the server code for that could look like. We see we have a very basic or standard express setup, and then in our route, we're rendering our application. And then we start collecting HTML. And basically for the app itself, we're just going through all the components that we render, and assume each of those could be a server component. So we execute them as functions, and we await their results. And we turn those into strings. And then at the end, we just concatenate all the strings.

And once we collected all the HTML, we return it back to the server, to the client. And what that looks like, we already seen. This basically uses that render. Right? So it does what we want it to do. But we can also see the problem that I was describing in the very beginning. If we click on one of the links here below, it takes a long time for the browser to actually bring us there. Because the browser has to wait for the server response, before it can actually navigate to the new page. And this is obviously a very bad user experience.

So how can we improve it? The first thing we can do, and I already hinted on that, is introducing streaming. So streaming has been around forever. Basically, since the introduction of the World Wide Web and HTML. And what it does, it allows us to start writing a response, and then keep the connection open, and keep appending to that response document, whenever stuff becomes available. Right? And frameworks like Express and other server frameworks make that really easy. So in Express, on the response object, we have a write method that does exactly that. It writes to the response strip. So let's use that everywhere where we were collecting HTML in memory before. So we don't need that anymore. And use it here. And then we also don't have anything at the end anymore that we need to send, because we've already sent everything. And instead, we just tell the browser, by the response end function, that the connection can be closed. We're finished now. And if we refresh the page, we see that it does what we want.

5. Rendering Order and Implementing Loading State

Short description:

The sections are out of order because we're dealing with promises in parallel. To render elements in the right order, we switch to a sequential for loop instead of a promise all. However, we're still mostly looking at a blank screen while stuff is loading. To show a loading state, we use suspense on the client and implement it on the server. We also need to keep track of suspended children.

It immediately renders that logo. But you can also see that there's a problem, and you might have already caught that before, and are screaming at your screen right now. Our sections are all jumped up, they're out of order. And it makes sense. We're still dealing with all of the promises in our components in parallel in this promise all function. So that doesn't really work because in the stream, like I said, we can only ever append to the bottom of the document.

So in order to render the elements in the right order, we have to deal with them in sequence. And I know this is not the most efficient way to do it. But I want to keep things simple for the sake of this demo. So I'll just turn this into a sequential for loop instead of a promise all. And if we refresh the page now, we see it again, renders the logo immediately. And then it renders each of the sections once they become available. Now, this is a lot better than what we started with. But it's still not great, because we're still mostly looking at a blank screen.

So even if you imagine the logo wasn't at the top, but was rendered for whatever reason underneath the title section, we would literally just stare at a blank black screen while the stuff is loading. So that's still not great. So how can we show a loading state to the user while stuff is loading? Now on the client, we could just do suspense here, like render suspense boundary, and render fallback here. So that fallback here, like I said in the beginning, could be some kind of loading state. Then we wrap that around all of our asynchronous components, and that loading state will be rendered while asynchronous stuff is happening. Now let's implement that on the server.

First, we need that component. And that exports the function suspense. Like I said, it has fallback and children. I'm gonna be lazy with types just for the sake of time. But for now, let's just return fallback, just to get us started. And then use that component here. And if we refresh the page, it does exactly what we want. It immediately renders the logo and the fallback. So now we need to keep track of all of those suspended children that we haven't rendered immediately, but that we do want to deal with in the background. Right? So for that, we need a way to keep track of them.

6. Implementing Suspense on the Server

Short description:

To implement suspense on the server, we create a suspended object to store the suspended children. After rendering the application, we check if there are any entries in the suspended object. If there are, we loop through the entries, get their response, turn them into strings, concatenate them, and remove the entry from the suspended object.

So let's create a simple object we call suspended. And then we need the ability for each suspense instance to have a unique ID. So we know, again, we're just dealing with them on the server, so we can easily do this to make sure each instance has a unique identifier. And then we can use that identifier to store the children that we suspended.

And now, after rendering our whole application, we can actually just check, do we have any entries in that suspended object? So if we just look at the length of that, we know, if any of them are there, basically what we want to do is very similar to what we've done in the classical server side rendering before. Right?

So we want to look at all the entries of the suspended object. Then we make sure that we're actually dealing with an array of React elements. But once we have an array of React elements, we just loop through them again, get their response, turn them into strings, concatenate all of those strings at the end, and then remove that entry from the suspended object because we've dealt with it.

7. Swapping Loading State for Content

Short description:

To swap out the loading state for the actual content, we need to identify the fallback and wrap it in a div with a suspenseID data attribute. We can give the div a display of contents to prevent layout issues. We then wrap the actual content in a template and use web components or custom elements to tell the browser which fallback to replace with the content. JavaScript is required to make this work.

If we run that, we still get the logar and the loading state, but once the content is ready, it also pops into existence. So this is cool. Like now we're really close to what we want, but not quite there.

So the last step that we need is to somehow swap out the loading state for the actual content once it's available. So how can we do that? Like how do we get around the restriction that I described before? We're working with a stream. Stream only allows us to append to the bottom of the document. How do we actually replace a previously rendered element with a new element? So short answer is we can't.

I know that's a bummer, but like most of the things in this world these days, the real magic happens in JavaScript. So we do need a little bit of JavaScript to make this work the way we want it to. And there's basically a few things that we need to make sure we can do. One is we need to actually identify the fallback that we want to swap out because there could be multiple fallbacks. So we need to be able to tell which fallback is the right one for the content that's ready.

So let's wrap the fallback in a div, give it a data attribute that identifies it. Call it suspenseID. That's just the idea that we already have. And now a CSS tip on the side. We don't want this div to mess with the layout of the page. So we can just give it a display of contents, which basically tells your CSS renderer to ignore this div for any layout purposes. So if that is wrapped in a grid layout or a flex layout, this div will be ignored and CSS will look in the children for any layout purposes. So that's pretty cool.

And once we're able to identify it, what we want to do is wrap the actual content in a template. So this will allow us to still add it to the document, but the browser will ignore it. It will not render anything. Let template tag. And the other thing that we want to do is now tell the browser which fallback it should swap it out for, right? So the content is available. We want to swap it into place wherever that fallback was rendered. So there's a billion ways to do that for the purpose of this demo, we are going to do it with web components or more specifically custom elements. So let's pretend we have a custom element called suspense content, and that has a target ID. So this allows us to tell the browser, this is the ID we want to swap it out with. And now we just need to write that JavaScript that does what it does.

8. Implementing Swapping of Loading State

Short description:

To implement the swapping of the loading state with the actual content, we define a custom element called suspense content. The connected callback function is called when the element is rendered. We find the previous sibling, which is a template element, and use the target ID attribute to locate the corresponding suspense boundary in the DOM. We then swap out the HTML content, allowing the loading state to be replaced by the actual content. Multiple suspense boundaries can be used to render individual loading states for different sections, improving the user experience.

So for the sake of time, because I'm running out of it, I'll just copy that from my notes, but I'll still go through it like we're actually doing here. So all we're doing is we're defining a custom element, like I said, calling it suspense content. And this basically allows us to use that as a tech like here. And every time the tag gets rendered, the connected callback function will be called. And in that connected callback function, all we're doing is looking for the previous sibling, which we know is a template element. Then we take the ID from our attributes from the target ID. We use that to in the DOM find the suspense boundary, like our fallback that we rendered with the related ID. And all we're doing is swapping out the HTML of each other. Cool. If we save that, refresh the page, it hopefully does exactly what we want. It shows the loading state, but once the content is there, bang, it gets swapped out with the loading with the, with the actual content. So the loading state is gone, the actual content is there, and we're not limited to a single suspense boundary either. So just like on the client, what we can do is wrap each of our sections in their own suspense boundary to render their own loading state. And was, that gives us is even better UX because now, um, each of them has a loading state and each of them can render immediately once they're ready, they don't have to wait for all of them to be there, which is pretty cool.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Simplifying Server Components
React Advanced 2023React Advanced 2023
27 min
Simplifying Server Components
Top Content
Watch video: Simplifying Server Components
React server components simplify server-side rendering and provide a mental model of components as pure functions. Using React as a library for server components allows for building a basic RSC server and connecting it to an SSR server. RSC responses are serialized virtual DOM that offload code from the client and handle interactivity. The client manifest maps serialized placeholders to real components on the client, enabling dynamic rendering. Server components combine the best of classic web development and progressive enhancement, offering the advantage of moving logic from the client to the server.
A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Speeding Up Your React App With Less JavaScript
React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Top Content
Watch video: Speeding Up Your React App With Less JavaScript
Mishko, the creator of Angular and AngularJS, discusses the challenges of website performance and JavaScript hydration. He explains the differences between client-side and server-side rendering and introduces Quik as a solution for efficient component hydration. Mishko demonstrates examples of state management and intercommunication using Quik. He highlights the performance benefits of using Quik with React and emphasizes the importance of reducing JavaScript size for better performance. Finally, he mentions the use of QUIC in both MPA and SPA applications for improved startup performance.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.