“Microfrontends” for Mobile in React Native

Rate this content

Scaling has always been an issue in software development. Architects have been grappling to solve this problem on many layers. In the early 2000s, a concept of “micro-services” started popping up - a system could be split up by business domain into a number of smaller loosely-coupled services. 

More recently, this concept has started being adopted by the frontend community. An app could be split into multiple sub-apps, each with their own teams, technologies, and codebases. Companies like Spotify, Amazon, and Microsoft have adopted this approach and it has helped them scale even faster.

In the world of mobile development, the question arises: “Can we create Microfrontends for mobile apps?”.

24 min
23 Oct, 2023

AI Generated Video Summary

Micro frontends are an architectural style where independent deliverable frontend applications compose a greater application. They allow for independent development and deployment, breaking down teams into feature verticals. React Native's architecture enables updating the JavaScript layer without going through the app store. Code Push can be used to deploy separate JavaScript bundles for each micro frontend. However, there are challenges with managing native code and dependencies in a micro frontend ecosystem for mobile apps.

1. Introduction to Micro Frontends with React Native

Short description:

I'm super excited to be doing this talk on micro frontends for mobile with React Native. A little bit about me. My name is Mo. I am the head of mobile at a company called Theodo based in the UK. We have been doing React Native for a very long time. In the last few months, we were approached by a client to develop a streaming service. With universal apps, the idea is that you write once and you can run anywhere. You try to reuse as much of your core component logic and your business logic across the board. How do we architect a project at this scale? How do we create the right work stream so that our teams can simultaneously develop? One of the things that we did was we tried to take the main features of the application and put them inside of packages that teams could develop autonomously.

Hey everyone, nice to be with you all at React Advanced this year. I'm super excited to be doing this talk on micro frontends for mobile with React Native. It's a topic that I've been exploring a little bit for the past few months and I think there's a lot of interesting learnings and I hope that by the end of it I will have piqued your interest to explore a little bit more in an area that I think is a little bit underdeveloped and there's a lot of scope for improvement within our community. So yeah, hopefully some exciting stuff will come out of this.

A little bit about me. My name is Mo. I am the head of mobile at a company called Theodo based in the UK. Theodo is a group of international consultants, digital experts that are located around the world, mainly based in France, the UK, New York and also in Morocco. We have been doing React Native for a very long time. You may know us by another name, BAM, where we've been working on open-source in React Native since the very beginning. We adopted React Native back when it came out a few months after it was released by Meta, and we've released various open-source projects like the React Native Image Resizer Library, and more recently Flashlight, which is a tool to measure performance for mobile apps.

Being in the consultancy space, you get to experience a lot of different projects, and I want to talk to you a little bit about one of them today. Story time. In the last few months, we were approached by a client to develop a streaming service. Now, this is a full-scale media platform. It's not just streaming with some videos and just a very basic site. It was the full-fledged thing, with news, with streaming, reading articles, listening to podcasts, all centralized into this one platform that had quite a lot of different moving features about it. The key points in this project was that, one, there was a large number of features, but they had a bunch of other requirements that made it more complex. One was that they wanted it to have feature parody across web, mobile, and even TV. They wanted to have very short turnaround, which meant that we needed to have several teams of developers working on this project simultaneously.

So, being a bit familiar with the React Native space, one of the things that we went for when we heard about parody across the board was this idea of universal apps. This is a space that is developing and I think coming to fruition in the past few years. With universal apps, the idea is that you write once and you can run anywhere. You can use React Native really to create a web application, a mobile application, a desktop application, and even maybe a TV application. You try to reuse as much of your core component logic and your business logic across the board and super powerful in the sense that you can have many, many gains in terms of speed and delivery and rate of iteration and innovation. So it's a very exciting space to be in and we knew that this was going to be a good fit because our project was going to be mobile first but they also needed access to web and TV, so it was kind of a no brainer for us. But it also got us thinking about something a little bit more subtle, which was how do we architect a project at this scale? How do we create the right work stream so that our teams can simultaneously develop? We've got tens of different developers working on this project at the same time. How do you organize it in a way where people aren't stepping on each others' toes? People aren't having too many different sort of merge conflicts or too many different blockers along the way of their development. So one of the things that we looked at very heavily was how do we structure this project? Now this is a simplified folder structure, but hopefully it gets the point across. One of the things that we did was we tried to take the main features of the application and put them inside of packages that teams could develop autonomously.

2. Introduction to Micro Frontends

Short description:

Some of the main features were isolated into separate packages that could be used inside the application. This modular feature-driven design works well for universal and React Native applications. The next natural step is to explore microfrontends for mobile. Microfrontends are not suitable for every project, but they can be beneficial for large-scale projects with autonomous teams. The story of micro frontends begins with the transition from monoliths to microservices in the backend. As applications grow, maintaining a monolithic frontend becomes challenging, slowing down development speed.

So some of the main features were things like watching live streams or reading news articles or maybe listening to a podcast. And so we isolated these features into separate packages that could then be used inside of the application. And these were eventually building blocks that would come together and build the full fledged platform.

And one of the nice things about packaging like this was that we could effectively take any of these modules, isolate them, test them individually, they could be developed in isolation without needing to deal with all of the other stuff that the teams were working with, which meant that the developers wouldn't really get blocked at any point. And this sort of modular feature driven design really works quite well for universal applications and React Native applications.

Because when we started to break down our teams, we saw that we had created these nice feature verticals where a single team was focusing on business logic on the front end, they were creating common React Native components. But they were also coding in Native for iOS and Android and web and really understanding the core of the feature that they were building and becoming specialists in that. We really like that, but it wasn't a new concept. The next natural step that you could take from this was to go down the microfrontend's route.

So it kind of piqued this question in my mind around whether or not microfrontend for mobile is something that is feasible. And so that's what we're gonna explore together today. This is very much an exploratory talk. We're not looking to... I'm not here to advocate going full fledged with microfrontends and adopting them for every single project that you use because that is nonsense. I think there's a lot that we can learn from this approach. It's applicable to a very specific type of project. It can help a lot of projects that are at scale and they're very, very large and with a large number of teams that can be autonomous, but it's not for every single project. So I want to put that grain of salt there just so that everyone is aware this isn't advocating that you should use this on every single project that you go on from now on.

So let's go through a little bit of a history lesson. From monoliths to microservices. So ironically, the story of front ends, the story of micro front ends, starts from the backend where applications started to go from monoliths to microservices. So let's say you've got a basic backend that handles three main features, authentication, streaming and payments. So they're stored under one umbrella application. So all of them fit into one app that is a monolith and so that's fine. That's really three features. There isn't much surface area, but naturally over time you start to add more and more features. And so the app grows. And suddenly as this project is growing larger and larger, you're inevitably stuck with sort of a behemoth of an application. And every single new developer that comes on has this cognitive load that is just massive to deal with. And so the speed of the team will naturally start to slow down and down as you start to build more and more into this application.

3. Introduction to Microservices

Short description:

Teams often fall into the pattern of working on massive monoliths, which can be challenging. In the early 2000s, the concept of microservices emerged as a solution. Microservices involve splitting application features into self-contained services that can communicate with each other through APIs or event buses.

We've all seen it. It's a common pattern that teams fall into. And it kind of leaves you feeling a bit like our friend Harold here, working on these massive monoliths. So, a lot of people grappled with this in the early 2000s. And this concept of microservices started to come up. And the idea with this was, what if each of these features of the application started to, was split out to constitute its own self-contained service? So, each of these services could be isolated into very specific feature divisions. And they could communicate with those services, maybe by APIs or some sort of event bus.

4. Exploring Micro Frontends in Modern Architecture

Short description:

Micro frontends are an architectural style where independent deliverable frontend applications compose a greater application. It allows different small frontends to be deployed on their own cadence and schedule, coming together to build a whole site. Amazon's website is a classic example of micro frontends, with the header, navigation section, and promos as separate micro frontends. This approach offers benefits such as breaking down teams into feature verticals, enabling tech agnosticism, and allowing for independent release processes.

And if you're looking at the diagram on the right, it looks pretty scary. It is. But it's not for you. It's for those poor platform and DevOps engineers who have to deal with it. So, you're fine. Those platform engineers are going to be feeling like hero now. So, it wasn't the silver bullet that a lot of people went for. But it did solve some problems of scale for a lot of large organizations.

So, then this concept of microservices started to become more and more popular. People were adopting it left, right, and center. And so, later down the this concept was taken and put into the frontend space to create micro frontends. Now, if you go onto the community-led website for micro frontends, the definition that they list there is that it's an architectural style where independent deliverable frontend applications compose a greater application. So, that means that you have different small frontends and each of these are kind of deployed on their own cadence and on their own schedule and all come together and build a whole site together.

And the classic example of this is the Amazon website. So, Amazon is actually a nice place to see where you could break micro frontends into. So, if you look at the main home screen, at the very top you've got the header. That could be a micro frontend in itself. You've got the navigation section. That could also be a micro frontend. But then you might also have these sort of promos that they've got in boxes within the main part of the page and that could also be a micro frontend. And So, each of these micro frontends comprise and build the larger website.

So, there's quite a few benefits here. You break down your teams into feature verticals so there's less context for each team. And they can really deal with the core of the features that they're building out. That's great. Teams can also be tech agnostic. So, you can kind of mix and match different stacks together. And that means that you don't have to really carry the baggage of tech debt if there's choices that you necessarily don't agree with but other teams might have made in the past. We've all been there. And each of the teams have sort of an independent release process.

5. Micro Frontends and Mobile Apps

Short description:

Micro frontends add complexity but offer benefits such as independent release cycles. However, mobile apps have different distribution processes, requiring submission to app stores. React Native's architecture allows for updating the JavaScript layer without going through the app store.

So, they can release on their own cadence. And those releases will be just sideloaded off to the user when and where those independent release cycles are completed. So, those are the benefits.

Now, it does come with a very major disadvantage. And that's that you're adding a lot of complexity to be able to achieve this. So, whereas with a normal frontend, you've got a single application that's being published. Here you've got suddenly a bunch of different moving parts. You've got multiple with their own tech. You've got a lot more points of failure that you're gonna have to deal with. And on top of that, you're adding a host layer that needs to manage the shell of the frontend effectively. And that in itself is a lot more added complexity.

And so, this added complexity is something that you're gonna need to consider when you're looking at micro frontends. And so, when you take this to the mobile app, well, how do we split this out? Can we find a similar split? I think we can. If you look at the Amazon application, maybe you can have a product description micro frontend that's a screen of the application. And you can also have a shopping cart micro frontend. So, you can start to split and modularize an app into micro frontends as well. But ultimately, micro mobile apps are quite different to web apps. The key component here is the distribution side. Apps are bundled and released via an app store. You go through a build process, you submit them to the app store. And so, it raises a question around this concept of independent release cycles.

Because even if you take the different screens that we just talked about, put them into modules, so, you have a product details module and a shopping cart module, and then you combine them into a single app, ultimately, you're going to still need to go through that process of submitting to the app store, which is the great, big, scary ghoul that stands at the end of every team's release. And they can either approve or deny your application going through. So, really, the future teams don't have any control over the release processes. And that really ages any developer beyond measure. It's a depressing sight to see. But that is where React Native really comes into play. And this is one of the, I think, the beauties of React Native is this architecture of having a JavaScript layer and also having a native layer. And one of the things that you can do with that is that, you know, if you want to change some of the stuff that lives on the JavaScript layer of your application, what you can basically do is write some JavaScript, bundle that, send that somewhere to the cloud, and the shell of the React Native app can query and basically update the JavaScript layer whenever you want to push out updates to a team. Now, this is incredibly powerful because at any point you can just go in and update JavaScript and not need to go through the app store.

6. Micro Frontends with Code Push

Short description:

Faster iterations, quicker bug fixes, delivering value to users sooner. Code Push supports a single JavaScript bundle, requiring bundling everything together. But what if we could use Code Push in multiple parts of an application and bundle things separately for each micro frontend? Different instances of JavaScript bundles inside a single native app shell, independently deployed by Code Push.

Faster iterations, quicker bug fixes, ultimately delivering value to your users sooner, everyone's going to be happier, right? I know there's a lot of different implementations for this which for achieving these over the air updates. But one is Code Push that we're going to be looking at. And Code Push is great. But it only supports a single JavaScript bundle, which means you still need to take everything and put them all together. Which was a depressing thing to come to terms with for me. But it still got me thinking, it would be very cool if we could use Code Push in multiple parts of an application and bundle things separately for each of the different micro front ends that you may have and have different instances of JavaScript bundles inside of a single native app shell that could be independently deployed by Code Push.

7. Demo of MyCars Application

Short description:

I spent a fair bit of time, but we ultimately came up with a demo to show this. I've created a very basic application called MyCars with two tabs, Home and Remote. These are two different JavaScript bundles, two different React Native apps deployed independently. We're going to make some changes to improve the app, starting with the dashboard screen.

I spent a fair bit of time, but we ultimately came up with a demo to show this. And this is very exciting for me, so hopefully it doesn't fail. Let's take a look at the demo.

I've created a very basic application here called MyCars. I don't own any of these cars that I'm about to show you. If we jump into it, it's a very basic app with two tabs. Now, the shell of the app is a Swift app, but the screens inside are going to be built with React Native. This first screen is the Home screen, and that is a single bundle. And then we've also got a Remote screen, which is another bundle. These are two different JavaScript bundles. They're two different React Native apps that are being deployed independently from each other.

We're going to go and make some edits to just showcase how this would work. On the Home screen right now, I've got a little carousel which has a bunch of different cars that I wish I had in my garage, but I don't. And Audi A4, a Bentley Continental, and best of all, a 1970 Opel Corsa with 203,000 miles. So we've got some nice-looking cars here, I promise you. We're going to go in and make some changes. Now I've got a little bit of feedback on this, how we can make it a little bit better. So firstly, good morning. It always says good morning. Probably not accurate right now when I'm recording this, when it's in the evening. So we're going to go and change that. And then also on this, it's a little bit confusing on the remote because it says vehicle open, but this is actually just locked and unlocked. So I had a scare at one point thinking that the cars were left with their doors open when it was just unlocked. So let's go and change those two things. So if I open this up here, I've got a repo set up for the dashboard screen, and that's an independent React Native repo. If you literally look here, all that we've got within this repo is it's a bare React Native app that's got a basic index.js with an app being exported, which is just the single screen for the dashboard. And likewise, here, we've got something very similar for the remote screen. So let's jump in here and make some changes. Let's start with our dashboard. So firstly, we wanted to change it from good morning.

8. Updating Text and Deploying Bundles

Short description:

Let's make some changes to the text on the main screen and the remote screen. We trigger a code push to generate and deploy the bundles. The challenge is that code push doesn't support multiple JS bundles, so we modify its implementation to handle different bundles. By comparing file names, we ensure that the correct bundle is accessed. After a code push, we close the application and upon reopening, the update is triggered, resulting in the updated text and unlocked vehicle on the screen.

Let's just make it, how are you doing today? And we'll just change the text there. And then at the same time on the remote screen, we said we don't actually want it to be locked or open. We actually just want to change this to unlocked. So let's go ahead and change that. And then what we're going to do is we're going to trigger a code push here. So I've got a script here that will run a generation of the bundle. And then afterwards, likewise here, we're going to do a code push here, which will which will generate the bundle, and then it will make a call to App Center to effectively push these bundles to the cloud. So that's doing that right now, it's going to do a release.

And so if we go into the native side of the code, I've just taken some of the code of snippets. This is very POC and very draft, but just to give you an idea, the way that it works is we've got a React Native view controller. And this view controller uses code pushes bundle URL to access a specific resource. And that resource is going to be passed in by the tab views to say, you know, I want to access the dashboard screen or I want to access the remote screen. Now, the challenge here is that code push, like I mentioned, doesn't support multiple JS bundles. So, with a lot of pain, one of the things that we have to do here is actually go in and change how code push looks for bundle, how code push looks for the bundle URL for a specific bundle that you pass in here. So, when we actually call code push.bundle URL and pass in the resource, we need to go in and modify the actual implementation for it to actually check and make sure that it's not quarrying for the same file. So, it always assumes that you have one bundle. And in this process, what we've done is we've gone in and changed it so that it checks for the actual file name and compares those together. This is very rough, very crude. It's just to get it working with the two different bundles. Ultimately, what will need to happen here is that it will need to be able to handle this kind of in a more generic term, but this just gets it kind of working out of the box right now.

So, effectively, what we do here is we check based off of the file that exists in side of the package, but also the file that exists in the actual app binary. And we make sure that they're the same resource name. And if they're not, we assume that it's another bundle that is going to be used. And so now that we've done a code push, we can go back. Now, what we're going to do for this update to trigger is we're going to actually close the application, and then on the next start of the application when we open it up, the first thing you'll see is it's back in where it used to be, but if we wait a second, it'll query. And then once it knows that there's been an update, it actually updates the application. So now it says, how are you doing today, Mo? Okay, great. That's been updated now. And then if we go on this screen, you can see that we've now got vehicle unlocked. So these two modules have been independently deployed.

9. Microfrontend Ecosystem and React Native Bundling

Short description:

They live in separate repos and could be developed by different teams. Webpack is the de facto bundler for microfrontends, but Metro is the bundler of choice for React Native. There's ongoing work to make Metro more compatible and suitable for a wide range of uses. The communities around Vite and Rollup have implemented their own versions of module federation, and it's only a matter of time before it comes to Metro. React Native's unique architecture with the JavaScript layer and the Native layer provides massive potential for architectural advances.

They live in separate repos. This is within one repo called dashboard screen, and this one is in another repo called remote screen. And they are being developed. In theory, they could be developed by different teams, and they could be independently published. Awesome.

So we've taken a look at how to use CodePush and React Native to create a very bare bones, basic, microfrontend driven application. Now, let's take a step back and just take an overview of where the whole microfrontend ecosystem and where the whole React Native bundling ecosystem stands right now.

Webpack is the de facto bundler to use for microfrontends, and that's because Module Federation is a key part of the Webpack ecosystem. And Module Federation really comes with all of the right tools as a plugin for you to be able to build really effective microfrontends on the web. There's a lot of great resources on this. I'd highly recommend watching some of the talks by Luca Mesoleri, who works at AWS, about using Module Federation and microfrontends in general. I think there's a cool stuff to learn there. And it's really where the maturity lies, especially on the website.

Now, naturally, a lot of people have been attracted to this for mobile as well. Recently, there's been a new Webpack-based toolkit that allows you to use Webpack instead of Metro as your bundler in a React Native application. And one of the primary reasons for that is to be able to use Module Federation and to be able to build microfrontends within mobile applications. The challenge with this is that Webpack is not a first class citizen in the React Native ecosystem. In the current state, a lot of different parts of the community are moving towards Metro. Back in the day, if you had a React Native for a web application, it would be that you would use Webpack for the website and you would use Metro for the mobile side. Nowadays, if you build a universal app within the Expo ecosystem, it is recommended that you use Metro for web as well. Metro is really the bundler of choice for the React Native community, and most people are heavily investing in Metro. There's a lot of good work that's being done to make Metro more and more compatible and more and more suitable for a wide range of uses. Ultimately, I am very excited for a future in which Metro can maybe support some form of module federation.

Now, this isn't really too far off. The communities around Vite and Rollup have implemented their own versions of module federation. There's a very thriving open source project dedicated to implementing module federation within Vite that's also compatible with Rollup, actually. So there's a lot of good work that can be done and has already been done by other communities around different bundlers, and I think it's only a matter of time before a mechanism like module federation comes to Metro, and I think that's where React Native will end up really shining because of the unique architecture it has with the JavaScript layer and the Native layer. There's massive amounts of power to take some of the architectural advances that have existed on the website and bring it over to mobile. So I'm very excited for that. But there are still some challenges.

10. Challenges with Micro Frontends and Mobile

Short description:

The theoretical concept of micro frontends doesn't work well with mobile due to several blockers. Native code cannot be code pushed, requiring a well thought out system and build pipeline to manage different teams introducing new native code or dependencies. Updates must still be rolled out through the app store for features that are not JavaScript based.

And so we're going to talk about why this sort of theoretical concept of micro front test doesn't really work with mobile. There's still quite a few blockers. Firstly is Native code. You can code push anything that's in JavaScript but you cannot code push any new native code. And so, as you split up your application into different micro front ends, you need to think of a well thought out system and a nice build and deployment pipeline that will effectively allow for you to manage these different teams as they start to introduce new native code or maybe change their native dependencies and introduce new native dependencies to make sure that you are still rolling out updates through the app store with new app binaries and ship those out to your users whenever you do need to introduce features that are not just JavaScript based.

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 Advanced Conference 2023React Advanced Conference 2023
27 min
Simplifying Server Components
Server Components are arguably the biggest change to React since its initial release but many of us in the community have struggled to get a handle on them. In this talk we'll try to break down the different moving parts so that you have a good understanding of what's going on under the hood, and explore the line between React and the frameworks that are built upon it.
Remix Conf Europe 2022Remix Conf Europe 2022
23 min
Scaling Up with Remix and Micro Frontends
Do you have a large product built by many teams? Are you struggling to release often? Did your frontend turn into a massive unmaintainable monolith? If, like me, you’ve answered yes to any of those questions, this talk is for you! I’ll show you exactly how you can build a micro frontend architecture with Remix to solve those challenges.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Day Berlin 2023React Day Berlin 2023
21 min
Exploring React Server Component Fundamentals
I've been developing a minimalistic framework for React Server Components (RSC). This talk will share my journey to deeply understand RSC from a technical perspective. I'll demonstrate how RSC features operate at a low level and provide insights into what RSC offers at its core. By the end, you should have a stronger mental model of React Server Components fundamentals.
React Summit 2023React Summit 2023
26 min
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 place2. What are server components and what benefits did they bring like 0 javascript bundle size3. Demo of a simple app using client-side rendering, SSR, and server components and analyzing the performance gains and understanding when to use what4. My take on how rendering UI will change with this approach
React Advanced Conference 2023React Advanced Conference 2023
28 min
A Practical Guide for Migrating to Server Components
Server Components are the hot new thing, but so far much of the discourse around them has been abstract. Let's change that. This talk will focus on the practical side of things, providing a roadmap to navigate the migration journey. Starting from an app using the older Next.js pages router and React Query, we’ll break this journey down into a set of actionable, incremental steps, stopping only when we have something shippable that’s clearly superior to what we began with. We’ll also discuss next steps and strategies for gradually embracing more aspects of this transformative paradigm.

Workshops on related topic

React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
- Introduction- Prerequisites for the workshop- Fetching strategies: fundamentals- Fetching strategies – hands-on: fetch API, cache (static VS dynamic), revalidate, suspense (parallel data fetching)- Test your build and serve it on Vercel- Future: Server components VS Client components- Workshop easter egg (unrelated to the topic, calling out accessibility)- Wrapping up
React Summit 2022React Summit 2022
117 min
Detox 101: How to write stable end-to-end tests for your React Native application
Compared to unit testing, end-to-end testing aims to interact with your application just like a real user. And as we all know it can be pretty challenging. Especially when we talk about Mobile applications.
Tests rely on many conditions and are considered to be slow and flaky. On the other hand - end-to-end tests can give the greatest confidence that your app is working. And if done right - can become an amazing tool for boosting developer velocity.
Detox is a gray-box end-to-end testing framework for mobile apps. Developed by Wix to solve the problem of slowness and flakiness and used by React Native itself as its E2E testing tool.
Join me on this workshop to learn how to make your mobile end-to-end tests with Detox rock.
Prerequisites- iOS/Android: MacOS Catalina or newer- Android only: Linux- Install before the workshop
React Advanced Conference 2022React Advanced Conference 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
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 Summit Remote Edition 2021React Summit Remote Edition 2021
60 min
How to Build an Interactive “Wheel of Fortune” Animation with React Native
- Intro - Cleo & our mission- What we want to build, how it fits into our product & purpose, run through designs- Getting started with environment set up & “hello world”- Intro to React Native Animation- Step 1: Spinning the wheel on a button press- Step 2: Dragging the wheel to give it velocity- Step 3: Adding friction to the wheel to slow it down- Step 4 (stretch): Adding haptics for an immersive feel
JSNation Live 2021JSNation Live 2021
113 min
Micro Frontends with Module Federation and React
Did you ever work in a monolithic Next.js app? I did and scaling a large React app so that many teams can work simultaneously is not easy. With micro frontends you can break up a frontend monolith into smaller pieces so that each team can build and deploy independently. In this workshop you'll learn how to build large React apps that scale using micro frontends.
React Advanced Conference 2023React Advanced Conference 2023
153 min
React Server Components Unleashed: A Deep Dive into Next-Gen Web Development
Get ready to supercharge your web development skills with React Server Components! In this immersive, 3-hour workshop, we'll unlock the full potential of this revolutionary technology and explore how it's transforming the way developers build lightning-fast, efficient web applications.
Join us as we delve into the exciting world of React Server Components, which seamlessly blend server-side rendering with client-side interactivity for unparalleled performance and user experience. You'll gain hands-on experience through practical exercises, real-world examples, and expert guidance on how to harness the power of Server Components in your own projects.
Throughout the workshop, we'll cover essential topics, including:
- Understanding the differences between Server and Client Components- Implementing Server Components to optimize data fetching and reduce JavaScript bundle size- Integrating Server and Client Components for a seamless user experience- Strategies for effectively passing data between components and managing state- Tips and best practices for maximizing the performance benefits of React Server Components
Workshop level: 
No matter your current level of React expertise, this workshop will equip you with the knowledge and tools to take your web development game to new heights. Don't miss this opportunity to stay ahead of the curve and master the cutting-edge technology that's changing the face of web development. Sign up now and unleash the full power of React Server Components!