Server Components: The Epic Tale of Rendering UX


Server components, introduced in React v18 end these shortcomings, enabling rendering React components fully on the server, into an intermediate abstraction format without needing to add to the JavaScript bundle. 

This talk aims to cover the following points:

1. A fun story of how we needed CSR and how SSR started to take its place

2. What are server components and what benefits did they bring like 0 javascript bundle size

3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what

4. My take on how rendering UI will change with this approach

26 min
06 Jun, 2023


Sign in or register to post your comment.

AI Generated Video Summary

This Talk introduces server components in React, which provide an intermediate format for rendering and offer advantages for both client-side and server-side rendering. Server components reduce bundle size on the client and improve search engine optimization. They abstract the rendering process, allowing for faster rendering and flexibility in choosing where to render components. While server components are still in the experimental stage, Next.js is a good starting point to try them out.

1. Introduction to Server Components

Short description:

Today, I'll be talking about one of the very coolest things that React has been working on, which is server components. We'll be diving into different concepts, but I will be explaining the things in a little more fun way. Let's just have only one agenda in our current talk, which is just a short story, and let's try to uncover things based on the short story itself. Before diving in, a little bit about me. I am Nikhil, and I work as a software engineer here at Postman. I usually work on super fun stuff like design systems and the overall foundation of user experience that we have set up here in the product. I love to talk about everything that the web is doing and it's heading to in general. So if you're like a geek like me, I would love to connect on Twitter, on GitHub. You can find all these handles which I'll definitely share with you all.

Hey, everyone. Today, I'll be talking about one of the very coolest things that React has been working on, which is server components. We'll be diving into different concepts, but I will be explaining the things in a little more fun way. Without any further things, let's try to see what we are planning to cover in this talk.

You might be thinking, maybe what's this guy going to tell us? What are server components? How they work? Blah, blah, blah. They can be a thousand number of things. I would just say, for this talk, because I want to keep the theme of the talk as simplicity. Let's just have only one agenda in our current talk, which is just a short story, and let's try to uncover things based on the short story itself.

All right. So, before diving in, a little bit about me. I am Nikhil, and I work as a software engineer here at Postman. I usually work on super fun stuff like design systems and the overall foundation of user experience that we have set up here in the product, so I work on the bits and pieces of all of these things. Yeah, other than that, I love to talk about everything that the web is doing and it's heading to in general. So I love to talk about performance. I love to talk about how the front end is going and what new is coming up. So, yeah, if you want to, if you're like a geek, like a kind of a geek like me, so I would love to connect on Twitter, on GitHub. You can find all these handles which I'll definitely share with you all. So, yeah, I would really love to connect with you all.

2. Introduction to Client Side Rendering

Short description:

Bob is a person who is at a beach and like accidentally, he does not have anything to create a sand castle on a beach. He loves building sand castles. The responsibility of building the sand castle is like probably only on to Bob. This is how client side rendering right now works. You will have a server and you will have someone like a client that is going to request the server to do something. In this case, like as a Bob wants to build a sandcastle, maybe, you know, a client wants to build a web page. So he requests this from the server. The server is going to give it a response, which is, you know, a list, like a JavaScript files is going to give it HTML files and CSS. And it's the client's responsibility, like, you know, Bob is, it was Bob's responsibility that he has all the sand and what is the disposal and he has to figure out how to build a sandcastle. So this is what the browser does as well. The browser creates the final website basically. And like when everything is ready, this is what you see on your page, right?

So okay, so now let's get to the fun part. Now let's start a story with a guy named Bob. Now, Bob is a person who is at a beach and like accidentally, he does not have anything to create a sand castle on a beach. He loves building sand castles. But like what he has to do is he has to see, okay, there is sand and I just need to use my hands, like how we used to do in childhood, right? So we need to, like he just needs to build this sort of thing with just some hands.

So the responsibility of building the sand castle is like probably only on to Bob. He has to figure that thing out. He does not have anything to help him out. Now, with this starting gist of the story, this is what you would, if you relate to it, you would see, this is how client side rendering right now works, right? You will have a server and you will have someone like a client that is going to request the server to do something. In this case, like as a Bob wants to build a sandcastle, maybe, you know, a client wants to build a web page. So he requests this from the server. The server is going to give it a response, which is, you know, a list, like a JavaScript files is going to give it HTML files and CSS. And it's the client's responsibility, like, you know, Bob is, it was Bob's responsibility that he has all the sand and what is the disposal and he has to figure out how to build a sandcastle. So this is what the browser does as well. The browser creates the final website basically. And like when everything is ready, this is what you see on your page, right? So like pretty much simple.

3. Server-side Rendering and Client-side Rendering

Short description:

Now Bob remembers, oh, I don't have anything, so let me take some help. Bob takes helps from his sister, Sarah. Sarah is well-equipped and passionate about building sand castles. This is what SSR is, where you tell the server to build the website for you. The server creates the final HTML output on the server itself, and you get that HTML output on the client. Server-side rendering provides a bare minimum for users to see, and when JavaScript is available, the application becomes ready for users to interact with. In this talk, we will focus on the advantages and disadvantages of client-side rendering and server-side rendering. Client-side rendering has better subsequent page loads, while server-side rendering is better for initial page load and provides content faster. Client-side rendering does a good job after the initial page load work is done.

Now let's get to the next step of the story. Now the next step would be now Bob remembers, oh, I don't have anything, so let me take some help. So Bob takes helps from his sister, Sarah. Now, Sarah has like, Sarah is also very passionate about building sand castles at beach and like she's like very well equipped. She has like, like these good sets of tools, like you know, a shovel, like, like a basket and like she can do things like very, very quickly and easily. So Bob takes her help. And there's now like Bob just gives everything as a responsibility to Sarah. And he says, like, yeah, build the castle for me and like I'll just use it. And now if you understand the analogy, this is now what SSR is, right. So SSR or server side rendering is where you tell the server that I don't want to do stuff myself rather, please help me build the website for me. Right. So now how it will differ in the in, in terms of the timeline is now whenever I'm requesting the server for a website or like a webpage. The server is not giving me the resources like HTML and CSS. What it's doing is like it's creating the final HTML output on the server in itself. And I get that HTML output on the client. Now when I get that HTML output, I use like, like now then like now I see like something on the page. For example, like, if there is something that does not have JavaScript, but there are some, you know, very static content like some about sections of a page which do not usually have interactivity with them. So this is like a bare minimum that I can give my users on the face so that like they are like not staring at a blank screen. And when the JavaScript is available, like when the client now request for the JavaScript seeing the HTML, now I can hydrate my application and it actually becomes like totally ready for users to interact with as well. So this is basically what server-side rendering does, right? So far so good. I think we all know all of this basics. Now what I want to divert this story towards is what we want to focus towards in this talk. Like, what are we all know like there are tons of advantages and disadvantages of every type of paradigm that we have here. Right. So let's like look at them like one by one, very quickly. So if you see like, I'm not going to tell you like some patterns of both of these techniques and like what are the pros and cons in a nutshell. So, if you see one client-side rendering has like better subsequent page loads, whereas for server-side rendering, it's better for like an initial page load, so it can give you content faster in compared to client-side rendering because like, you know, it has to prepare everything from scratch and it's end on the browser. And secondly, client-side rendering does a good job after the initial page load work is done. Right. So, if you go to like different routes and you try to see different pages, only that JavaScript is refreshed, which is actually needed.

4. Server Components and Rendering

Short description:

Server-side rendering can lead to high server-related costs, while client-side rendering is better for search engine optimization. However, client-side rendering requires rendering and creating web pages on the browser repeatedly, making it bad for SEO. On the other hand, server-side rendering is good for static pages but takes more time to render with interactivity and JavaScript. Server components, introduced by the React team, abstract both client-side and server-side rendering, providing an intermediate abstraction format. This allows for faster rendering and the flexibility to choose where to render components on the client or server.

So, like a lot of refetching is saved because you already have like majority of the stuff on your plate, but with server-side rendering, every time you like go to the page or like maybe you refresh the server-side rendered app, it has to like do all of this stuff every time again and again. So, it can lead to like high server-related costs as well.

Now, like client-side rendering applications are great for like creating PWAs while like the client-side rendering is better with search engine optimization. And the fact is really simple because it has like you're showing something on the page and the web crawlers, or the different APIs can like have access to that information so that they can show it on the websites. So, so far, like we have like these set of advantages. And if you see like disadvantages, again, like client-side rendering does not have what SSR has like initial page load. what client-side rendering is having like, like subsequent payload. You have to do like rendering stuff and creating the web pages on the browser again and again. And client-side rendering is again bad for SEO, which we already mentioned in the advantages section while SSR is, you know, good with stuff like, like things like SEO. So like with, with that in place, let's like just make all this list a little bit shorter and focus on only these two things.

So if you see one thing is good and one thing is, and the same thing is like, which the other technique is not good at, right? So in this case, one has a good initial payload, but the other one does not. It is good with subsequent payload, page loads. One is good with, you know, with static pages, for example server-side rendering, because if you have interactivity and JavaScript in that, like it's again, going to take some more amount of time to render your page on the server. Because again, JavaScript is going to take some time. But in case of client-side rendering, it's good with dynamic pages, right? Because you're like rendering everything on your end on the browser, right? So far so good. It's simple. So we know that, okay, one thing is good and one thing is not, in some other techniques as well. So like, you know, you don't get the best of both of the worlds, right?

Now, imagine another part of the story, and this can be the, you know, maybe the climax of the story. So let's say now, instead of Bob calling his sister, maybe what would be better if like, maybe Bob had access to all of these, like, you know, really, really cool tools to build the sand castle, right? Like, if you would have like access to all of them, like he could maybe choose like, you know, how to like putting it in our analogy how to basically get both of the advantages, you know, having somebody else to help bring the castle versus how we can build that stuff together. So maybe he can like merge both of these benefits and disadvantages together with only the set of tools maybe. Right. And this is basically the, you know, what server components are that the React team has introduced. Right. So, several components are like a new. So if you talk about in, you know, technical terms, so several components are React's new way of abstracting both the goodness of client side and server side rendering, which actually like instead of giving you a page or like HTML CSS or like something as an HTML kind of an output, like both these techniques do, it gives you some intermediate abstraction format that you could say, where it can help render things faster and it can help you choose what is it that you want to render things on the client, versus what you want to render things on the server in the same page, because server side rendering does not allow you to. So let's try to look at how server components is changing these things, right? So let's again, see a very simple diagram of a client and a server. Now, so like client again requests for a webpage. Sorry, server gets, now server is again doing some part of server side rendering. It's actually rendering your server components on the server. And now, instead of giving you this output, it does not give you your HTML or like server side rendering, some output that you can directly show to the browser.

5. Server Components and Automatic Code Splitting

Short description:

It gives you a special format of data for React to render components faster and merge changes back to its Virtual DOM tree. Server components are rendered on the server, reducing the bundle size on the client. This technique combines client-side and server-side strategies, allowing for flexibility in rendering. Automatic code splitting simplifies component lazy loading using React.lazy.

It gives you some, you know, a very JSON-y or like it's a very weird type of format, but it gives you a special format of data. Now, this is not for you. This is for React to figure out how it can render these components faster and like merge all of your changes that it has made on the client, merge them back to its Virtual DOM tree, right? So this is like the simplest way that you can put it.

So it renders some parts of your page which are server, like server components. It renders them on the server. It gives you some data and it finally like generates, like your, your, your client actually is going to do some rest of the stuff. It's like not that much heavy, but it can do that part much faster than client-side rendering. All right.

So talking about the pros and cons of all this stuff is what do you get basically out of this technique, out of all of this FSR. So one thing is you get zero bundle size and you are right when you're hearing that. So server components are running only on the server. So you never ship the JavaScript that we have run on the server. So all of the components, you can like maybe a thousands or hundreds of components, none of them actually get shipped to the client, which is exactly zero bundle size that also in this example you might have been seeing, Dan Avermoff had also shown in one of the talks. So this is one of the very biggest pros. It like helps you make your client's side bundle be a lot more smaller. And also as I've been saying this whole time, you get the best of both worlds, which is both client-side and server-side strategies combined in one technique. So imagine something like this. You have a tomtree. You can have something that is being rendered on the server. There is something that is being rendered on the client. We talk about the implementations, how you can do that. But you can tell React that, okay, some parts of my web application are to be server rendered. And in the same page, some of them have to be rendered on the client side. So you can give that indication now to React. So which was not there on server-side rendering, and now React will handle the rest of what parts to work on on the server and what to just skip it and let the client handle. So this is a very magical and a very powerful thing to do. All right.

Going to the next thing is automatic code splitting. Now, I personally like this because, you know, like currently you would see, we have to write a code which is something like this. You have a plain React.lazy library, and you can lazy load your components as or need them, right? So you have to like write some stuff.

6. Using Server Components

Short description:

With server components, React.lazy APIs are no longer needed as the server handles code-splitting. Server components are used for data display and fetching, while client components handle interactivity. Server components can render other server or client components, but only serializable props can be passed between them. To use server components, create a .server.js file extension to indicate the component will be rendered on the server.

So, with server components, those React.lazy APIs, they go away because they handle this for you. Now, if you see in this example, like I'll just maybe go to the previous slide and show you. So you had old photo renderer and new photo renderer, these two components, which were like client components, and you were lazily loading them. But now, since everything is being rendered on the server, so server components, like on the server, they can actually segregate all, like what all client imports do you have, which are not being used while rendering your final server component, that can compose of your client and the server. So it can actually do that code-splitting stuff for you. For example, in this case, if the feature flags like new use photo renderer is true, only new photo renderer component is going to be loaded as part of the JavaScript here and not the other one. All right.

Going to the next step is you like, if you like imagine this scenario, you have your components which were earlier on your client but now we have shifted these very React components from this client side to the server. So like since we are like very close to the server, now we can have like more faster and like direct calls with the server and the response that we can get from the database, it can much more faster I would say as compared to the usual fetch calls that we do. So it's super fast than that. All right.

There are some things that we also cannot do, which is with like, although you can use like client and server components, both like in conjunction on the on the server things like states effects, which are usually like the things of client components. Server components do not support that. So these things are something that you cannot use. They're a very good thing. If you want to imagine something, server components are usually used for displaying some data or like making some fetch calls or doing sort of data fetching. Whenever there is interactivity involved, you would go with client components. So I would like just say there is the thumb rule, data fetching or display stuff with no interactivity, server components, interactivity and like more richness, you have to go with that's how we need to segregate those two. The next thing you have to, like if you like you can have server components and you can also render either a server component inside a server component or you can render a client component inside it. But only like you can also like pass props from like server components to client component, but only the props, which are serializable over the network, because the server components are not rendering on the server. Like they're gonna, sorry, the server components are rendering on the server and the client components are not. So you have to, like, if you want to share data between them, they have to like, go through the server link. So only the serializable data, like, you know, objects and strings, numbers, things like that. They can like be easily be serialized. But things like, you know, functions, you can't, you can't use them as like, you can't like pass them as a prop. So this is one limitation. So, okay, now, yeah, now let's see how to actually use server components. Like what do you need to do to get just get started? In React like, I think many of us might have already seen the talk of like how React team had been demoing it. But like, you can use a .server.js extension to indicate as for the example that React had mentioned, how to create a server component. So this is an indication that this component is going to be rendered as a server component on the server.

7. Next.js and Creating Components

Short description:

Next.js allows you to create server components by default for everything inside the app directory. You can use the 'use client' directive to create a client component instead. This directive tells React to render the component on the client rather than the server.

Next.js does it in a different fashion. So it has like, it tells you that, okay, everything that you create inside the app directory, that's going to be a server component by default. Although you can do also like you can do some tweaks, you might be wondering like, how do I like create a client component if I want to create a server component? Like how do I like, you know, choose between the two. So you can just like one line, which is use client directive. Now this is going to help you just tell the React that, okay, this is nothing. It's not going to be rendered on the server, please render it on the client. And that's how it makes that distinction.

8. Demo and Server Components

Short description:

Let's go to the demo and see how things work. The demo is a simple API call that fetches a dev joke. Client-side rendering shows static data first and fetches the question and answer later. Server-side rendering prepares everything on the server, eliminating blank screens. Server components provide an interesting alternative. Let's open our DevTools.

All right, enough talking. Let's now actually go to the demo and like see how things are up. Now I've opened this very small demo here as a separate page. And this shows you a very simple thing. It's just an API call that I make on every reload, and it just shows you a dev joke. Like you have a question, and then like it just gives you a punch line or like an answer. Like in this case, like why do assembly level programmers need to know how to swim? Because they work below sea level. Nice one.

So this is how the basic demo is. So if you see like the disadvantages that we had been thinking about client-side and server-side rendering. So client-side is actually rendering things upfront when it gets the data. So like how you would, how you can like test it is if I refresh my app here, I would see that there is some static data that I can get as part of HTML, but since Javascript is not gonna be loaded, I might not get all of this stuff. Which is like the question and answer that I'm fetching as an API call. So if I refresh, you would see for some time, I don't get the question and answer. I just get the static content that I've hardcoded because that's how client-side rendering works, right? It is still getting data from the server and when the Javascript is there, it's gonna render things out. It's gonna build the sandcastle on up front. So that's how this happens. You guys already know how server-side rendering is gonna behave in this case, I guess, no? So now we are preparing everything on the server. We are not waiting for, we are not doing that thing on the client. So if I now refresh this page, I should not see a blank area, I should see this up front. So if I refresh, you see, oh, okay, maybe I think I'll just restart. Okay, something with the older build, I don't know. Okay, let's see if this restarts. Okay, yeah, here we are. So if I try to refresh, you'll see, I see the data, like I see everything up front, I'm not waiting for like a blank screen or like my JavaScript to run on this client or something, I'm preparing everything on the server, shipping it out. So that's how things are happening.

All right, now how server components are different with this. So now let's see some very interesting things now. Okay, so let's open our very old DevTools.

9. Understanding Server Component Rendering

Short description:

Let's open our DevTools and see what is actually being sent from the server to the React client. The server sends an intermediate communication channel to merge the rendered components onto the client, minimizing the client's work. Another example shows how client and server components can be used together. The server component does not ship anything to the client, resulting in zero bundle size. This is the power of server components, allowing customization of rendering on the client and server without repetition.

Okay, so let's open our very old DevTools. And let's see what is like basically what actually is it sending you? Like how is it actually working? Now if I refresh this page, you'd see I'm like still getting like I'm still getting kind of the like the data because it's actually preparing things for me as like a server side rendered app. Right. And if try to see what is it actually sending you. Right. Is. Let's go to the. Yeah. So this is what it's actually sending you now. It's like you know some weird set of things that it is using but it's you know an intermediate communication channel between the server and like the React on the client to tell you how to merge all of these things that are rendered on the server onto the client so that the client has to do like minimal work. So this is like what it is actually sending. Right.

Now let's also try to see and I think I have like another example to explain it. Now we talked about how client components and like how several components can be like you know used in conjunction on the server. Right. So if you see I have like a child like a like a client component as a child which I'm not rendering on the server and inside it I'm rendering a server component. Right. Now ideally like from theory point of view we may be talk that the server component it should not ship anything on the client. So I should not see anything in my job. So what webpack is compiling but I might see something on the client. But this line child component or do I need this? Let's go to sources go to webpack. Yeah. So if you see there was an app and it only has a client .psx file which is only for the clients component which was like we had added this everything on the server but react just gives this on to the browser that please render this down as a client component but you don't see any code that is ship for the server component. So there is absolutely zero bundle size you don't ship anything as part of your job set to the server component but the client component it gives you. So it's like very much customizable. Okay so this was one thing. So yeah I think I covered most of this. So yeah this is actually the power of server components. It lets you customize basically what you want to render on the client what you want to render on the server and like not doing all the stuff like again and again. So you get like again like what you are like talking about.

10. Advantages and Tradeoffs of Server Components

Short description:

Server components have advantages, but there are tradeoffs to consider. It's not recommended to use them in production apps yet, as they are still in the experimental stage. Next.js is a good starting point to try them out. Watch the React team's YouTube video and check out the official Next.js documentation and Zenstack article for more details. Feel free to explore the demo code and reach out for any issues. Postman is also hiring.

The best of both worlds is like what makes the strategy so much beautiful. Okay so with that being said. Now let's talk about some more stuff. So you might be thinking server components are so great like you can fit like basically they don't have any disadvantages now do they? Like you can like I can use them anywhere any place any time and like my websites are going to be like super performing but like everything has a downside to it though.

So like again like this strategy also has its tradeoff but like most importantly than tradeoffs that we had I think discussed like it being able to use effects or state updates or like you still need a server so like it's maybe it's again or like hamper your server related costs so like those parts are also there. But I think more importantly I would not recommend trying them out in the like trying all of these things in the production apps itself because the current status is I think React team is still like they're doing like a absolutely great job in gathering feedback and being super transparent about their findings and research but it's the same experimental stage in React and if you want to try it out NextJS like you can get started with it with NextJS and this is how I had built this demo itself So it's super easy to use, I would really love for you to give it a try.

A few like if you want to like go like full on through this thing I would really recommend watching this YouTube video from the React team where they have actually demoed you and explained the problem in like in more of details and also explain things up with a really like another very cool demo so I would really love you to try that out and again there is some cool documentation that I personally found like very useful and like it's so simple to understand things for example the official Next.js documentation and also there's a very cool article by Zenstack on to server components and like how you can actually get started with it a lot faster so I would definitely give it a recommendation here.

Okay. The code for this demo you can find it out on the slackbits url so feel free to fiddle with it try to break it do whatever you want to do with it so it's always fun to learn this way and feel free to like shout out at me whenever you see any issues any problems over like Twitter or like other channels. And one of the very last things is like these are some similar sorts of interesting problems and problem spaces that we keep on working with in Postman. So we're also hiring and if you if you folks would want to get part of this journey so feel free to reach out to the careers website and connect cool. This is mostly it that I want to discuss. I hope you folks are enjoying the amazing sets of conference like amazing sets of talks that we have in the event.

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

React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.
In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick
easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data
use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time

React Summit 2023React Summit 2023
32 min
Speeding Up Your React App With Less JavaScript
Too much JavaScript is getting you down? New frameworks promising no JavaScript look interesting, but you have an existing React application to maintain. What if Qwik React is your answer for faster applications startup and better user experience? Qwik React allows you to easily turn your React application into a collection of islands, which can be SSRed and delayed hydrated, and in some instances, hydration skipped altogether. And all of this in an incremental way without a rewrite.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Workshop Free
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
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.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Workshop Free
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.

React Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
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 🤐)
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Workshop Free
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

React Summit 2023React Summit 2023
152 min
Designing Effective Tests With React Testing Library
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents
- The different kinds of React application tests, and where component tests fit in
- A mental model for thinking about the inputs and outputs of the components you test
- Options for selecting DOM elements to verify and interact with them
- The value of mocks and why they shouldn’t be avoided
- The challenges with asynchrony in RTL tests and how to handle them
- Familiarity with building applications with React
- Basic experience writing automated tests with Jest or another unit testing framework
- You do not need any experience with React Testing Library
- Machine setup: Node LTS, Yarn