Building the Right Product and Building It Right: Extreme Programming and Atomic Design

This ad is not shown to multipass and full ticket holders
React Summit US
React Summit US 2025
November 18 - 21, 2025
New York, US & Online
The biggest React conference in the US
Learn More
In partnership with Focus Reactive
Upcoming event
React Summit US 2025
React Summit US 2025
November 18 - 21, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

Have you heard about Atomic Design? How about Extreme Programming and Test Driven Development? For sure you have heard about React - a few things, I bet. In this talk you will get some insight on leveraging the power of Atomic Design to build the right product (using React, duh!) and capitalize on Extreme Programming and Test Driven Development to build it right ( exploring the React Testing Library).

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

FAQ

Extreme programming (XP) is an agile software development methodology aimed primarily at improving software quality and responsiveness to changing customer requirements. It was created by Kent Beck in 1996.

The core values of extreme programming include communication, simplicity, feedback, courage, and respect. These values encourage vibrant team interaction, minimalistic designs, frequent feedback loops, the bravery to make tough decisions, and mutual respect among team members.

Atomic design is a methodology for creating design systems with a hierarchy that includes atoms, molecules, organisms, templates, and pages. It was developed by Brad Frost in 2013.

The Volkswagen Software Development Center in Lisbon integrates extreme programming practices such as paired programming and test-driven development to enhance team collaboration and software quality.

Designers in Volkswagen's Lisbon center act as a bridge between the team and the users, identifying user pain points and crafting solutions to improve user experience.

Test-driven development (TDD) ensures that testing is done early and frequently, leading to better defect detection, cleaner code, and a more robust software product.

In React projects, atomic design is adapted by structuring UI components into atoms, molecules, organisms, templates, and pages, allowing developers to build consistent and scalable user interfaces.

Paired programming aims to enhance code quality and knowledge sharing within a team by having two developers work together at one workstation, where one writes the code and the other reviews it.

The system provides dealers with a dashboard to monitor the status of car orders, improving communication between dealers and customers and enhancing the overall customer service experience.

Rita Castro
Rita Castro
23 min
14 May, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
This talk explores extreme programming (XP) and balanced teams, emphasizing the importance of simplicity and team collaboration. The application of XP practices, such as paired programming and test-driven development, is discussed, along with the organization of frontend code. Atomic design is introduced as a methodology to solve dealer problems, and the process of creating the user journey and identifying atoms is explained. The talk also delves into testing components and the completion of the user journey using XP and Atomic Design.

1. Introduction to XP and Balanced Teams

Short description:

Welcome to this talk about extreme programming and atomic design. I'm Rita, a software developer at Volkswagen. I'll explain how to build the right user-driven digital product using quality UIs and test-driven development. I'll also discuss translating designs to React. The Software Development Center in Lisbon opened in 2018, introducing XP and balanced teams. XP, driven by communication and simplicity, benefits developers and the whole team.

Welcome to this talk, where we'll tell you a little bit about extreme programming and atomic design.

First thing, first things first. Hello, my name is Rita. I'm a geek at heart and I really like to play sports. I'm also a mom, which means that whenever I'm not, I'm not with my family. That means that I'm probably working. I work at the Volkswagen Software Development Center here in Lisbon and these are my amazing colleagues and teammates.

So about this talk, I will try to tell a little bit on how to build the right product and from where I stand, I think a good product should be user driven and it should be a digital product bear in mind. And it should be done using consistent and quality UIs, because you want your users to be engaged with it. And how exactly can you build it right? Well, you should have tests for it. Tests are an important part of software development. And in fact, they're as important as how they are done. And to me, the best way of doing tests is to do test driven development.

On the other hand, and since this is React Summit, of course you want to go from designs to React. So you want to have an easy way to translate what you have from your designs to React. How can we achieve this? This is what I'm setting myself up to tell you and talk to you about.

The Software Development Center in Lisbon. It was created in 2018. It was the first development center that Volkswagen opened outside of Germany. And they chose to do so in Lisbon. I wouldn't think. And I thank you for that, so I joined. I already knew and I already did test-driven development and used to work in an agile framework. Let's put it this way, but they pitched in something new, something different, which was XP and balanced teams. So XP stands for extreme programming and it was created back in 96 by Kent Beck. And it is an agile way of developing software. It is mainly targeted for developers, but the rest of the development team, it also can take a lot of advantage from what XP stands for and what it encompasses at its core and what does it encompass in its core.

So it's driven by five core values, the value of communication, keep the chat and the conversation going on within your team, because with this, you are to share information, you are able to transfer knowledge from one person to the other, regardless of the role they have in your team. Simplicity, when you're building the product, build it the leanest way as you can.

2. Simplicity and Team Collaboration

Short description:

Build the product in the leanest way possible to get frequent user feedback. Have the courage to discard what doesn't meet user needs. Respect and value the opinions of the entire team.

Simplicity, when you're building the product, build it the leanest way as you can. Why? So that you can get feedback from it really, really often. You don't want to be developing something that the users won't need, or that the users don't want, or that it's poorly developed and unusable. So get feedback as fast as you can. Have the guts, or the courage to toss things away if they're not what the user needs or wants, regardless of how much you've invested in it. And most important, have respect amongst your team. Each and every decision you make for your product, it is a team decision. So it is not something that you do by yourself. Everyone's voice is heard. Everyone's voice is respected. Opinions are worth it, and you can voice them out loud.

3. XP Practices and Organizing Frontend Code

Short description:

To apply the values of extreme programming (XP), we focus on paired programming and test-driven development. Paired programming allows us to share knowledge and communicate effectively. Test-driven development helps us build only what is necessary. We work in integrated and balanced teams composed of designers, product managers, and developers. Designers bridge the gap between the team and users, understanding their pain points and proposing solutions. Product managers handle the financial aspects and break down features into manageable stories. As developers, we evaluate feasibility and act as gatekeepers of technology. Working together, we achieve magic. In the Software Development Center (SDC), I have worked on four products using React as the front-end framework. We used to follow feature-driven development, but as the products grew, we needed a better way to organize our frontend code.

However, these values, they're a bit barren if you don't have any sort of practices that you can use them upon. So the two values that, the two, sorry, the two practices that we like to stand out from XP are paired programming and test-driven development. For paired programming, it is important because you are able, again, to share the communication, to share the knowledge that you have amongst yourselves. So regardless of your role in the team, you're going to pair. So you're going to be working with someone that will share the information that you're building upon. Test-driven development, so that you do just what is needed to get your feature up and running. Where do we do this? Integrated and balanced teams. What are they then? They're composed of designers, product managers and developers, us. What do designers bring to the table? Well, they are the bridge between the team and the users. They understand what are the pain points that the users have and they come up with solutions to make their lives a lot easier. What do the product managers do? Well, they take care of the money and they break down the stories. Sorry, they break down the features that we want to build for our product into stories that we, the developers, can do. And what do we do? Well, apart from coding, we're also the ones that are responsible for seeing and evaluating if something is feasible to be done. We are the gatekeepers of the technology, but we are also the ones responsible for evaluating the feasibility of the product. What happens when all of us work together? Magic happens. That's what. In the SDC, me. So, I joined in 2017, as I told you. Sorry, 2018, as I told you. And now it's 2021. What have I done in the middle? Apart from having the kit, I have worked in four different products. All of them had React as its front-end framework. Why did we choose so? Because, in quoting the documentation from React, React is supposed to make our lives a lot easy. It is supposed to make it painless to create interactive UIs. And you should be able to build encapsulated components so that you can make these UIs in a very easy and good way. However, we used to do feature-driven development, a loose adaptation of it at least. Which means that for every feature that we wanted to develop within our code or within our product, we would have a folder for it and then we would start nesting out things that are specific to that feature in it. And if we had components that would be reused and shared throughout a couple of features, we would extract them to the components feature. But then as the products began to escalate, the features became a little bit too crowded, let's put it this way. So we had to find a different way of organizing our frontend code.

4. Atomic Design and Solving Dealer Problems

Short description:

Atomic design is a methodology created by Brad Frost in 2013. It consists of five levels of elements: atoms, molecules, organisms, templates, and pages. We are applying this methodology to solve a problem faced by car dealers. They need to keep track of the status of each order and communicate it to customers. Through user interviews, we identified three key assumptions: dealers want to know the order status, be updated about it, and share the information with customers. We, as developers, have confirmed that we can extract and integrate the necessary information into the existing dealer product.

Enter atomic design. What is it? It is design methodology and it goes into creating and maintaining anything from the design system. It was created by Brad Frost into 2013. And it's composed of five different levels of elements.

Please bear in mind that this is a design framework, so we're going to do an adaptation from a design framework to React. So how is it structured? So there are atoms, which are the most basic elements of all. If you combine atoms together, you will get molecules. If you join molecules and other atoms, or eventually, molecules and organisms as well, you'll get organisms. And when you set out, when you build the layout and you decide, okay, this goes here, that goes there, etc., you have a template. And when you pick the organisms and you put them on your template, you get pages. So it's a linear flow to build your UI, and it's quite easy.

So having this in mind, I'm gonna tell you the experience that we're currently doing in the SDC. We are trying to solve a problem or what we perceive as a problem from the dealers, from the dealers that sell cars. So, imagine that you're a dealer, you sell a car. You sell a car to a customer today. You sell another car tomorrow to a different customer and tomorrow and tomorrow and tomorrow. So, you sell a lot of cars because you're good at it. In average, dealers sell around 20 cars per month and each of these cars, so each of this order, takes around three months to be fulfilled. So, within this time span, the dealer needs to keep track of what's the status of the order. Is the car here, is it about to get here? Is it delayed? Well, if you don't communicate with your customer, it is really, really likely that the customer will pick up the phone and call and say, hey, where's my car? And that's a problem because then the dealer has to be able to find the information about the order of that customer really, really fast because you don't want them holding back.

So, how am I able to tell you all of this? Because we did a lot of user interviews with dealers so that we would understand the pain points and the needs that they have. With that, our designers formulated three assumptions. The first one being that the dealers want to know the status about their orders. The second, that they want to be updated about those status. And the third, that they want to be able to share that information with the customers. Given that, we think we can come up with something. So, us, the developers, we checked if it would be possible to get information from the orders. It is, because we can integrate with the systems that are really, really old, but we are able to extract information and provide it for the dealers. Can we integrate it in a product that is already used by the dealers, so that this isn't just another tool that they have to use? Yes, we can also achieve that. So, we're on the good side.

5. Creating the User Journey and Identifying Atoms

Short description:

In this case, the designers create the user journey, specifically the dealer's journey. The dealer opens a browser and sees a dashboard with information about all their orders. They can view the details of each order and check its status. To achieve this, we use React testing library for test-driven development and the Atomic Framework for consistent UI design.

In that case, it's up for the designers to create something that we call the user journey. The dealer's journey, in this case, because the user is a dealer. And what is it? So, you open your browser, you have a dashboard with the information about all the orders that you have. At a glance from the top, you are able to see the information about the other orders in a set of tabs. Below the tabs, you have information about all of the orders that you have available. Imagine that Lisa Marie calls, hey, I want to know what's wrong with my car. The dealer clicks on the button that says View details, and they are taken to a different page, the Details page. In the Details page, you get to see the details for Lisa Marie. So, all of the information about the order or the information that was deemed relevant about the order, and you check the status of the order. How is it? Is the car delayed? Is it in production? Is it arriving to the country, etc? Given this, and having a little bit of a throwback to the beginning of this talk, the fact that it's user-driven and that we want to do test-driven development for our product, this means, and the fact that you want to have an easy way to go from design to code with consistent UIs, well, for the first one, let's use React testing library. It's really, really good, it's solid, and it does what we want. For the design part, let's use the Atomic Framework that I just presented you. Then, in reality, we are doing nothing more than using XP with the Atomic Design. Let's see how it goes. So, let's start. And let's start by what? By writing a failing test, because that's how the test-driven development flow works. But which test are we going to write? Good question. Let's start small. What can be smaller than atoms? Nothing, in this case. So, let's take the dashboard. From the dashboard, let's try to identify a few atoms from the designs.

6. Atoms, Molecules, and Testing

Short description:

Atoms are unbreakable components that form the base of the UI. Implement tests to check for specific elements and fulfill the implementation. Pair programming allows for more specific tests and objective code. Use mocked components for flexibility. Molecules are atoms bonded together to provide functionality, such as the search bar and order progress.

Okay, we already know they are unbreakable components, and they will provide us the base tiles from the UI, which means that we can have the view details button as an atom, a formatted date as an atom, text as atoms, icons, to say, to name a few.

Then, we can implement a test for it. You render the view details button. You expect the text to be in the document. And you expect that there is a link to take us somewhere else. In this case, React Summit in Amsterdam. Why not?

Then, then, then you run the test. When you run the test, of course it will fail because your implementation has nothing. What do you do? You fulfill the implementation to or you do the implementation to be able to see a text that says view details. There you go. There's a paragraph with view details, that part of the test has passed, but you still get an error for the link.

Yeah, we're a little bit naughty here. We cheated a little bit on the test because, well, not cheating, we were playing a little bit. So with the pair programming, usually one person does a test, another person does the code. It's called ping pong. And sometimes you want to be able to, to dare the person writing the test to be more specific and to be as objective as possible so that it leaves you no room for free interpretations with your test. So with that said, fine, I'll give you a link. And when you have a link, tada, the test passes and we're good to go. A small detail is that I'm using, in the previous test that I showed you, I was using a mocked component for the React router DOM, so instead of using the actual link, I was mocking it. Why? So that I don't have to wrap the component that I'm rendering with the memory router. There is no right or wrong, there is no good or bad in the middle of this, you need to understand what makes sense for you and makes sense for your team and stick with it. So, you do you. No right or wrong, you decide what is the best. So the team talks among themselves and they see what is best for them. But whatever you do, be consistent.

Moving up in the atomic ladder, we have molecules. Molecules. What are the molecules? Molecules are atoms bonded together. So, they did something that brings functionality. The search bar, the order progress, for example.

7. Order Progress and Organisms

Short description:

The order progress has two elements: the text in transit and the transit icon. Organisms are a combination of atoms, molecules, and other organisms that bring user value. The orders list needs to include the text 'all orders' and components for the search bar, filters, and orders table. Mocking can encapsulate everything and provide a clear view, but it may drift away from the user experience and introduce shallow rendering. It's important to find a balance and consider the team's decision.

So, the order progress, it has two elements, it has the text in transit and it has the transit icon. It is, you render the thing, you expect the text to be there, you expect the icon to be there. Excellent. Let's see how it goes. You get it there. It's really, really easy, it's really, really fast. From designs.

Next in the ladder, organisms. Organisms are a flock of atoms, molecules and even other organisms. And most important of all, they bring you user value. So with the user value, what do you have? You have these two main elements. So the tabs list and the orders list. But then, let's build a test for it. So the orders list, it needs to have the text that says all orders and it needs to have the components for the search bar, the filters and the orders table. Sounds good. But then you're mocking it. So at this time, you need to be able to understand and decide what you want to do to mock or not to mock. So a pro con list. When you're mocking, it is really, really good because you get to encapsulate everything. You don't need to know the details of the elements that you're using down below the tree and you get a clear view of what you're using. You don't get to do any cheating. So if you want to have a text, you need to have a text, not a paragraph that says text. And it's really, really easy for new team members to get on board to the new concepts. However, we drift a little bit away from the user experience. We've got a little bit of shallow rendering going on. And sometimes mocks can be tricky. Especially if you're using third-party libraries. Again, it is a team's decision to choose what is best. And what I can recommend you is that you will find your balance if you follow this road. So on one hand, you'll have unit tests.

8. Testing Components and Dealer's Journey

Short description:

On one hand, for unit tests, mock the components to ensure you're using the right ones. On the other hand, for integration tests, render the components to verify their correct usage. Tests that resemble your software give you more confidence. An example test for the order list organism checks the presence of the heading, row contents, and a clickable button that redirects to a different page. Templates and pages are created by placing organisms in the defined layout. The details page consists of atoms, molecules, and organisms. A test for the dealer's journey checks the presence of the dashboard.

On the other hand, you will have integration tests. So for the unit tests, you should mock them all. So this will allow you to make sure that you're using the right components to build your product. But then on the other hand, for the integration tests, you should render them all, because then you will be sure that you are using them right. And this is this resembles a little bit, or this flashes takes us back to a quote from Ken C. Dodds from the creator of React testing library.

So the more your tests resemble your software, the more confidence they give you. And that's damn right. And why? Because now we can build a test for the orders, the order list organism, in which, okay, we know that on the route, we have the orders list. And we know that eventually when we have the link that will take us to the order, we will be on the details page. So when we open the page or when we render the page, we expect to have the heading for the all orders to be there. Then we expect to have the contents of the row to be displayed. For example, a car, I'm buying a car. You expect to have the button, the link button for with the view details to be clicked, and then you click on it. And when you click on it, you get redirected to a different page. So this is good. This is a valuable test. This resembles how the user is interacting with your software.

For completion, and to wrap it up, templates and pages. If you define the layout, you place the organisms there, you get a page. Cannot be as simple as it is. The other page that we have in our design is the details page. It looks like this. It's composed of also. It has atoms, it has molecules, and it has organisms. Perfectly fine. We're not gonna dwell into that. Let's go back to the dealer's journey. We can write a test for the dealer's journey, and it would look something like this. You rendered the dashboard, you expect to be in the dashboard, so we expect the region dashboard to be there.

9. Completing the User Journey

Short description:

You expect to see the tabs, all orders, search bar, and filters in the dashboard. You would like to see information from the table, get the DRV label for a row, and go to the details page. Clicking the back button takes you back to the all orders page, completing the user journey. XP with Atomic Design allows for delivering high-quality software with consistent UIs faster than ever before.

You expect to see the tabs. Also good. Within the dashboard, you expect to see the all orders, you expect to have the search bar for the search all orders, you expect to have the filters, so you can achieve that with the implementation of the dashboard. Eventually you would really, really like to be able to see information from the table. So to get something from the table, you can get the DRV label for a given row, and then click the link button and be able to go to the rest. When you go to the rest, you know that you're no longer in the dashboard page, but you are now in the details page.

Finally, you've seen all there is to see, you click on the back button, and when you click on the back button, you're taken back to the all orders page. So, things are clean, things are nice, and this completes the user journey. So with one test, one somewhat big test, you are able to do the complete user journey described in a way that is as close as possible to the way the user is going to interact with your software.

So, to wrap up, I really, really think, it is my personal opinion, that when you use XP with Atomic Design, you get a very sweet spot. And this sweet spot is that you're able to deliver high quality software with consistent and solid UIs faster than ever before. Any day of the week, including Fridays. So thank you so much for attending. I'll talk to you soon. You can find me on any of those social media.

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.
Don't Solve Problems, Eliminate Them
React Advanced 2021React Advanced 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured Workshop
Ivan Akulov
Ivan Akulov
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
Next.js for React.js Developers
React Day Berlin 2023React Day Berlin 2023
157 min
Next.js for React.js Developers
Top Content
Featured WorkshopFree
Adrian Hajdin
Adrian Hajdin
In this advanced Next.js workshop, we will delve into key concepts and techniques that empower React.js developers to harness the full potential of Next.js. We will explore advanced topics and hands-on practices, equipping you with the skills needed to build high-performance web applications and make informed architectural decisions.
By the end of this workshop, you will be able to:1. Understand the benefits of React Server Components and their role in building interactive, server-rendered React applications.2. Differentiate between Edge and Node.js runtime in Next.js and know when to use each based on your project's requirements.3. Explore advanced Server-Side Rendering (SSR) techniques, including streaming, parallel vs. sequential fetching, and data synchronization.4. Implement caching strategies for enhanced performance and reduced server load in Next.js applications.5. Utilize React Actions to handle complex server mutation.6. Optimize your Next.js applications for SEO, social sharing, and overall performance to improve discoverability and user engagement.
Concurrent Rendering Adventures in React 18
React Advanced 2021React Advanced 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Hooks Tips Only the Pros Know
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
Introducing FlashList: Let's build a performant React Native list all together
React Advanced 2022React Advanced 2022
81 min
Introducing FlashList: Let's build a performant React Native list all together
Top Content
Featured Workshop
David Cortés Fulla
Marek Fořt
Talha Naqvi
3 authors
In this workshop you’ll learn why we created FlashList at Shopify and how you can use it in your code today. We will show you how to take a list that is not performant in FlatList and make it performant using FlashList with minimum effort. We will use tools like Flipper, our own benchmarking code, and teach you how the FlashList API can cover more complex use cases and still keep a top-notch performance.You will know:- Quick presentation about what FlashList, why we built, etc.- Migrating from FlatList to FlashList- Teaching how to write a performant list- Utilizing the tools provided by FlashList library (mainly the useBenchmark hook)- Using the Flipper plugins (flame graph, our lists profiler, UI & JS FPS profiler, etc.)- Optimizing performance of FlashList by using more advanced props like `getType`- 5-6 sample tasks where we’ll uncover and fix issues together- Q&A with Shopify team
React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured Workshop
Paul Everitt
Paul Everitt
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.