Treat your users right with Segmented Rendering

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
Slides
Rate this content

If you think that static rendering is limited to generic and public content that is the same for every user of your website, this talk is for you. Segmented Rendering is a new pattern for the Jamstack that lets you personalize content, statically, without any sort of client-side rendering or per-request Server-Side Rendering. Get the best possible performances for use cases such as theming, internationalization, A/B testing, multi-tenancy, and start treating your users right!

This talk has been presented at React Advanced 2022, check out the latest edition of this React Conference.

FAQ

Segmented rendering is a technique in web development where different versions of a webpage are generated and served based on user-specific segments. This approach allows for personalized content delivery, such as different themes or languages, while optimizing performance by using static rendering for these personalized contexts.

Next.js supports segmented rendering through its edge middlewares and static generation features. It allows developers to create multiple versions of a page based on user segments, such as theme preferences or language settings, and serve them efficiently using URL rewriting techniques that are invisible to the user.

Next.js incorporates three main types of rendering methods: client-side rendering, server-side rendering, and static site generation. Client-side rendering happens in the user's browser, server-side rendering is processed on the server per request, and static site generation is done at build time, creating static files for faster delivery.

Cookies are crucial in web personalization because they store user-specific information which can be used to deliver personalized content. They are automatically sent with every request, allowing the server or client-side JavaScript to recognize user segments and tailor the content accordingly.

URL-based personalization can lead to issues such as users modifying URLs to access unauthorized content or the URLs becoming long and unwieldy. These challenges can be addressed using a lightweight proxy server to rewrite URLs server-side, ensuring parameters are invisible and secure from user tampering.

In segmented rendering, a lightweight proxy server plays a crucial role by rewriting user requests based on their segment, such as a theme or language. This server-side rewriting keeps the URL parameters invisible to users, enhancing security and user experience without compromising URL length or visibility.

Next.js manages the dynamic nature of personalized content through incremental static regeneration. This feature allows pages to be updated after the build time in response to user interactions or data updates, combining the benefits of static generation with the flexibility of dynamic rendering.

Eric Burel
Eric Burel
21 min
24 Oct, 2022

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The Talk discusses the concept of segmented rendering for personalization in web development. It explores different rendering techniques, including server-side rendering, static seed generation, and dynamic rendering. The issue of rich guests and poor customers is addressed through segmented rendering. The implementation of segmented rendering with Next.js involves a lightweight proxy server and URL rewriting. The Talk also highlights the benefits of invisible server-side rendering and suggests a future unified API for server rendering.

1. Introduction

Short description:

Hello everybody and welcome to my talk, Treat your users right with segmented rendering. My name is Eric Burel. I'm the founder of LBKE, a small company in Montpellier, France. I'm a web developer but I'm also a consultant in public funding for research to business. I'm the maintainer of VulcanJS, a framework you might know if you come from the Meteor.js ecosystem and that is now running on Next.js and GraphQL.

Hello everybody and welcome to my talk, Treat your users right with segmented rendering.

First, let me introduce myself. My name is Eric Burel. I'm the founder of LBKE, a small company in Montpellier, France. I'm a web developer but I'm also a consultant in public funding for research to business. I'm the maintainer of VulcanJS, a framework you might know if you come from the Meteor.js ecosystem and that is now running on Next.js and GraphQL. I'm a member of the DevoGraphics Collective created by Sacha Gref who runs the State of GS, CSS and GraphQL surveys. I'm in particular in charge of the survey form where you actually fill the survey and I am teaching Next.js at Human Coders, a teaching company in France. You can meet me on Twitter or on Medium where I publish a few articles on various subjects, namely Next.js and GraphQL.

2. Personalization and Rendering

Short description:

I'm going to talk about personalization and explain what is the segment in segmented rendering. Web personalization includes examples like theming, internationalization, paid versus free content, and A-B testing. Next.js is a framework that offers three ways of rendering applications, including client-side rendering.

I'm going to talk about personalization to explain what is the segment in segmented rendering. So what is web personalization? Let's take an example. Picking a theme is the most basic example and the most visible example of web personalization. Let's say that in my application I have three possible themes fire, water and grass and each theme will change the display of the application. To implement theming, most often I will use a cookie. This is very common for web personalization to store some specific information about the user in a cookie. Why? Because they are automatically sent alongside every request and if they are not HTTP only they are also available to the javascript code. So they are very useful to keep information, to tell who is the user. What's their segment? In which category they belong for instance. So here I could have a cookie named starter with three possible values fire, water and grass.

Okay and depending on the value of course I pick a different theme in the application. But it's not the sole use case. There are many use cases of web personalization. We have this same in use case but also internationalization. It's a case of personalization that we we sometimes forget but when we change the language of an application to adapt the language of the user we are doing what we call personalization. We are optimizing the website and the user experience depending on their characteristics. The language we think they talk or the language they selected in a menu. This is personalization. Having paid versus free content is also personalization especially for instance if you have only the beginning of an article before hitting a pay wall. This is personalization in a sense that unpaid users have a different experience from paid users. Paid users have their content and unpaid users are invited to get a subscription. They have a different experience, a personalized experience, and they belong to different segment guest users and paid users. A-B testing is also a very important use case, maybe more advanced, but if you make a lot of money out of a website you probably have set up already A-B testing because it helps you test new versions of your website incrementally without affecting your whole user database. So most often we have two segments that are actually named buckets in A-B testing environment, A and B, and you have two different of the website A and B depending on the on this segment.

Let's come back at our use case rendering the right thing. Let's talk about Next.js because Next.js is a very interesting framework when it comes to rendering because it embeds three ways of rendering applications. The first one is client-side rendering. This is the most common This is the most common way to render content in modern JavaScript applications, in software as a service, because it's very dynamic. It happens in the user's browser so you can do a lot of computation there. It's just using client-side JavaScript and to get data to fill the content of the page, it will be used to browsers built-in like Fetch or libraries that are themselves built on top of these built-ins like SWR in the Vercell ecosystem.

3. Rendering Techniques

Short description:

Server-side rendering is the polar opposite of client-side rendering. Static seed generation is a middle ground that allows for generating multiple versions of a page based on parameters. Dynamic rendering, such as client-side rendering, allows for real-time updates but requires more computations. Static generation, while not adaptable to individual requests, is faster and can be tempting for personalization.

Server-side rendering is the polar opposite. You are doing everything on the server for each request. This is closer, for instance, to how PHP works. When you do a request it will hit a page that is a template. The server will fetch some data from the database at this point and will fill the template with the right values, and you end up with your rendered page that is then sent as-is to the browser as pure HTML.

And you have static seed generation, which sits in between, which is basically just server-side rendering, but not paired request, but computed at build time. It's similar in a way to just writing HTML. You could just write the page. But of course, it would be quite dumb to write the content directly. So static seed generation lets you do this at scale. You have the same page, and the static seed generator is able to generate multiple versions depending on some parameters you input, like the language, the theme, and so on.

They divide into two categories. The first one would be the dynamic ways to render a content. Client-side rendering and paired-request server-side rendering are dynamic because server-side rendering happens for each request. So the data can be updated every time the user refreshes the browser, at least. Client-side rendering is even more dynamic because it can be interactive, since it operates on the user's browsers. It can do computation any time. It doesn't even have to talk with the server. So most often you have this pattern, this jam-stacked pattern of calling APIs to get new data and rendering everything client-side. This is very jam-stackish way of doing things.

Static seed generation is well static. Because things are computed at build time, they cannot evolve for each request because you don't have the request yet. No one requested your server, you are just building it and deploying your server at this point. But it's faster because things are already computed and stored in a cache, so there is no new computation. The server just has to serve the computed HTML. And what will you use for personalization? You might be tempted to say dynamic patterns because they can adapt to the request because they can happen in the user's browser, so literally on their machine. It's easier to adapt and to personalize for a precise user, of course. However, they are slower. They need more computations. So you also have the choice to use static generation, but how? It's faster, so it's tempting.

4. Segmented Rendering for Rich Customers

Short description:

Using dynamic and slower rendering for personalized content creates a rich guest, poor customer issue. Unpaid visitors and guest users receive faster static renders, while authenticated customers with personalized content experience slower rendering. Segmented rendering addresses this issue by enabling static renders for personalized content.

But how? Again, since it doesn't move, how do you do that? And using systemically the dynamic and slower solution leads to an issue that I call the rich guest, poor customer issue. You will use the faster static renders only for public content, for content that is available to anyone surfing the web. So unpaid visitors, guest users, as well as connected users. And you will use the slower dynamic renders for personalized content. You will do use CPU time from the users, if you do client-side rendering. You will have slower computation on the backend if you do pair requests server-side rendering. So basically your customers that are authenticated, that receive personalized content based on their own personal data, have the poorest pattern, the slowest pattern. They are poor customers, while the guests that provide most often less value on the website because they are not connected, you don't know them, you can target them, they are not customers, they have the best experience. They are rich guests. This is the rich guest, poor customers issue. And segmented rendering is a way to reduce this issue by enabling static renders for personalized content to have rich customers.

5. Personalized Staticness and Proxy Server

Short description:

Let's talk about personalized staticness using segmented rendering patterns. The easiest implementation is to have one URL per segment, one URL per theme choice for users. But it leads to some issues. Users shouldn't be able to tell in which bucket they are. The URL can become long and ugly. To solve this issue, let's introduce a simple, lightweight proxy server.

So let's talk about personalized staticness using segmented rendering patterns. Let's do a first try, let's try to use the URL to personalize the content statically. It's very easy because most static seed generators rely on the URL, be it next.js, or Gatsby, or Astro, and so on. You give them URLs to render, and depending on the parameter, they will fetch the correct data and render the page accordingly. That's how they work.

So it's the easiest implementation, is to have one URL per segment, one URL per theme choice for users. So users that picked the fire theme will have one version, water theme one version, and grass theme one version. But it leads to some issues. First, the user can change the URL. It's okay for a theme, it's okay for a language. It's even a feature in a way, for a language. You can change the language of the page by just changing the URL. But it's a problem if you start doing personalization with paid content. You don't want users to change the URL to suddenly become paid users. You'd rather want them to pay for something. Then the user can see the parameter. Again, not a problem for a language, it's even a good thing for a language because it allows sharing the URL to other people speaking the same language with the language in the URL so they get the right content. But for an A-B test, that's a huge issue. Users shouldn't be able to tell in which bucket they are. Otherwise, you are drastically biasing the A-B test. It leads to a lot of issues and the data are just not valid anymore. So they shouldn't see the parameter in this case. And finally, the URL can become long and ugly. If you have a lot of parameters, you will end up with the language, the dark or light theme, the tenant, the company, the organization the users belong to. If you are doing business to business, it's very common to have multi-tenancy. To have multiple companies using your application with a lot of users per company. You will have the A-B test bucket, which is not good, paid content and so on. You have very long and ugly URLs.

So, to solve this issue, this limitation, let's introduce a new piece in our architecture. Let's introduce a simple, lightweight proxy server.

6. Proxy Server and URL Rewrite

Short description:

The proxy server rewrites the URL based on the segment, making it invisible to the user and protecting it from being changed. The length and appearance of the URL are no longer an issue, and there are advanced patterns to compress parameters if needed.

The role of this proxy server will be to take the HTTP request that hits the server and to re-write the URL, depending on the segment. I insist on the word re-write the URL, and not redirect the URL. A URL re-write is not visible to the end-user, and that's the key difference, because it solves all our issues with the URL at once.

The user cannot see the parameter anymore. The user cannot change the parameter anymore, because it's protected by the server, it's computed server-side. So the user cannot hack it by just changing browser values. And finally, the fact that the URL is long and ugly is not a problem anymore, because the users do not see it anymore. You can reach the limitation of 255 characters for URL, but in practice this will never actually happen. And even then we have more, even more advanced patterns to fix that. It's linked in the resource it's called the Megaparam patterns. Basically, you can encode the parameters to compress them. So there is solution even for this slight limitation.

7. Segmented Rendering and URL Rewriting

Short description:

To solve our issue, we convert the cookie into a URL parameter compatible with existing frameworks. This is called segmented rendering, where each variation has a unique URL. For example, for internationalization, the accept language header can be used to rewrite the URL to the correct language, eliminating the need for an explicit language parameter. Users can change the language using an invisible cookie instead of a visible URL parameter.

So to solve our issue, we have an HTTP request with the cookie fire and we turn that into a URL parameter fire, which is compatible with how existing frameworks work because Gatsby, NEFGS will be able to statically render content as long as the URL for each variation is unique. This is what we call segmented rendering. This is a recipe with two ingredients having one URL per segment. This is just how static rendering works. If it generates multiple variations of your website statically, you already do this but the trick is to use a tiny URL rewriting server to redirect to the right URL depending on other parameters of the request like the cookies or the headers. If I take another example with internationalization you could use the accept language header and rewrite the URL to the right language. This would remove the need from having an explicit language parameter. You still need a way for users to change the language but you could do that using a cookie that is invisible instead of using a URL parameter which is visible and in some scenarios might be ugly.

8. Implementation with Next.js

Short description:

Let's take a look at an implementation with Next.js. Our application uses segmented rendering to allow users to pick a theme. The theme is stored in a cookie, providing personalization without altering the URL. The page is statically rendered with the chosen theme, and the server response confirms the correct theme. The implementation involves static seed generation and incremental static regeneration for flexibility. The middleware, a lightweight proxy server, reads the theme cookie and writes the URL. This achieves segmented rendering without the need for a root parameter.

Okay so this might sound a bit abstract. So now let's take a look at an implementation with Next.js which is very interesting because it allows Next.js embeds the concept of edge middlewares that are exactly that. The proxy server that we need to implement segmented rendering. They provide that out of the box.

So here is our application using segmented rendering. It's a Next.js application that lets me pick a theme fire, water or grass. Okay so let's pick the fire theme. You will see that it changes the color as expected. The interesting part is that it doesn't alter the url. First, so if I go to application and check the cookies for this application I will see that I'm relaying on the theme cookie name fire instead of using a root parameter I'm using a cookie which is the right way to do personalization in many scenarios. Second interesting fact is that if I reload the page I will get the themed version already. Of course this is all statically rendered so for instance if I go to the network and I check the response of the server for the html request I will see my content with the right theme. So here I've not configured the the CSS for server-side rendering but I can see the fire theme in the html already so I'm indeed using static rendering. This is computed in advanced server-side there is no client-side computation happening.

Regarding the implementation the first piece is just a page with static seed generation as you would find in any Next.js application using get static path, get static props as usual. I generate different version of the page depending on the theme parameter. Notice that I'm using incremental static regeneration which is just a pattern in Next to understand the Next to handle the case where I have a lot of themes. For instance, here I'm not pre-rendering the green starter because maybe this is less requested by people and I don't want to have a very long build time so it will be computed only on the first request. So we have a lot of flexibility with this approach. And then of course I render my page based on this parameter. This is very usual if you use Next.js or any other static rendering framework, you will be used to this approach. But the most important part is the middleware. This is my proxy server. And when I mean tiny and lightweight, I'm not joking. It's 25 lines with a lot of commands. What it does, reads the cookies. If it's a valid theme, it will write the URL. Okay. As simple as that. This is how I get segmented rendering, so static rendering with personalization without using a root parameter.

9. Invisible Server-Side Rendering and the Future

Short description:

This part discusses the security and benefits of invisible server-side rendering for personalized themes. It also mentions the implementation example and the use of segmented rendering at the edge. The conclusion highlights the importance of caching in server-side rendering and suggests a future unified API for server rendering.

This is invisible to the user and this is secure because it's happening server-side. I can't let the user pick a theme that does not exist, for instance. They can only select fire, water, grass, or none. Otherwise, I throw an error. This is secure. It's great for paid content, A-B test, for instance.

Finally, just a detail, but that's optional, I've added some logic to switch the theme based on a cookie using an API root. So, I'm using the set cookie HTTP header, but you could do the same client-side, of course.

Let's get back to my slides. So, now you have an example of the implementation, and in Vercel, you might have a different wording. They won't call that segmented rendering. They will call that edge personalization. And it's actually the Vercel translation of this pattern. This is the same thing, except that Vercel is allowing you to have segmented rendering at the edge using its edge network. But it's basically the same idea.

Short conclusion. What's the future of server-side rendering? I think the future of server-side rendering is understanding that it's all about caching. Static is server-side rendering cached at build time. Per request, server-side rendering is just a cache miss in the same pattern. The cache key is not just the URL, but the full request. This is the idea behind segmented rendering, to use the request and not just the URL. And the value is of course the rendered HTML, or the data. It depends on the pattern. Gatsby deferred static rendering, for instance, is untying both and Next.js is always considering them as a whole. They are very tightly related in Next, but either way, that's the cache value. So my take is that in the future, we will have a unified API for server rendering that encompasses static PairRequest and everything in between. And until that, we have segmented rendering.

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

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.
Scaling Up with Remix and Micro Frontends
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Top Content
This talk discusses the usage of Microfrontends in Remix and introduces the Tiny Frontend library. Kazoo, a used car buying platform, follows a domain-driven design approach and encountered issues with granular slicing. Tiny Frontend aims to solve the slicing problem and promotes type safety and compatibility of shared dependencies. The speaker demonstrates how Tiny Frontend works with server-side rendering and how Remix can consume and update components without redeploying the app. The talk also explores the usage of micro frontends and the future support for Webpack Module Federation in Remix.
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.