Crafting Pristine React: Best Practices for Maintainable Code

Rate this content
Bookmark
Slides

In the dynamic world of React, ensuring that your code remains clean and maintainable is paramount. Dive into a session that demystifies the intricacies of structuring your React projects, distinctly separating concerns, and adhering to best practices that stand the test of time. Drawing from real-world experiences and hands-on tips, this talk promises to arm you with the knowledge to elevate your React codebase to the zenith of clarity and efficiency.

29 min
08 Dec, 2023

AI Generated Video Summary

React best practices, including state management, component performance, testing, accessibility, and clean architecture, are discussed. The use of useMemo and useCallback should be limited to when necessary, and tools like React's new compiler and Million.js can aid in performance optimization. End-to-end testing and React Testing Library are important for critical functionalities. Accessibility is emphasized, and the use of the xCore/React package is recommended. Logic business can be extracted from components, and file naming and folder structure should be carefully considered. Import aliases and different folder structures can enhance code maintainability. The talk also touches on managing hooks and testing, and ends with a discussion on favorite pizza and online presence.

1. Introduction to React Best Practices

Short description:

React provides the fundamental building blocks for creating a splendid application from scratch. Working with React is like making a pizza, incorporating all functionalities, components, dependencies, libraries, and logic. However, software tends to degrade over time. In this talk, I'll share best practices, insights, and common pitfalls related to component performance, state management, testing and accessibility, logic business, and code structure.

Well, thanks. I'm super excited to be here today. I love React Day Berlin. I love Berlin. I love React. And React is awesome. I mean, it provides the fundamental building blocks for creating a splendid application from scratch, allowing you to choose each ingredient step by step. Sometimes working with React, it feels like making a pizza. You have some basic constraints such as its shapes and the traditional method of building it. And by incorporating all your functionalities, components, dependencies, libraries, and logic, you end up with your perfect pizza.

But a few months later, that once glorious and beautiful pizza transforms into this. Yeah. But with React, who has experienced this? Raise your hand. Almost everyone. Yeah. That's typical. And David Lortz once said that programs like people get old. We can't prevent aging. But we could try to limit its effects. So, too long to read the blog quote. Software tends to degrade over time. Within 20 minutes, I'll be sharing best practices, insights, and common pitfalls related to five distinct React topics. First, we will talk about component performance, state management, testing and accessibility, logic business, and finally, files, folders, and code structure.

So, in short, a few React best practices. Guten morgen. Mein name is Miguel Ángel Duran. And this is all the German that I know. Sorry for the mistakes. I tried hard. Bitte.

2. Introduction and State Management

Short description:

I create content about web development on YouTube and Twitch. I have over 15 years of experience in software development. I've been working with React for seven years now. My most recent role was as frontend lead where I spent five years. I made the leap from my day-to-day job to focus on creating content on Twitch and developing my own products. Best practices from five years ago or today are not the same. Context matters. Factors such as team expertise, organizational structure, libraries in use, and the need for rapid iteration all play a role. I'll skip over some of the more common best practices for React applications. Let's begin with state management. And the most simple use selector to extract a state from the store would be this one. Our component becomes intertwined with the React Redux package.

I create content about web development on YouTube and Twitch. Just in case you want to start learning Spanish, who knows? You can find me in YouTube with midu.live.

A bit about myself. I have over 15 years of experience in software development. I may look young, but I'm approaching 40. I've been working with React for seven years now. Starting with the infamous Create Class. Anyone tried Create Class from here? Yeah. A few of you. Yeah. I'll give you a hug after the talk. Fortunately, past that era.

My most recent role was as frontend lead where I spent five years. We undertook the significant task of migrating a monolithic application to a new React application. A year ago, I made the leap from my day-to-day job to focus on creating content on Twitch and developing my own products.

So, before starting, because I want to acknowledge that discussions about best practices can often ignite passion. I mean, that's a bit cool, but sometimes even a bit of fanaticism. So, best practices from five years ago or today are not the same as maybe they would be in two weeks, one month, or one year later. These practices might evolve over time, or they may not be applicable to your specific use case. Because context matters. Factors such as team expertise, organizational structure, the libraries in use, the need for rapid iteration, even at the cost of technical depth, all play a role. So, even if you disagree with some of these practices, which is completely fine, I encourage you to remain open-minded and make your own.

I'll skip over some of the more common best practices for React applications. Okay? And let's begin with state management. I'm pretty sure that you know this library logo, Redux. It's everywhere. And in every codebase. And the most simple use selector to extract a state from the store would be this one. And we import the hook from Redux and use it to access a specific slice of a state we're interested in. And as we could observe, even with the simplest component, simpler component, our component becomes interwinded with the React Redux package.

3. State Management and Component Performance

Short description:

This approach is manageable for small projects or maybe medium-sized projects. But could be posed challenges as the project scales up. One piece of advice for best practices on React would be to grab your state library with your own hooks. It's best to encapsulate your state library. Create a custom hook that focuses on the data itself. Don't leak your library across all your components. Avoid this kind of custom hooks of user store, use local storage, use Fetch, and instead focus on your data. And name your custom hooks in order to change the implementation. Now talking about component performance, useMemo and useCallback are designed as performance optimization tools for React applications. But I would say that they should be used only when truly necessary.

This approach is manageable for small projects or maybe medium-sized projects. But could be posed challenges as the project scales up. If you want to change to Sustan, somebody could think about use final replace, but it's not that easy. Because you have a ton of results. And it has some drawbacks. Because you could miss some files. It's a manual process. A lot of file changes. And even maybe it's too complex.

Because some components like this one, it's even for a small component, it's bloated with numerous references to Redux. So, one piece of advice for best practices on React would be to grab your state library with your own hooks. It's best to encapsulate your state library. Because then and this is applicable to any library. Because it ensures a more streamlined and adaptable integration of state management within your application.

So, obviously, you could create a custom hook, and that would be something like that. And the most important thing is not even the custom hook, but the naming of it. Because if you notice the name of the hook, it doesn't specify how or from where we are extracting the data. But rather focus on the data itself. And when we are using it, we are removing any specification of Redux. And even if we check the most complex example in this instance, the improvement is going to be significant. We move from this, that is super bloated with Redux code, to something like this. Now it is understandable. It doesn't care about where I'm getting the data. And it's focusing on a few lines of code.

So, don't leak your library across all your components. Avoid this kind of custom hooks of user store, use local storage, use Fetch, and instead focus on your data. And name your custom hooks in order to change the implementation. And don't even have to go to every one of your components to move from one library to another. Now talking about component performance, useMemo and useCallback are designed as performance optimization tools for React applications. But I would say that they should be used only when truly necessary.

4. Optimizing Performance and Testing

Short description:

Utilizing useMemo and useCallback excessively can complicate readability and add unnecessary complexity without significant performance improvements. React's new compiler, under development, aims to automatically memorize components and functions. Another option is Million, a virtual DOM replacement for React that offers automatic performance improvements without code changes. Profiling from dev tools is crucial to identify re-rendered components and evaluate their cost. When it comes to testing and accessibility, integration tests are essential.

And I mean, a lot of times on my last company, we had a lot of code like this one. They are utilizing the useMemo hook to prevent recreating posts on every render if the post remains unchanged. And this approach could make sense sometimes for some specific cases. But the problem is that sometimes you'll find something like this inside a component. The issue arises because the same component is using one useCallback and useMemo four times. And this overuse complicates readability, adds unnecessary complexity, and in some instances doesn't result in a tangible performance improvement.

So, what can we do? We could wait for React forget the new compiler that React team is working. It's still under development. It was announced in 2021. And it's designed to automatically memorize our components and functions. Three months ago, they shared a small update that they're still working on it. I don't know if it's going to be launched any day. But another possible solution could be considering using Million. Million is a virtual DOM replacement for React. And you don't need to change or add complexity and lights of code in your codebase. But instead, it offers significant performance improvement automatically. So, it compiles. It acts like a wrapper in some components. And it improves their performance. And you don't have to change anything. You don't have to add useMemo or useCallback. It doesn't do the same. But the performance improvement is considerable.

What I want to share is this kind of phrase that is super important. The primitive optimization is the root of all evil. The piece of advice here is that you have to profile from the dev tools to identify which components are being re-rendered. But not only that, but also check the cost of it. Because sometimes, even if it takes one millisecond or even less, it doesn't make any sense to put more code in order to try to fix something that is not a problem. Talking about testing and accessibility, consider an application using Amazon as an example. If you were limited to performing just one type of testing, which would it be? You need integration tests.

5. End-to-End Testing and React Testing Library

Short description:

Implementing end-to-end tests in your application is crucial for critical functionalities. Tools like Playwright offer mind-blowing features, such as a Visual Studio Code extension that generates code while you navigate your website. The API is similar to React Testing Library, which is considered the best API for testing React applications.

The obvious choice would be an end-to-end test. If you only have one test in your application, it should be an end-to-end test. And currently, there's no excuse for not implementing some end-to-end test in your application to critical functionalities. Nowadays, these tests are faster than some years ago and they are more affordable. And we have some tools like Playwright that are mind-blowing. For example, they have this Visual Studio Code extension, where you open your website and while you are navigating your website and you are trying your application, then it's writing for you all the code. And even the API is super awesome because it's super similar to React Testing Library that I think and I find that this is the best API for testing for React applications.

6. Accessibility and Reporting

Short description:

A lot of times people don't care about accessibility. My recommendation would be to install the package xCore/React. It's super easy to understand and configure. You can create a method to report accessibility issues and get detailed information about the issues in the console log.

And also about accessibility, a lot of times people don't care about accessibility. Sometimes it's because we are, I don't know, ignorant, maybe we are lacking information about how to fix those things. My recommendation would be to install this package, xCore slash React. It's super easy to understand. It's straight to the point. And I will show you how to configure it and the information that you are going to grab.

You could create a method to report accessibility issues like this one. The only thing is that it's going to be executed on client and on development mode. And we're using some dynamic import to only import those dependencies for development. So we avoid adding the bundle to the production bundle, these packages. Then in your entry point, you should use this new method, two lines of code, report accessibility, and then pass the React instance really to the method. And that's the information that you are going to get. You are going to get in the console log, you are going to get some issues, serious issues, moderate issues, and not only the typical issues that you could find in the Lighthouse, which are cool, but some more interesting even for the semantic of the HTML, the missing area roles, and much else.

7. Logic Business and Clean Architecture

Short description:

Normally, if we see a use effect in a component, it could be a smell of something. It's not always, it's not a silver bullet, but it might be an indicator that it could be a refactor into a custom hook. Sometimes custom hooks are not enough, at least for bigger apps, for enterprise apps. So, the idea would be to extract your logic from components. Clean architecture could make sense if you are working in a very big company. It could help test our logic business without the need of thinking about React. The logic business is what is making money for you. You could move your logic business to a different library, even for different devices, applications, and so on.

Talking about logic business, normally, if we see a use effect in a component, it could be a smell of something. It's not always, it's not a silver bullet, but it might be an indicator that it could be a refactor into a custom hook. This is a typical example of usage of use effect, and we could extract it to a custom hook. And even we could go further using use query from React query in order to avoid the need to manually match manage states for loading error and data.

But sometimes custom hooks are not enough, at least for bigger apps, for enterprise apps. So, the idea would be to extract your logic from components. So, one idea would be we have this custom hook, use real states, we are grabbing real states, but consider this scenario, a custom hook that is burdened with numerous responsibilities, like validation of the data, of the input, data fetching, and the mapping. And what is even worse is when we're trying to extract logic from our React components, and we end doing something like this. It seems that it's better, but the problem is that we are passing as parameters a way to update our local state. So, our logic should be agnostic to the framework, and this is not. This would be a little bit better. We have something that is completely agnostic to React. So, we could use this to React Native, Vue, Angular. Well, maybe not for Angular, because we don't use Angular. But for any framework, even for vanilla JavaScript. But you could go one step more using clean architecture.

Sometimes clean architecture could make sense if you are working in a very big company. If you are only a team of three, maybe it's not. It could be our engineer. But in a company with hundreds of developers, it could make sense to create value objects and entities based on the domain-specific design. Repository interfaces in order to be able to change from your Apple repository, or maybe local storage repository, or directly to database repository. You could create your own API repository. And even create a service that you could inject if you are using the API repository or a mock repository. This is great. This is helping to test our logic business without the need of thinking about React. The logic business is the most important thing that you are going to have. Because React, I hope that it's going to be alive for a few more years. But the logic business is what is making money for you. And you could move your logic business to a different library, even for different devices, applications, and so on. And have you seen this image on Twitter, right? It was the meme.

8. Server Actions and File Naming

Short description:

The useServer magic string allows you to extract server actions to a different file, making them invisible to the client bundle. It's crucial to be mindful of file naming and folder structure to avoid subtle bugs, especially on Linux-based systems. Unix systems are case sensitive, while Mac systems are case insensitive, so it's best to use camelCase for file names and folders, even for React components.

And the problem with this kind of image is that it lacks context. This is the possibility that you could do with Next.js now, with React, with the form actions. But the thing is that you are able to extract this to a different file. You are not forced to do this in line inside the button. In this case, you are able to extract all the logic of the server actions. And you could do some validations. You could do everything. And the only important thing is that you use the useServer magic string on the file. And then it becomes invisible to the client bundle.

The last thing is files, folders, and code structure. It's super interesting because there are tons and tons of articles on the internet talking about this. And it's normal because it's a challenge. It's super important about the context of each application. And because everyone has a different opinion of it. But one thing that is, for me, super, super important. If you check this code, it appears to be fine. But there is a subtle bug that could cause your continuous integration system, particularly if it's based on Linux, to fail. And it's super hard to see. And I know, by experience, that it could take hours to get the error.

The problem with this code is this. The thing is that Unix systems are case sensitive, whereas Mac systems, that is the one that we're using, except this one that is using Adele, are case insensitive. So my whole take about this is avoiding camelCase for file names and folders. Prefer camelCase even for React components. And I know that this is not popular. I know it. A lot of people now are taking photos. I know about it. But I thought, like, some years ago, that the perfect case for React components were Pascal case. And after that, I was checking a lot of repositories on GitHub about popular projects like Next.js. And they are using camelCase for all their files, even React components.

9. Import Aliases and Folder Structure

Short description:

If you don't like Next.js, it's not negotiable for me. Always use import alias to enhance maintainability of the code. Utilize a different folder structure for big and huge projects. Your architecture should inform readers about the system itself. Don't be afraid of changing your mind. Check out Advent.js, an Advent calendar with challenges for JavaScript and TypeScript.

And if you don't like Next.js yourself, because I don't know, Peanuts, even remix in the repository for components, they are using camelCase. And that is not why they invented it. I mean, there's a reason behind this. So, I know that it could be hard. But for me, it's not negotiable.

Another thing is always using import alias to enhance maintainability of the code. Import aliases enable you to avoid using relative paths in your imports. So this kind of code that are super hard to read and understand where they come from, they come from this to this. It's much clearer by utilizing import aliases.

And finally, talking about the structure. This is the classic folder structure. I mean, it's fine. It's good for a lot of things. It's perfect for a small and medium projects. But when things get bigger, it's hard to scale. This is a different kind of folder structure that is super interesting for big and huge projects. And it's that your architecture should inform readers about the system itself, rather than the frameworks and dependencies that you are using. In the classic one, you have even a folder that is called Redux. So, in this case, if you are, I don't know, building a healthcare system, then new programmers view the source repository, and their initial impression should be, oh, this is a healthcare system. Some drawbacks, of course. The learning curve is complicated. The initial overload, the duplication risk, because maybe you duplicate some components. But at the end, for huge projects, it's a must.

In 20 minutes, it's complicated to talk about all the best practices on React. I tried to share some, based on my knowledge and my experience. But the most important thing is that you don't have to be afraid of changing your mind. For me, for example, it was like the case for file systems or components on the React applications. And sometimes it's only about checking, trying, and trying again. Before we go, one more thing. I would like to invite you to check Advent.js, an Advent calendar with challenges for JavaScript and TypeScript, developed with React, of course.

QnA

Architecture and Managing Hooks

Short description:

Available in English, Portuguese, and Spanish. But if you ask me to translate it to German, I will do it. One thing which I find interesting about your talk is, you dived into some actual things people can just change in their files, in their code directly. Especially when you talk about architecture, I think about some people work in small to medium businesses, some people work in huge companies with hundreds of developers, and they have sort of different needs. And especially for the kind of small to medium businesses, like is this sometimes architecture? Is it over engineering? Are we putting more effort into building things that are bigger than the requirements we have? We have another question. The top-voted question with a lot of people asking is, how do you manage your hooks? It's very easy to create hundreds of custom hooks when following some of these tips.

Available in English, Portuguese, and Spanish. But if you ask me to translate it to German, I will do it. Well, I'm not doing it. It's a little bit difficult. But thank you.

What I'm gonna do, by the way, is I'm gonna save the fun questions for the end, all right? And we'll start with the technical questions first. But one thing which I find interesting about your talk is, you dived into some actual things people can just change in their files, in their code directly. And then you spoke to some broader kind of architectural ideas and themes. And especially when you talk about architecture, I think about some people work in small to medium businesses, some people work in huge companies with hundreds of developers, and they have sort of different needs. And especially for the kind of small to medium businesses, like is this sometimes architecture? Is it over engineering? Are we putting more effort into building things that are bigger than the requirements we have? Absolutely. I mean, I wanted to share my experience working on a huge project, because I think it's important. And usually we don't talk about it. And we use clean architecture on the front-end side, which is not common. But obviously, I don't recommend people from a small company, three people on the team, 15 people. Maybe it's not worth it. But even that, they could try to separate the logic on one file, agnostic from the framework. And that, for sure, is going to help. It's super easy, cheap. It's like less than one minute. And it could help you to try to test better, share this logic with another components, or maybe even to move to a React native application and use that logic. And it's like one minute of that. And I think that's the good thing about clean architecture, is that it spills out into all the other things. Like your tests will thank you. If you need to go cross-platform, they will thank you and all of those things. So great answer. Great answer.

We have another question. The top-voted question with a lot of people asking is, how do you manage your hooks? It's very easy to create hundreds of custom hooks when following some of these tips. So we're going to have lots of different talks. Lots of different people are going to come up with different hooks that people should use.

Managing Hooks and Million.js

Short description:

The idea of the scrimming architecture folder structure makes it easier to create and manage hooks. Million.js has some compatibility issues and requires adding an exclude component array. It offers a drop-in replacement for React internals. Test-driven development is useful in some cases but not necessary all the time.

How do you manage all of them? Yeah. Great question. That's why I wanted to introduce the idea of the scrimming architecture folder structure. Because if not, you have a folder called hooks. And you have like 100 hooks inside. Then you have to check like, OK, where is the one that I need? Or I'm going to duplicate some. So the idea with the folder structure of the scrimming architecture is that, as you are managing the hooks components or something else, based on your features or your logic business, it's going to be easier to create and manage those hooks.

I totally understand it. And the next one is, I think I missed this in your code, but it's what is the catch with Million.js? Can you drop in a replacement without any errors? So, yeah, of course, there is a catch. One catch is that it's not 100% compatible. There are some kind of corner cases. For example, you have to add exclude component array in order to avoid to use it everywhere, because it could be problematic. And the other catch is that you are adding a new dependency. Maybe there's some cost in the compilation time, build time. But other than that, the catch is that I love React. But Virtual DOM and even some internals from React, they're a bit old. And it's very easy to create a drop-in replacement better than some internals that we have from React. I love React, but it has some time now.

Absolutely. There are definitely some things that only make sense in the React ecosystem, make no sense anywhere else as well. We've got another question, and this one is about test-driven development. What do you think about it? I love TDD. But for me, there is no silver bullet. I know that there are people that I only develop using test-driven development. Sometimes I use it, especially for logic, because I could create the logic, return the JSON directly, and then go backwards trying to make the test pass and so on. But I don't know. It depends. Some days I want to try TDD and use it. And sometimes I'm more creative, and I try creating the component. So I think that it could help in some cases, but I would like to use it only when it makes sense, not 100% of the time.

Testing, Toolkits, and Pizza

Short description:

Writing tests has its own ecosystem of bugs and errors that are not your code. Zustand is great for small projects, while Redux Toolkit is better for larger ones. Context API can be used for static states. Each solution has its drawbacks and advantages. Let's move on to some fun questions. Why not paella? Pizza is more universally understood. What's your favorite pizza? As long as it doesn't have pineapple, any pizza is acceptable. My favorite is chicken with chocolate.

Yeah, totally. We were at TestJS Summit yesterday, and it's really interesting how writing tests has its own ecosystem of bugs and errors that are not your code. Your code could be fine, and then the tests have a problem, which is really interesting. And there is no silver bullet. It is the classic it depends answer. It depends, yeah.

For sure, for sure. We have another one. This is more about tools and toolkits. Why Zustand over Redux Toolkit? So it's the same. It depends. I mean, even why not Context API? Context API could make sense for a state that is not going to change often for something that is static. Zustand is great, for example, for small stores, small projects. If it gets bigger, Redux Toolkit, the good thing that you have, it's a great documentation, a great community. Now you have immutability that is great as well. The problem is that it's bigger, but I mean, there are drawbacks and good things of each solution.

No, totally. All right, we have less than a minute left to finish. I won't be able to go through more of the technical questions, but let's go through some of those fun ones. You chose pizza. Why not paella? It's more complicated to share a joke about paella here because maybe people are going to think that paella is great in every photo. It doesn't matter. But in pizza, it's not normally having a chicken. Maybe you get a chicken and maybe people think that's normal. I'm pretty sure there are some Italians who were screaming internally at the screen when they saw that picture. Speaking of that, what's your favorite pizza? Wow, that's a complicated one. Please, just as long as it doesn't have pineapple in it. If there's any right answer, accept that one. No, no. My pizza is chicken with chocolate.

Favorite Pizza and Online Presence

Short description:

My favorite pizza is sobrassada, which is like butter with honey and cheese. For more information, check out the speaker Q&A and discussion room. You can find me online at Middle-def everywhere.

No, no, no. My favorite pizza is a special one because it's sobrassada. I don't know the word in English, but it's like some kind of pepperoni, but it's like butter with honey and cheese. Awesome.

We've run out of time, but people want to find out more. Someone was asking about the GitHub. They can find you over at the speaker Q&A and discussion room. Awesome. And where can people find you online? Middle-def everywhere. All right, check him out. Give him a round of applause.

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 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
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 Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 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
React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
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 Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
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
Featured WorkshopFree
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
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
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
Prerequisites- 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
React Day Berlin 2022React Day Berlin 2022
53 min
Next.js 13: Data Fetching Strategies
WorkshopFree
- 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
160 min
React at Scale with Nx
WorkshopFree
The larger a codebase grows, the more difficult it becomes to maintain. All the informal processes of a small team need to be systematized and supported with tooling as the team grows. Come learn how Nx allows developers to focus their attention more on application code and less on tooling.
We’ll build up a monorepo from scratch, creating a client app and server app that share an API type library. We’ll learn how Nx uses executors and generators to make the developer experience more consistent across projects. We’ll then make our own executors and generators for processes that are unique to our organization. We’ll also explore the growing ecosystem of plugins that allow for the smooth integration of frameworks and libraries.