Complex React Migration: New Solutions to Old Codebase Problems


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.

32 min
14 May, 2021


Sign in or register to post your comment.

AI Generated Video Summary

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.


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

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

React Summit 2023React Summit 2023
24 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Workshop Free
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?
There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.
Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.
You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Workshop Free
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.
The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.
React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.

React Summit 2023React Summit 2023
171 min
React Performance Debugging Masterclass
Workshop Free
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Workshop Free
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.

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