How Hopin is Moving 10x Faster: Microfrontends at Scale

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Hopin is the fastest-growing startup in the world. Many engineers join every month. Companies with different technologies are acquired every other month. It brings many challenges to our front-end architecture. In this talk I'll explain how we're breaking up our React monoliths and enabling interoperability using multiple React trees and reactive variables.

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

FAQ

The speaker is Alex Lobera.

The main topic is how Hoping is moving ten times faster with micro frontends at scale.

Alex Lobera works for Hoping as a senior staff engineer.

Micro frontends are an architecture where apps are broken into a collection of smaller apps that are organized around business capabilities, owned by small teams, independently deployable, and loosely coupled.

Hoping uses micro frontends to allow small teams to work quickly without stepping on each other's toes and to mix and match technologies across different products.

Hoping uses React, while another acquired company, Jam, uses Vue.

Hoping uses webpack's module federation to pull dependencies and integrates them at run time, mounting them on independent component trees.

Hoping uses a very lightweight store that enables teams to share some state without deriving state, unlike more powerful tools like Redux or Recoil.

Hoping scopes and namespaces styles to avoid global state and ensure styles remain independent for each app.

When Alex Lobera joined, his product area had 12 engineers, and now it has around 60 engineers working on the same Exodus app.

Decisions are made bottom-up, where people identify problems and propose solutions, which are then socialized and adopted by other departments.

Alex Lobera
Alex Lobera
25 min
22 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses how Hoping uses micro frontends to improve development speed and create boundaries between applications. They break up apps into smaller, independently deployable apps owned by small teams. They use webpack and module federation to integrate dependencies at runtime and have a lightweight store for sharing state. The Talk also addresses performance concerns and the importance of explicit contracts and namespace styles to avoid conflicts between micro frontends.

1. Introduction to Micro Frontends Architecture

Short description:

Today we're gonna be talking about how Hoping is moving ten times faster with micro frontends at scale. In order to understand the architecture, you need to understand the context. Hoping has acquired different companies. We have an example. The way we organise is by product areas. Then we have teams that work on those products. Companies have technology stacked. In the case of Hopping, we use React. Jam uses Vue. We might want to mix and match technologies across different products. Very important, teams work in the same UI. We have small teams, and you can have a single page that has different features, and every feature is owned by different teams. All together in the same page. We want those teams to be able to work very quickly without stepping with each other's toes. So now what's our definition of micro front-ends? So for us, micro front-ends is an architecture, and we think of it as a software application where we break up apps into a collection of smaller apps, and they have a series of characteristics. First, they're organised around business capabilities. They're owned by a small team. They're independently deployable, and very important, they're loosely coupled.

Great. Well, thank you, everyone, for joining my talk, and thank you React Advance for having me here today. We're gonna run a little experiment. My laptop wasn't working, so I have, like, I'm gonna be, like, I feel like a DJ with two laptops at the same time, and I have one connected to the other one, let's see how it goes.

Today we're gonna be talking about how Hoping is moving ten times faster with micro frontends at scale. First, let me introduce myself. My name is Alex Lobera, and I love React, TypeScript, of course, micro frontends, salsa bachata and my partner, and not in that particular order, of course. I work for Hoping and as a senior staff engineer, and you can find me on Twitter, in Alex Lobera.

This talk is about micro frontends architecture, and in any architecture, everything is a trade-off, right? We are constantly making decisions about what's best for the job. We are weighing different options. We're in a React conference, so React weighs more. We're weighing what is the best option. In order to understand the architecture, you need to understand the context. Let me share with you the context in our application, or in our organisation. Hoping has acquired different companies. We have an example. The way we organise is by product areas. Then we have teams that work on those products. Companies have technology stacked. In the case of Hopping, we use React. Jam uses Vue. We might want to mix and match technologies across different products. Very important, teams work in the same UI. We have small teams, and you can have a single page that has different features, and every feature is owned by different teams. All together in the same page. We want those teams to be able to work very quickly without stepping with each other's toes. So now what's our definition of micro front-ends? So for us, micro front-ends is an architecture, and we think of it as a software application where we break up apps into a collection of smaller apps, and they have a series of characteristics. First, they're organised around business capabilities. They're owned by a small team. They're independently deployable, and very important, they're loosely coupled.

2. Micro Frontend Architecture and Demo

Short description:

Here we have a UI with two independent features, a chat and a user profile. Each team can deploy these features independently by building and deploying them to a CDN. We use webpack and module federation to pull the dependencies and integrate them at runtime. We have a lightweight store for sharing state between micro frontends, pushing the state logic inside each application. In a demo, we show how different component trees and dependencies are loaded based on the context of the application.

Here, for instance, we have a UI, and there is two features. I'm going to call them apps because, for us, features should be able to work independently without the context of the larger app. Here we have a chat and a user profile. Then every team is going to be able to deploy them independently. They will build them and deploy to a CDN. Then we use webpack to pull those dependencies using module federation and we integrate them at run time.

Once we have those scripts, we mount them on independent component trees. So here we have two features, two applications, so we will have two independent component trees with two routes. We might want to share some state between them. We don't encourage engineers to share a state between the microfrontend but there are some cases where we may want to do that. To do this, we have a very lightweight store that is going to enable teams to share some state, and it's a very simple store. It cannot derive a state, for instance, unlike Redux or recoil. We believe they are too powerful for this paradigm, so we have a simpler implementation that will push all the state logic inside the boundaries of each application. Again, our goal is to have a very decoupled system.

Let me show you a demo. Now is when things get funny. First of all, I'm not using my laptop. Here is the first experiment. I'm going to be switching to the other laptop. So here what we have is some React app. We are rendering it here. You can see the component tree. I can move over the tree and see that if I'm over the input, you see also the input highlighted on the UI, same for the button, and I can also look at the network tab, and I'm pulling some dependencies, I can filter by React here, and you can see I download React and React DOM because we need those to mount this application, but I can also look at this in the context of a next JS application. And here, if I look at the component tree, I can see this component, this is the next JS app, I can scroll down, and when I get to this point in the tree, I see I'm highlighting the user profile but I don't see the input and the button that I saw before. So we have this mount, I can scroll down and I can see another tree, I can see my input and my button here, so there are two distinct trees. I can also look at the network tab, and, if I filter React, I see that here I'm not downloading React or React because, in the context of the application, it's sharing those libraries with the React app. Let's have a look at this Mount Micro Front-end that is receiving some URL and some name. I'm going to switch to the other laptop. Okay, WebStorm. How do I make things larger in WebStorm? I don't use WebStorm.

3. Mounting the Application and Cleaning Up

Short description:

I receive a URL, load scripts, and mount the app on an HTML element, returning an unmount function for cleanup.

Does anyone know, like, if I do a command plus? Say again? Oh, that was so easy. Thank you. You learned something. I did. So let's go back. I'm going to look at this mount here. And I want to look at the mount function. So what I do is I receive a URL, and that URL, I will load some scripts. When this is ready, it means module federation is ready to load some script, some module in this case. What I'm going to load is the profile. And I have it in here. This is the entry point of that application. Notice that I'm not exporting components. I'm exporting a function that has an argument which is an HTML element, and what I'm going to do is I'm going to mount my app on that element, and I'm also going to return an unmount function to clean up this.

4. Decoupling Applications and Creating Boundaries

Short description:

We decouple our applications using micro frontends to create boundaries. By rendering each application in its own component tree, we avoid implicit context dependencies. We use a lightweight store called ReactiveMap provider to share state between applications. This allows us to change specific parts of the app without affecting others. We can even mix and match different frameworks, like replacing React with Vue, by simply changing the rendering location. This gives us flexibility and the ability to create boundaries.

So I can go back to the other laptop, and I'm going to look, I'm going to collapse this, and I can go to the chat. Then I'm mounting this other application, this React app. I can go back to the home page and mounting and unmounting. Why do we do all this, right? The reason we're doing this is because we want to decouple our applications, and if we render everything in the same component tree, we could potentially add some Redux or whatever on the context, and then all my small applications would use that implicit context, right? And so that's bad, right? Because if tomorrow I change the next level application Redux or something else, then I also need to change my other applications. Here for instance we have a provider, and if I want to use this provider on the other side, I will need to also add the provider in the context of the other application, and then what I will need to do is I will need to explicitly wrap it from one side and pass it to the other one, right? When I mount in this create route, I get the context from one side and pass it to the other one. So the reason we are doing this is because we want to create boundaries, and that's very helpful. That's very helpful because... Well, before... So one thing we can do is, speaking about the context, I want to show you this provider that we were looking at, this ReactiveMap provider. This is the lightweight store that I mentioned before that we use, and so I can use it, for instance, to add some name, right? I want to change the name on one side of the application, but I also want other places in my app to react to it. So if I change the name to Alex, then this reacts, which is a different application. I can look at the profiler and I can maybe add something here. Record. Save. See what happened. And only my chat was the application that reacted to it and was rendered. So this is really nice. Now we have boundaries and we can mix and match as I was saying before. Let's say we have a Vue.js chat. The purpose of the demo, I'm not saying we should do this. Let's say we want to replace React with Vue. I could go to this other laptop, and in the page where I'm rendering I'm going to change for 87, right? I have on this board I'm running the Vue.js application so what I'm going to do is I'm going to change this. And now if I go to the other app and I reload the page, I don't have the Vue.js application which is very interesting. Sorry, I got it. I'm getting confused with this laptop. So, if I change it in the right place and now I go to the other laptop, and ... And I reload this page, I have the Vue.js application. Whoo! I never thought I was going to be like getting this round of applause for showing Vue.js in a React conference, but you never know. So, I can look at the elements and select this div here where I have this Next.js application. Notice that it's highlighting the entire app on the browser.

5. Creating Boundaries and Performance Demo

Short description:

I have this Vue.js inside the Next.js application, and it actually reacts to changes. We create boundaries between our applications and have explicit contracts. I prepared a demo to address performance concerns. I have one React app that can mount many other apps. Let's do an experiment with 30,000 components and see how long it takes to render.

And I can select this, I have this Vue.js inside the Next.js application, and it actually I can also change my name, and it also reacts to it. Similar, the same experience, the same as I did before. Why is all this happening? Because we are creating boundaries between our applications, and because we have explicit contracts. As long as we comply with those contracts, everything should work.

Okay. So I'll go back here. So that's cool. That kind of works, but what if I go that path and then I have 100 applications, maybe one, I don't know, many applications, React component trees in my app. What's going to happen? Is this going to be performant? I don't know. Maybe some of you are wondering that. So I thought of preparing a demo for this. And I have this benchmark which I'm going to... So here what I have is one React app that can't mount many apps. If I look at the component tree, I have one app that can mount many other apps. You can see the create root here as we have on the other side. I can render, let's say, ten apps. So I'm mounting ten applications here. I can also say, okay. I'm going to render ten components each. Now I have ten apps with ten components. We can see the memory on the left. And on the right, we have a clock. I'm changing that using JavaScript so if the thread gets really busy because we are mounting and calculating trees, then it will freeze. So let's do an experiment. If we run maybe we don't have a lot of time so let's go straight to 30,000 components. Let's see how long it takes to render on my laptop 30,000 components. So that's going to be around six seconds. Let's do it again just for fun so I can waste a little bit more time on this. 43 is going to be around 49. Six seconds.

6. Performance of Rendering Multiple Apps

Short description:

Okay, nice. It's consistent. So what if I render 3,000 apps? How long is it going to take? It was two, three seconds. Let's do it again. Same two, three seconds. Let's do the final test. Before we render, we mounted 30,000 components. Now let's mount 3,000 apps with ten components. That's going to be the same. What did we learn here? It was faster. React will take more time to render many component trees. However, it is not only React. You also need to paint those changes, and the sooner you start painting, the faster it is. So, all in all, it won't make your app slower to do this. The point here is you don't do this, you don't break your app into many apps because it's smart, it's faster. You do it because you want to create boundaries, you want to decouple your code and your applications. Use some principles, create boundaries.

Okay, nice. It's consistent. So what if I render 3,000 apps? How long is it going to take? It was two, three seconds. Let's do it again. Same two, three seconds. Let's do the final test. Before we render, we mounted 30,000 components. Now let's mount 3,000 apps with ten components. That's going to be the same. Let's refer. What do you think is going to happen? I have three minutes left. Let's go to it. Ten. And, oh, that was interesting. Wait. Four, five. What did we learn here? It was faster. I have some benchmarks I want to share with you here. I did it with 100,000 components and a few combinations of those. As you can see, memory-wise it didn't change much. The time to display those changes was different. React will take more time to render many component trees. However, it is not only React. You also need to paint those changes, and the sooner you start painting, the faster it is. You can see, the more you increase the numbers, there is a significant difference here. So, all in all, it won't make your app slower to do this. I'm using React 17. I expect this to be probably insignificant, maybe, with React 18, but the point here is you don't do this, you don't break your app into many apps because it's smart, it's faster. You do it because you want to create boundaries, you want to decouple your code and your applications. Use some principles, create boundaries.

7. Sharing State and Using Explicit Contracts

Short description:

You can create multiple component trees and use explicit contracts to share state or context. Keep the state logic within the boundaries and avoid using powerful tools like Redux and Recoil for inter-app communication.

You can create multiple component trees. It's safe. Use explicit contracts. Oops! Use explicit contracts if you want to share a state or context from one place to another, make it explicit, get it from one place and pass it to another one. If you decide to share some state, I recommend you to keep the state logic inside the boundaries For us, we use a very simple store that cannot derive a state. It only communicates stage changes. And we believe that Redux and Recoil, for instance, those sort of tools, are too powerful for a paradigm like this. You can still use Redux but you use it inside your app, not to communicate between your apps.

QnA

Micro Frontend Styles and Contracts

Short description:

Thank you very much! Thank you. Thank you. Micro front ends, huh? We have one question from the audience. They want to know how to ensure styles don't bleed between apps, and how to enforce contracts between different microapps. Good tips are to namespace your styles and avoid using global estate. Runtime checks and TypeScript can help enforce contracts. As for rendering multiple apps with components, starting painting earlier can make it faster. The choice of tools depends on the context and requirements. It's important not to use too many laptops and frameworks simultaneously. The decision to go Microfrontend architecture at Hoppin and its impact on teams and developers is an interesting topic.

Thank you very much! Thank you. Thank you. Alright. Step into my office, pal! Let's have a chat! Let me close both laptops. DJ Alex! Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Brr- Wow! I made it! I didn't think of it. Breath.

So, Alex! Yeah! Micro front ends, huh? Yeah, that's the topic. We have one question from the audience. You can ask questions at slide.do. The code is 2225. And they want to know, how do you ensure styles don't bleed between apps, especially if apps are legacy and use global selectors? And apps aren't mutating shared packages? Well, you want to scope namespace your styles, and you want to make sure that if you use components, you want to avoid using global estate because it might have the same scope for different packages if they are completely independent. So I would say try to avoid global estate for sure. So global CSS and global styles, and namespace your classes. Good tip. Good tip. how do you enforce the contracts between different microapps? In the end, a contract is a function with arguments for us, and what you do is you can have two types of checks, runtime checks, which we do, like if you try to access something that you should not, then you will get an error, and we also use TypeScript, and the reason we use runtime also checks is because sometimes engineers will like to use TS ignore, so it's good to have a backup plan. I never use TS ignore. Me neither, but I saw it. You shouldn't either. Billy asked, is it faster to render multiple apps with components, rather than the other way around, because of how React reconciles changes? Large tree versus multiple smaller ones? I don't know the exact answer, but my hypothesis is that you will start painting earlier, as opposed to calculating more things, because what is slow is painting the UI, not JavaScript. JavaScript is much cheaper, if you like, than modifying the DOM. So the sooner you start doing that work, then the faster it is. Cool. I want to ask, would you recommend Microfrontend plus view plus Webstorm? Is it a great combination to introduce? Well, I would add to that using two laptops is also not a good idea, but I think courses for courses. You need to find a problem and then use the right tool, and, I don't know, maybe in some context it makes sense to do that. I would say it all depends on the context and the requirements, but try not to use too many laptops and too many frameworks at the same time. Probably a good idea. There's a question in here about Hoppin specifically that I want to read and also add a little bit to. Steph O. asks, how many engineers work on Frontend at Hoppin and how was the decision to go Microfrontend architecture made, and I also want to follow up, is there any sort of process or organisational effect that it has on either teams or devs on whether they work on one app or multiple? Yes, that's a good question.

Working Independently and State Management

Short description:

When I joined nine months ago, my department had 12 engineers on an Exodus app. Now we are around 60. We needed a way for people to work independently. We operate with bottom-up decision-making and built our own framework. We are developing a simple state management tool. Hopefully, we will open-source it in the future. Follow Alex on Twitter for updates. No more questions, but there will be a discussion room later.

When I joined nine months ago, my department, my product area had 12 engineers on an Exodus app. Now we are around 60 in the same Exodus app. So that's too many people in the same place. find a way for people to work independently so they don't step on each other's toes.

The way we operate is more like decisions are made bottom up, so some people will say, OK, we have this problem, we will solve it, and then others will try to socialise that idea and use it. So it's more a decision of we have this problem, then we started building our own framework, like, and now other departments are using these tools too, which is pretty cool. Influencers. Yeah, I would say that. This is a very popular one. It's got a lot of thumbs up.

Which state management do you recommend to use to communicate between apps? So obviously the one we are building. So the thing is, we didn't find any state management tool that was good enough for the that are too powerful, and that kind of encourages developers to, you know, when you get power, you use it. And so we wanted to create something very simple, and for instance, deriving a state in that is not a good idea because then you have this centralised thing that has logic, and so we had to build something that was much simpler than the things that we found in the community. So the answer is hopefully one day we will be able to open source it and I will show But I would say the one we are creating. You should follow Alex on Twitter for that news, when if it comes. Yeah.

We unfortunately don't have time for more questions, but Alex and Ruben are going to have a hybrid discussion room later around 2.10, just off the stage here, if you want to ask them more questions or get advice on micro-Frontend. Thank you, Alex. You are free to go.

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.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

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.