Complex React Migration: New Solutions to Old Codebase Problems

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

In 2020, Rangle partnered with the Survey Monkey team to migrate a legacy codebase to React. Survey Monkey’s best-in-class digital products were being held back fragmentation and complexity, which created a lot of rework and wasted effort for their engineering teams. Working together, we implemented a number of process and architecture changes that cut the complexity and improved workflows, letting our blended team deliver results with speed and consistently, even early in the engagement. These were not one-size-fits-all solutions, but solves that were unique and fitted to the needs of the engineering and product teams. The success of the project was due to Survey Monkey’s motivated teams that were: 1) Ready to embrace change; 2) Able to keep a firm focus on the outcomes; and 3) Readily understood the complexity of the project.


This allowed us to co-create some non-intuitive solutions that engineers at similar enterprise-level companies should know about.

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

FAQ

ServingMonkey is a pioneer software as a service company from Silicon Valley, known for its market-leading survey software and other market research tools such as quick polls, competitive analysis, and customer feedback systems. It has a significant presence in enterprise companies worldwide and played a crucial role during the 2020 pandemic by empowering communication and engagement across companies.

ServingMonkey faced several challenges in migrating their product to a new web platform, including the sheer size of the product and the high sophistication of its features which complicated the integration and implementation of modern DevOps practices and a cohesive design system.

Rainbow, a consultancy known for its expertise in creating new products and digital modernization, partnered with ServingMonkey to refine and implement a migration strategy. This involved developing a domain library and a three-tiered architecture to simplify feature code and facilitate a cohesive look and feel across the application.

The three-tiered architecture developed for ServingMonkey includes pure visual components of the domain, question type-specific business logic, and interfaces with the specific needs of features. This architecture helps in separating concerns and allowing feature teams to implement user interfaces related to different question types without deep knowledge of each type.

An evolutionary architecture is designed to sustain changes and reconcile these changes without losing cohesion. It allows a system to evolve over time while maintaining its integrity, thus preventing the architecture from becoming outdated quickly. This strategy is essential for long-term maintenance and scalability of software systems.

The domain library was central to the modernization process at ServingMonkey. It was designed to encapsulate business and presentation logic related to key domains, such as survey questions, enabling consistent and efficient feature development across different teams.

The design system developed for ServingMonkey provided a cohesive and well-rounded set of React components based on solid design principles. This system was crucial for ensuring a consistent user experience and accelerating the development process as the company migrated to the new platform.

Jason Santos
Jason Santos
32 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This Talk discusses the challenges of dealing with legacy code and the benefits of partnerships in software development. It highlights the case study of ServingMonkey and Rango, showcasing the solutions implemented to modernize their code bases. The talk emphasizes the importance of three-tiered architecture and collective ownership in achieving sustainable changes. It also addresses the challenges of migrating to new technologies and the need to consider business value when making technology decisions. The talk concludes with insights on preventing code from becoming legacy and the benefits of code migration and collaboration.

1. Introduction to Legacy Code and Partnership

Short description:

Imagine having legacy code that no longer meets your needs. You discover new technologies and your team is eager to adopt them. Despite some discrepancies, you continue delivering and evolving. Fast forward 10 years and you have a new legacy code. My name is Jason Santos and I'm here to talk about our partnership with ServingMonkey and the amazing work done by our team of engineers.

Oh good afternoon everyone, of course not everyone, only those that are where it's actually afternoon for everyone else whatever time of day there is. Let me know if you've seen this before, right?

Imagine like you have your legacy code and it's not giving you all the speed you need, right? The world has changed, you can feel it in your styling, you can feel it in your build, you can smell it in the code. Then you find brand new technologies and your team is eager to adopt that. Everything's pretty amazing, you can do things you haven't been able to do before and yeah, except they are not super familiar to you. You let your teams decide what to use. At some point, the best technology wins, everybody's happy and now you at least can start delivering your features. Business is always doing it, you deliver, business wants new things, shinier things, and somewhere along the lines you have a little bit of discrepancy. Some technologies are different here and there, different ways of doing things have appeared, your team grows, features grow, and you start seeing discrepancies here and there, but at least you're delivering and things are evolving and growing. Fast forward 10 years and you have yourself a new legacy code.

My name is Jason Santos and this is how I used to dress to impress clients, I mean when you could actually meet them face to face and I worked at Rainbow. You probably know who we are and I'm here to talk to you a little bit about how some of the awesome things we did in partnership with ServingMonkey. But don't get the illusion that I have done all these things by myself, right? There's an awesome, awesome group of people that helped me a lot and like that did this most of the work actually, while just keeping you and taking the credit. And seriously, they're some of the most fantastic and smarter engineers I have ever worked with.

2. Introduction to ServingMonkey and Rango

Short description:

We're going to talk about ServingMonkey and Rango, the problems we faced, the solutions we came up with, and show you some code. ServingMonkey is a pioneer in software as a service, with 1,200 employees and 17 million users. Work4Rainbow is known for creating new products and helping companies modernize. In partnership with Wrangell, Silver Monkey aimed to modernize their code bases using the latest technology and DevOps practices. The challenges included the size and complexity of the products. The solution involved the development of a domain library to simplify the feature code and ensure a cohesive look and feel.

Well, but first let me tell you a little bit what this presentation is about. We're going to talk to you about what is ServingMonkey exactly, what's Rango exactly, and what are the problems we faced. We're going to talk to you a little bit about what type of solutions we came up with to solve those problems. And of course, I'm going to show you some of the code.

Okay, what exactly is this product we're modernizing? ServingMonkey has one of the first examples of software as a service in the market. It's a pioneer of Silicon Valley that helped shape that industry. It has about 1,200 employees and more than 17 million users. They have product lines that include market leader survey software and whatever type of market research, like quick polls, competitive analysis, customer feedback, you name it. They have a large footprint on enterprise companies around the world, and they have an impact that was massive during the 2020 pandemic. They empowered communication across companies, engagement, all that good stuff that we are forced now to do from our kitchens. Yeah, it's great to have great software to do that with.

Now, for the shameless plug, Work4Rainbow, right? We're pretty known in the software development scene. We were pioneers on the modern web and we have a very constant presence in summits like this. Our team excels at creating new products and helping companies modernize and become more digital. You probably know us. We've been sponsoring and presenting in many technology events ever since 2013, and we are a consultancy board in Toronto, Canada, but now we have presence in multiple countries. In the last quarter of 2020, Silver Monkey partnered with Wrangell in an effort to modernize some of their code bases into this brand new technological platform they were developing. The Silver Monkey team was facing a lot of challenges to bring all their feature teams into that brand new web platform, and the biggest challenge may be the sheer size of it, and they used the best technology that was available, and they were building that with some of the best and most mature DevOps practices that we have ever encountered. It looked like they were set up for success. On top of that, they had developed this awesome design system, like they're very cohesive and well-rounded, based on solid design principles, and implemented as a React component library with everything on it, on and the cherry on top. However, now that they needed to migrate, they had this big set of expectations of what that migration was going to do. And together, Rangel and Sarumaki devised some of the fine-tuning and some of the planning around how these goals were going to be achieved. It all started with the problem statement, right? How can we make sure this migration is successful and that we can reap all these benefits at the end? You start with the challenges, right? The sheer size of their products, the high sophistication of it, made it hard for us to really make sure everything was going to fall into place. Local complexity was the key element, right? It was really a matter of trying to figure out how each one of these highly sophisticated pieces was going to really come together as one platform. The solution was the domain library. Maturing a rolling out wrench that was SurveyMonkey's design system was a good strategy to help the feature teams become more productive and create a cohesive look and feel to the application. But it was just the start. Simplifying the feature code was possible only if some of the business and presentation logic on the features themselves were shared. When the same concepts were used in different places, domain-specific code will be in charge of that section. The concept is inspired in domain-driven design and helped shape a library that could concentrate everything related to one of the most important domains at SurveyMonkey, the question.

3. Execution and Three-Tiered Architecture

Short description:

Now for the execution, we divided the team into two squads - React developers and alignment with feature teams. We refined the governance model and bridged knowledge silos. The three-tiered architecture separated the domain library into visual components, business logic, and feature interface. The solution was deployed as three internal NPM packages. Custom visualization and theming were achieved through separate files. Visualizations are non-visual components that map usage to actual visual components.

Now for the more concrete part, the execution. First, the process. We divided the team into two different squads, allowing the React developers to start delivering quickly, and in the meantime, have another group started creating the relationships and the alignment with the feature teams inside SurveyMonkey to help design APIs and integration points. The two tracks ran independently, spearheaded by different solution architects that kept in constant contact, one team, one goal, but with the ability to concentrate focus across the two dimensions.

On the design system side, we have been able to refine and validate most of the governance model that empowered the feature teams and the domain library team to continue to contribute to that design system and keep it cohesive. At the same time that by contacting the feature teams themselves, we were able to bridge some of the knowledge silos and create a common understanding of the structure and of the problems. The names were not super important, but they needed to be aligned. The important thing was with the abstractions in place, we can not only communicate more efficiently, but now we can reshape those same abstractions as a single team.

One pattern emerged as a good way of giving this whole integration system the flexibility it needed and ensure the separation of concerns that will allow all the teams to move forward with the domain library, the three-tiered architecture. Inspired by the capability pattern, it consisted in separating the domain library in three parts. The pure visual components of the domain, the question type-specific business logic, and the interface with the specific needs of features. Most of the mechanisms were implemented using React contexts and TypeScript and the goal was to make sure the feature teams could implement question-related user interfaces without deep knowledge about the particulars of each question type.

This is how we deployed the solution. Three different packages were delivered as internal NPM packages and one of them, the question internals, contained only the domain-specific visual components. Another library, the question definitions one, contained the business logic types and type cards specific to each of the 23-plus question types supported by the SurveyMonkey apps. The third one, question bundles, included the capability providers and the visualizations that were actually the mapping between those two. They were feature-specific facades that allowed the feature teams to inject custom behavior and custom visuals into the domain visualizations.

Okay, enough talk let's see some code. This is one of the smallest components, like it's super tiny but it can show you the pattern. It's one of the key things that we had to support here and one of the reasons why some of these components were very specific to the domain was the custom visualization of it, like it's the ability to theme it differently in run time. We achieved that by having this separate file alongside each component that could give it some specific styling but that would also change the way that styling worked based on the theme that was injected by the end user. This is a slightly different but yeah still very basic component. It's different from the design system version of the same component because of the ability for the end user to theme it. This is the rest of it. It's a basic input and it's also one of the first iterations. Visual components are tier 3 and this is tier 1. This is an example of a visualization. Visualizations are non-visual components despite their name. They were designed to be one of the easiest things to write because you have lots of those. Their structure is designed to really map the usage to the actual visual components and map the properties and if necessary hold some state.

4. Evolutionary Architecture and Collective Ownership

Short description:

The strategy focused on making the code that would be written many times extremely easy to write. This is achieved through a capability provider and a list of visualizations. The evolutionary architecture allows for sustainable changes without losing cohesion. Positive feedback from the engineering teams and collective ownership of the architecture have been key to the success of the approach.

It was also one of the hardest ones to name. You can see the rest of it here. The single text box question field is a visual component from tier three and you can see that the visualization maps some of the external properties that are the way the feature is going to call them to the internal ones in the visual component. The last bit is the visualization declaration that helps the overall engine to select which visualization is proper for each capability and question type.

So one of the most important aspects of the strategy was to make sure that the code that was going to be written many times was extremely easy to write. So, this is one capability provider. We tried to make sure that the end user didn't have to spend a lot of their time preparing the types and setting parameters and things like that. So for that we created a bunch of helpers like a lot of helpers that allowed someone to simply use this factory here with a list of visualizations and then TypeScript will infer the types for the external capability provider based on the visualizations that were selected. Now let's see some typical usage here. This is how you would use it on the application code. You would get the capability provider somewhere in your code and inside of it, amongst all your other visual components, you would have one single question controller. The single question controller would be replaced by the appropriate visualization depending on what the question at the runtime was configured around. For example in this case, you have a single text box that will render as a single text box and if you change to a comment box, it will change everything that can be changed based on the data that's inside the question type. The question type itself is on tier two and drives what can be changed by each one of these things.

The idea here is that this is an example of an evolutionary architecture, that's the main concept of this solution right. What's an evolutionary architecture? It's an architecture that can sustain changes and reconcile those changes without losing cohesion. It's the antidote for having to do that again in 10 years. Right, this migration is still ongoing, but we can see some very important results from the approach. The main one may be the response from the engineering teams. We received a lot of positive feedback, and some of the engineers really jumped into the opportunity to really understand what was going on there. So one of the things that we really tried to drive was to really create this collective ownership of the architecture, to really make sure that everyone could contribute to it and bring their problems so we could accommodate it. It's really important to have that flexibility, otherwise you end up solving problems but not the right problems. Okay now the only thing missing is the monkey bonds. How do you call a group of very young monkeys that are siblings and keep yelling a warning at you all the time? Monks! Well, thank you all. I hope you like the presentation. If you want to know more, join me for the Q&A. So it seems that for your question how old is the oldest code you have to maintain on your day to day, it seems that the winner is five years old with 38 percent, and the next one, the follow-up is less than three years. So in between three and five years maybe, I would say. What do you think about this? Yeah, that's pretty interesting because like five years in JavaScript, years, it's a lot of time. Like that means that you're probably dreading having to do certain things because they will probably be harder in certain parts of your code than they are in other parts of your code.

5. Challenges of Legacy Code

Short description:

Having legacy code that no longer meets your needs can be a big challenge. You may be forced to rebuild it to support modern requirements. The process of migrating to new technologies and practices can be difficult, especially when dealing with a codebase that has been in use for a long time.

And you're missing opportunities. People are asking you to do things and you're like scratching your head. That's tough. And it's a big challenge, this, right? When you have this code that you depend on it to produce value for the business, you don't want to just spend time rebuilding it. But then at some point you will be forced to because there's other things that you want to do that depend on that code being more modern. Yeah, that's for sure. I can tell you for sure because in the past I used to work at a startup and we actually were one of the early adopters of React I would say, almost eight years now. And we started with Create Class. We have used mixins and everything, right? Like the sugar, and suddenly we had to move on to classes, to use classes, and also we had unit tests, and everything was a mess. And we also wanted to move to TypeScript as well. And it was, how can you do everything at once? And it was really, really hard. You either had to rewrite everything or, I don't know, do something like code modes and everything. And it was only three years old. So it's still like five years, it seems a lot as well. But I see that also 10 years, it's kind of growing and really hard to maintain after a while, especially for JavaScript, as you said.

6. Approaching Technology Decisions and Modernization

Short description:

Approaching technology decisions solely from a technical perspective may not always be the right approach. It's important to consider the value being added to the overall business and identify opportunities for improvement. This can lead to conversations about modernizing the codebase.

Yeah, yeah. And that's the thing, right? If you try to approach it from a technology perspective, like you look at these brand new technologies and you want to use it, sometimes there's not the right call, right? You need to really think of the value you're adding to the overall value stream of the business. And what are these opportunities to do that, that are missing? Because that's how you get like your migration budget, so to say, right? Like you get there. We could just do that. That would be awesome for this product for our users. And that's where you get the conversation going for really modernizing the codebase.

QnA

Questions and Three-Tiered Architecture

Short description:

Exactly. Speaking about questions, we have quite a lot of questions. I'll start with a one from Popling. Can scrolling be considered as first input? Let's pick another one from Tom HD. How did you arrive with the three tiers of architecture? The three tiers, we started with the simplest possible thing that could work. Let's build the visual components and people would use them any way they want. Then we started thinking about the constraints that you should always do. There's a missed opportunity there. Okay, you folks said you wanted this, like that you wanted the features of these applications to be very easily expanded. So how can we reduce the cost for these developers? We might remove some something from them, but now we give them the ability to do something really fast. And at the end, we found out that this complexity that was mounting inside the domain library needed to be divided.

Exactly. Speaking about questions, we have quite a lot of questions. I'll start with a one from Popling. Can scrolling be considered as first input? Be considered what? Can scrolling be considered as first input? You are the expert. I don't exactly get the question, but maybe maybe Popling, if you can add more to that as well, we'll come to it.

Let's pick another one from Tom HD. How did you arrive with the three tiers of architecture? Yeah, that's okay. We can get the scrolling afterwards. I think I got it, but the three tiers, we started with the simplest possible thing that could work. Let's build the visual components and people would use them any way they want. That's the first idea. Then we started thinking about the constraints that you should always do. Like if that happens, some things we'll be able to do and some things we won't. And what you wouldn't be able to do if everybody could consume just visual components everywhere. You wouldn't be able to standardize the way they approach gathering, getting the data from the back end of the GraphQL data and the shape of these data. Then how would they do validations, how will they do the transformations, all these things. There's a missed opportunity there. The question needs to always be, okay, what do you want to pay in terms of a tradeoff for the ability to centralize these things? Now you're going to build a little more complexity, but you're going to gain something. So we started having those conversations.

Okay, you folks said you wanted this, like that you wanted the features of these applications to be very easily expanded. So how can we reduce the cost for these developers? We might remove some something from them, but now we give them the ability to do something really fast. This is going to be like reducing their complexity and giving them a little less customization options. And at some point we started having problems. Like, okay, now in this situation here, as we started creating an inventory of all the things that needed to be done. At some point in the app, like, okay, these folks really need to customize this part here. So let's give them a mechanism now. But if you give them a mechanism, you're adding complexity again. And is that trade-off, okay. And then the conversation keeps going. And at the end, we found out that this complexity that was mounting inside the domain library needed to be divided.

Shaping Three-Tier Architecture and Scrolling

Short description:

We shaped the code into a three-tier architecture, separating visual components, business logic, and integration. Scrolling can be handled by the library or the application, depending on the context. We do not have a public Git repository with a playable architecture example.

Like, because it was different types of things that were born there. Like, okay, we have the visual components, but they should be devoid of business logic. Like, otherwise, it's kind of crazy. Depending on the scale, of course. Like, where does this business logic go? Does this business logic belonging react? Probably not. So, at this point, we started shaping this as a three-tier thing. Like, we have the integration part, we have the business logic isolated, and now we have the business-oriented visual components and organisms that people could use tied to these other things.

Okay. All right. Let's move, because we have so many questions. Let me pick up the other one. Can you also do the, in addition to what you said about the scrolling, as well? Like, let me read it again. I think he's asking if scrolling is an input that goes into the infrastructure. That depends, of course. The real boundary of this is the vertical domain, the bounded context that it belongs to. So, if you scroll inside a component, that is the responsibility of the library to provide as an organism, and this thing is kind of opaque to the outside. This component should deal with the scroll itself. But if the scroll is the responsibility of something that includes that, then the application should do that and the communication between the application and the library should have some semantic that is really representative of what that means. If it's something like, oh, you're in view now, show yourself. That's one message you want to send to the library instead of, oh, the user scrolled 10 pixels. That's the key. It makes sense.

Urbon is asking, Jason, do you have a Git repository with simple example and playable architecture? No, actually, no. I should probably put that up. I'm a really bad user of Git repositories, public Git repositories. I should do that more often. I think the oldest public code I wrote is already like two years old or something. In JavaScript years, that's forever. Yeah, nice one. Yeah, definitely.

Code Migration and Preventing Legacy

Short description:

I recommend putting your code on GitHub for others to explore and contribute. Migrating code from SurveyMonkey was done by focusing on domains and feature teams. The goal was to create cohesive, business-oriented domain entities. Feature teams were onboarded into the new structure, using the library and rebuilding parts or adding new features. To prevent applications from becoming legacy, focus on delivering value to users and continuously modernize your code.

I totally recommend you to just put it out there on GitHub so people out there can take a look, can play around. Maybe they'll have some tips and tricks here and there that they implement or move towards their own application or the whole structure of the company.

Another question from Chris Shim is how did you migrate the code of SurveyMonkey, feature by feature or more domain by domain? That depends. It started with domain because the thing that SurveyMonkey had was like very independent feature teams. They had a lot of local complexity as I said in their code because each one of these feature teams were super powered to really drive features and sophistication into their part of the product.

Now what you need to go there and understand that complexity and see what are these features so you don't rob end users of anything and make them cohesive in the centralized domain, a bounded context, like a group of business-oriented domain entities. Once you have that working right by your perspective and by the feature teams that have that domain as part of their features perspective as well, you can then onboard this feature team into this new structure, into using this library and start getting their input into evolving that. It can happen with multiple feature teams at once because they will run in parallel and they should probably migrate their own features because they are ultimately the ones that understand the best what that feature does and you can also start helping them to rebuild certain parts or build brand new features using that library because now it creates the opportunity for them to build stuff super fast because some of the complexities is removed from their plate and contains everything they would wish to contain.

Great. Yeah, that's that's a really good answer to be honest. The last question is by Arek. We have time for one more question. So, how to prevent enterprise applications from to be legacy after two years? If you have any best tips or tips and tricks how to do it? How to avoid being legacy after two years? Yeah, there's no silver bullet right? And it's it's one thing that is really important for us to understand is that as technologists we consider something legacy once it's not a shiny toy anymore, right? It's like we look at things, oh i can't believe you're still using class components, right? That's that's that's not really true. Code that's there, delivering great value to users is great code, right? You the focus is when you are missing opportunities to deliver great experience to users then you're starting to think okay can I justify rebuilding this or do we spend this time building something new right? If depending on the answer you might want to just every few months or like maybe just every day adding a little modern piece to your code.

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.
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.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

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.