How to do Good Without Doing Anything

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.

In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.

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

FAQ

Web accessibility is about ensuring that all users, regardless of their circumstances, abilities, or disabilities, have the opportunity to participate on the web and in society broadly. It involves making web applications accessible to everyone, preventing gatekeeping that could exclude certain populations.

After shipping a product to production, maintaining web accessibility involves ongoing maintenance, bug fixes, and feature development. Continuous testing and automation play key roles in safeguarding against bugs and regressions that may affect accessibility.

Uraima Estevez recommends tools such as the ESLint plugin JSX Accessibility for static code analysis, Lighthouse for running accessibility audits, and React Axe for testing accessibility in React applications dynamically. Additionally, axe-core is suggested for its powerful API used in automated web UI testing.

The ESLint JSX Accessibility plugin helps developers catch common accessibility mistakes during the coding phase. It integrates with development environments to provide real-time feedback and can be automated with GitHooks to prevent inaccessible code from being committed.

Lighthouse is an automated tool that runs accessibility audits on webpages to assess how accessible a website is. It provides a score based on adherence to accessibility standards and offers detailed feedback on areas for improvement to help developers enhance web accessibility.

React Axe displays accessibility errors directly in the Chrome DevTools console, providing real-time feedback as the user interacts with the page. It includes severity ratings for issues and links to resources for fixing them, making it valuable for dynamic testing of React applications.

axe-core serves as a low-level API that powers tools like Lighthouse and React Axe. It allows developers to customize testing workflows and processes to fit specific use cases, making it a foundational tool for building comprehensive accessibility testing suites.

Important tests for web accessibility include unit tests to check individual components, integration tests to examine interactions between components, and end-to-end tests to ensure overall user flow accessibility. These tests cover everything from ARIA attributes to keyboard navigation.

Yuraima Estevez
Yuraima Estevez
32 min
25 Oct, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Accessibility is about making sure everyone can participate on the web, regardless of disability. Automated tools like Lighthouse and React Axe help identify accessibility errors and provide guidance on fixing them. Unit tests validate ARIA attributes and keyboard navigation, while integration and end-to-end tests focus on outcomes and simulate user experiences. Cypress.io is an open-source testing framework with excellent accessibility support. Implementing small changes leads to a deep understanding of web accessibility and bug resilience.
Available in Español: Cómo hacer el bien sin hacer nada

1. Introduction to Accessibility and its Importance

Short description:

Hello React Advanced, I'm Uraima Estevez, a front end dev manager at Shopify. Accessibility is about making sure everyone can participate on the web, regardless of disability. Web accessibility keeps the web inclusive and prevents gatekeeping. It goes beyond the build phase, requiring maintenance, bug fixes, and feature development. Testing and automation help protect the user experience and save time. Building accessibility testing and automation suites is an upfront investment that pays off in the long run.

All right, here we go, hello React Advanced, very excited to be here today with you remotely. My name is Uraima Estevez. I am a front end dev manager over at Shopify on the Polaris Design System Team. If at any point you want to follow along with these slides, feel free to pop over to a11y-testing.uraima.com. And if at any point you do want to show me some love on Twitter or you want to ask some you can feel free to find me at URAM04.

So let's dive right in. I'm going to start by figuring out what is accessibility. So in my mind, accessibility is all about our users. And I mean all of our users, every single one of them. It's about making sure that everyone has an opportunity to participate on the web, in our mobile apps and more generally in society. And accessibility ensures this regardless of a person's circumstance, ability or disability. Web accessibility is really about keeping the web inclusive. Tim Berners-Lee, father of the internet, says here that the power of the web is in its universality. Regardless of disability is an essential aspect of it. So for us as engineers, web accessibility is about making sure that we don't gate keep certain populations of people from being able to access the web. And this is exactly what could happen if we aren't intentional about how we build our apps so that they do work for everyone.

And just like every other aspect of our work, accessibility goes beyond the build phase of an application or a website. Your work simply is not done right after you ship to production. There's maintenance, bug fixes and feature development that all come right after you ship to prod. And really every time we make a change in the code bases that we work in, we could potentially ourselves up to bugs and regressions. And in some ways, this is a fairly solved problem. We've found some pretty good ways to protect ourselves from unintentionally creating bugs or degrading our user experiences. And we do this through testing and automation. We've managed to cut down the time in running these tests and other processes and have found the ways to help protect the experiences that we're building on the web. So if we build out our components and apps as accessibly as possible, we write tests against them to validate that their behavior is being guarded against bugs and then we find those opportunities to automate some of those processes in our accessibility development cycle, we save time and build confidence in our systems that they will work for everyone and consequently make the web better for everyone. And we can sleep soundly knowing that we've built and kept our applications inclusive with very little effort in the long run. And that very last sentence is the caveat here, in the long run. As you know, building out accessibility testing suites, building out automation suites, these are things that take time and effort upfront, but once you have those in place, they really do have a really great return on the investment that you're making. So in a way, you'll be able to say that you're doing a lot of good without doing anything all once you make that investment. Sort of.

2. Automated Tools for Accessibility and Lighthouse

Short description:

We'll discuss automated tools for accessibility, including the JSX Accessibility ESLint plugin and Lighthouse. The plugin helps catch common accessibility mistakes during development and can be automated using GitHooks and CICD pipelines. Lighthouse allows running accessibility audits on webpages, providing insights and a score out of 100 to measure accessibility adherence.

So we're going to break this up into two parts. We have our tools, which are going to be the automated tools that we're going to use at different stages in our development process. We are going to get some help automating the harder tasks that a lot of times we end up doing, and this is going to help keep our code bases free of accessibility bugs. And then we're going to talk about testing. We'll discuss what kinds of tests we write and what we want to be validating when it comes to accessibility support in our components and our apps.

Now quick disclaimer before jumping in. I am assuming you have a pretty good grasp of accessibility concepts and testing concepts so I'm going to make an assumption that you are pretty good at the best practices, the common lingo, and any syntax that I throw around. If you need a primer on accessibility, I have a couple of recorded talks that I've linked in this slide and if you would like a couple of primers on testing fundamentals, I can also tweet out a few helpful resources that I've found really helpful along the way. So with all that said, let's dive right in to tooling.

So I really like to start off with this ESLint plugin, JSX Accessibility. This is a set of accessibility linter rules that are going to check your JSX elements and React during your development. So this is super low-lift because most people, especially most people here, probably already have some sort of linter in their code base, and likely are using something like ESLint. So this is going to help you catch the most common accessibility mistakes in your code while you're writing your code. Another bonus is that you can automate all of this using GitHooks to prevent inaccessible code from getting committed. You can also throw it into your CICD pipeline and fail any builds if errors are thrown, so that you can prevent accessibility errors from making it into production.

Moving right along, we're going to talk about Lighthouse. This is an open source automated tool for improving the quality of your webpages. More specifically, Lighthouse allows you to run accessibility audits on your website. This is going to give you a really good understanding of just how accessible your website is. It's going to help you unearth any issues that you might need to resolve. Lighthouse comes in a few different flavors, Chrome DevTools, Command Line, CI Systems, and a really helpful web UI. All of these are going to be great for any different stages in your development process and can really be tailored to the way that you like to work. For now, we're going to take a look at Lighthouse and the Chrome DevTools because that's how I like to use it, but there's really a lot of documentation out there for any other use case that you want to explore. So in the Chrome DevTools, we're just going to pop into the audits tab. Now you're going to see Lighthouse offers us a list of audits that we can run with a few different options that we can set. So here I have the accessibility category, and we're going to run it against a desktop device. By click generate report, it'll take a couple of minutes, and then we're going to see that Lighthouse gives us a full audit of the web page that we just ran it against. That's going to give us a score out of 100. So this score is going to let us know how accessible our website is by checking if we're adhering to accessibility standards and best practices. So we want to get to as close to 100 as possible.

3. Automated Accessibility Testing Tools

Short description:

Now, along with our score, we are also going to get a list of where we lost points for when we didn't exactly meet those best practices or standards. Lighthouse is not just for accessibility support, but also for running different audits. React Axe tests the accessibility of React applications and displays the results in the Chrome dev tools console. Lighthouse and React Axe identify accessibility errors and provide guidance on fixing them. Axe-core is a powerful API used by Lighthouse and React Axe for automated accessibility testing.

Now, along with our score, we are also going to get a list of where we lost points for when we didn't exactly meet those best practices or standards. If you see here, I ran it against the Polaris DevTool web page documentation. And on the previous page, we got 100 out of 100, really great stuff, navigated into another page in the Polaris documentation. And we got docked a couple of points here. So another thing that's really great about Lighthouse is that when we do lose points out of that 100 point score, it's going to give us some pretty helpful tips for how we can fix those errors. Here, you see that we actually have some heading elements that are not in sequentially descending order. If I click into this error, it'll give me a little bit more details around how I can exactly fix this error and bring that score back up to 100. So I really like to use this Lighthouse tool as I'm making changes in my code, basically to make sure that I'm not unintentionally degrading my accessibility to support and to keep me as close to that 100 out of 100 as possible.

Now, something that I really, really love about Lighthouse is that it's not just for accessibility support. We can also use it to run a bunch of different audits. We have performance, best practices, SEO, progressive web apps, really anything that we can think of in order to have a top-quality website. So all of this is rolled into one tool so that we can make sure that we're building the best website possible. And fun little fact here is if you get 100 out of 100 across multiple different categories, you get a really nice little surprise at the end.

Our next tool that I always like to talk about when talking about React accessibility testing is React Axe. Now this is another open-source tool that is going to test the accessibility of our React applications and it's going to display those results in the Chrome dev tools console. So here I'm actually using the New York Times 30-Day Wellness Challenge as a demonstration. I'm going to open up the dev tools console and right away we're seeing that React Axe is highlighting all of the accessibility errors on the page. So these errors are going to include something called a severity rating. It's going to range from minor to moderate to severe and these ratings are basically going to give us a very quick understanding of how badly does this affect my user experience and how should I prioritize fixing those errors. Along with those errors it's going to give us a link to a really helpful resource for details on what the error is exactly and some ways that we can fix it. So in a lot of ways Lighthouse and React Axe are pretty similar. They essentially are telling us where we have made errors in our accessibility support and how to fix them. One really key difference here to note is that you saw Lighthouse really is only checking after a page has loaded and you're essentially statically checking that page. For React Axe you're seeing here that I'm clicking around interacting with the page and as I'm interacting with it, it's giving me new errors. It is rendering as I go and as I am dynamically interacting with this website. So React Axe is a really great way to test out that not just at the initial page load that our website is as accessible as possible, but as my user runs through the website or the application to make sure that all of my bases are covered.

So last tool I want to talk about today that I won't get too into, but it is a really important one to hit, is axe-core. This is an accessibility engine for automated web UI testing. So axe-core is essentially a really powerful lower-level API that helps with running automated accessibility tests and processes. And a fun fact about axe-core is that because it is such a low-level and powerful API, both Lighthouse and React-Axe are built using the axe-core API.

4. Automated Testing with Unit Tests

Short description:

We'll cover the main three kinds of tests: unit tests, integration tests, and end-to-end tests. For unit tests, we validate a component's API and behavior, such as aria attributes and keyboard navigation. React testing library and Jest are recommended tools. Let's start with an accessible button. We'll ensure the correct rendering of the aria-label attribute and handle cases when it should not be rendered.

So essentially that should signal to you that this is going to allow you to take full control over the workflows, the processes, and the tests that you want to build to custom fit your specific use cases. And that really wraps it up for tooling that I want to go over. We talked about a couple, and that is really by no means an exhaustive list of the tools that are available for your JavaScript applications when it comes to accessibility testing but I think this is a pretty good start to get you at least thinking about your accessibility development processes and where you can start to automate some tasks.

So now let's move into our testing, we're going to talk about some automated tests that we can check to make sure we're keeping our apps accessible. So quick disclaimer, I'm going to share the tools that I use but the frameworks and the libraries that I call out here really don't matter all that much. What I want you to pay attention to is what I'm testing and why it's important to test them. So we're really going to cover the main three kinds of tests that are relevant to us and these are unit tests, integration tests and end to end tests.

Diving right into unit tests, these tests are going to be looking at individual standalone components. We're going to be validating a components API and its behavior. This might look like testing our aria attributes and making sure that they are present and that their values are correct. This can also look like testing keyboard navigation within that component itself. So again, tools don't really matter here, or the specific tools don't really matter here. But just in case you want somewhere to start, I like to use React testing library and Jest together. They work really well together and they've got great accessibility support. So let's start off with a really simple component. We're just going to build out an accessible button. In my button, I'm going to make sure that I'm passing an accessible label prop and I'm going to conditionally render that accessible label. That label is actually going to show up as the HTML attribute aria-label. And this is going to provide a descriptive label for the element that it's applied to, so that something like a screen reader or some other sort of assistive technologies can announce it to our users or make it more accessible, essentially.

So, here's our test. Let's dive right in. We're going to start by checking that our aria-label attribute is rendered when we pass accessible label prop to it. We're going to create a button component and render that to the page. Finally, I'm going to assert that our button does have that aria-label attribute present and that it is set to the correct aria-label value that we pass to our prop. Now, this test is going to ensure that we always have the right aria-label for our component. And this is key because it could really protect us from any regressions if one day someone comes along and refactors the button component. They may accidentally delete that accessible-label prop unknowingly or just simply forget to render it, and if that happens, this test is going to yell out, hey, you forgot something really important here, maybe go back and take a look to validate what you wrote. Now, we also want to validate when that aria-label should not be rendered. And we only want to render this aria-label. If the accessible-label prop is not passed to it.

5. Testing ARIA Attributes and Keyboard Focus

Short description:

We render the accessible-button component and ensure that no aria-label is rendered when the accessible-label prop is not passed. This test protects against introducing accessibility bugs.

So, much the same as our last test, we're going to render out our accessible-button component, and then we're going to query for that button component. And now, here's the key. We want to make sure that because we did not pass an accessible-label prop to our accessible-button, we are not rendering an aria-label, not even the empty string in that aria attribute. And the reason we want to do this is because if we have an aria-label that is set to empty or maybe set to null, or something that is not the specific label that we want, this could have some unexpected side effects when it comes to assistive technologies, like something like a screen reader comes into play. So, again, this is not too difficult of a test. It's fairly straightforward, but in the long run, it really does help protect us against introducing any sort of accessibility bugs that may degrade our user experience.

6. Testing Keyboard Focus and ARIA Attributes

Short description:

Testing keyboard focus is crucial to ensure keyboard navigation is supported. By using the focus method on interactive elements, such as buttons, we can assert that they have the expected focus. This test helps catch bugs that may break keyboard navigation in the future. It's important to validate ARIA attributes and ensure their presence and correctness in the code.

So let's talk about another test, this time, figuring out our keyboard focus. So, making sure that we're testing that our components can gain focus is a really good way to test for keyboard navigation. Now, all of our interactive elements need to support keyboard-only users. And only elements that can be focused are interactive with a keyboard.

Here, we're going to take that same accessible button and then call the focus method on it. And then, we're going to assert that after we've focused on this button, that that button should actually have focus. Now, this test really protects us in the future from introducing bugs that break keyboard navigation.

For our accessible button that we've written here, we have used the HTML button element as the main element. And HTML buttons by default are keyboard navigable because they are able to gain focus. But let's say somewhere down the line, probably you honestly, six months later after you wrote this, come in and you change from our button HTML element to a div. Now, here's the issue is that divs are not focusable elements by default. They are not interactive out of the box and therefore they don't need to gain focus. Because of that, they're not going to support keyboard navigation. So that is a problem. But because we have our test, now this is going to fail our test. And it's going to let us know that we have likely introduced an unintentional bug in our code that breaks keyboard navigation for our users. And these are the kinds of things that we want to make sure we're testing for. We want to find those test cases that are going to distill down exactly what the outcomes look like through an accessible lens for our components. If you have a component that is interactive, this lets me know that I have to check for keyboard focus in order to make sure that keyboard navigation is supported. When my components rely on ARIA attributes, for example, I want to make sure that I'm validating those ARIA attributes. Making sure that they are present in the code and that they have the correct value when they are present.

7. Integration and End-to-End Testing

Short description:

Integration tests validate how components interact, focusing on outcomes. We test for aria attributes and keyboard navigation across multiple components. An example is the Slack signup form, where validation triggers an error message and visual indicator. We ensure assistive technologies receive proper signaling. End-to-end tests simulate user experiences within a complete flow.

So, enough with unit tests. Let's talk about integration tests. And, integration tests are going to help us validate how individual components interact with each other. And a lot of what we just covered talking about unit tests can be applied to integration tests. We are less concerned about component APIs. We are more concerned about the outcomes of how these components come together and work with each other.

So, while we can still test for aria attributes and keyboard navigation, this time we want to test them across multiple components coming together. Here, I have an example using the use React meetup website. We have a Slack signup form on the site where you can submit your email and join our Slack group. So, here, when I focus into the email input, and then blur out of the email input, there is a validation run. And when that validation is run, and there is no valid email address, you see that there is a red outline added to this input to signal to me that I need to add some sort of valid email. I also need to make sure that my screen reader users are notified of this error somehow, and that's where we're going to test right now. We're going to test that we are properly signaling to any assistive technologies of this specific flow.

So, let's take a look at this component. Our Slack signup container is composed of multiple components, and the container is going to pass a few props to all of the components. Here, we have an accessible input as we saw earlier, and this is going to take an onBlur function, and we also have an accessible alert component. And this component is going to accept some sort of message, likely an error message, that is going to run with validation. So, looking into our accessibleAlert component, we can see that it is visually hidden so that it doesn't show up on the page, because this is a component that is only here for assistive technologies. I have here the role attribute set to alert, and this is an aria-attribute that's going to announce any changes to this component, so when we do add an error message, something like a screen reader is going to be able to announce that message to our user, and I've set it to empty to start, because this is only going to alert our user of any changes to this paragraph node.

So, let's take a look at what a really simple test might be for a Slack signup container component. We're going to test that myAlert is updated when the input is blurred and no valid email address is added to it. I'm going to render out my signup container component and get references to myInput component and myAlert component. I'm going to focus into my input and assert that theAlert contains no text in it, because again the alert should be empty when it's rendered to the page. Then I'm going to blur out of that input component and now I'm going to assert that myerrorMessage should have the text content that matches myerrorMessage value that I've passed to it. That was maybe a lot of moving parts, but the guiding principles are the same in this case. We are checking that the behaviors of these components as they come together are accessible throughout the different stages. We can check that our components will contain the correct aria attributes, the appropriate keyboard navigation, even though there are a bunch of components coming together for one functionality.

Now we'll talk about end-to-end tests. These are tests that are probably going to be the closest to how our user is going to experience our websites or our apps. We're essentially going to evaluate the same things as with our user and integration tests, but now we're going to do it within the context of a fully fleshed out user flow.

8. Testing with Cypress.io and Final Thoughts

Short description:

Cypress.io is an open source end-to-end testing framework with excellent accessibility support. The Cypress Acts plugin checks for accessibility errors and integrates into your testing suite. Using Cypress, we can test the user flow, navigation, and accessibility support. Our tooling helps prevent accessibility bugs and generate audits to improve accessibility support. Make incremental changes to address accessibility errors.

Any sort of full pages or even our entire applications. I like to use Cypress.io. This is an open source end-to-end testing framework. It's really great for browser driven testing and it has excellent accessibility support.

Another bonus is Cypress has this Cypress Acts plugin that I really like. It's pretty similar to Lighthouse and React Acts in that it checks for accessibility errors except it's built right into your testing suite. It kind of keeps all of your validation in one place and it allows for really an easy integration into your CI, CD pipeline.

Using Cypress, let's write a very simple test for that same Slack sign-up form that we just talked about. We want to know that our Slack sign-up component works using only a keyboard. We're going to query for our accessible input. We're going to type in a valid email address, hit Tab to get to the Submit button, and then hit the Enter key in order to submit our email address. Finally, we're going to check that our accessible alert is updated with that success message.

Now, that was really quick, simple, super small, but this tests the entire user flow of our Slack sign-up form when we are successfully submitting an email address to this form. We're able to do this simulating using just a keyboard. That's what we want to be checking for in our end-to-end test, specifically. We want to check how is the user interacting with my app or my website? How can I translate that into a test and validate that that works, and how am I doing that through an accessibility lens?

We can also test that we are alerting of errors in the same way that we did in our integration test, making sure that errors are properly announced to our users. Or we can take it a step further and say, what if I wanted to test my entire navigation flow? What happens when a user is using a single page application? And what is the implications for navigation and accessibility support? For end-to-end test, we're thinking about our users, thinking about the flow of our websites and then our apps, and figuring out how do we want to validate all of these concepts as they're coming together.

And that's it for testing. That was a lot to cover using just the three types of tests that we usually focus on. Our unit tests are going to be for our component APIs and our behaviors. Integration tests are going to be for components that interact with each other or depend on other components, and end-to-end tests are for validating entire user flows. So putting all that together, our tooling helps us prevent accessibility bugs from being introduced while we're writing code, committing to code bases, and shipping to production. They're going to help generate audits and uncover where we can improve our accessibility support. And then in our testing, we covered unit integration and end-to-end tests, when it's appropriate to use each kind, and what to test for when we're working in each sort of category.

Now, that was admittedly a lot to cover in a really short amount of time. And there's still plenty that we haven't uncovered, that are really going to be critical for creating an accessibility development flow that will benefit your projects and your teams. So, if I can leave you with really just one piece of advice that I want you to take away, it's going to be that, admittedly, it can be really overwhelming if this is the first time that you've thought about the accessibility of your projects. And you're taking stock of the work that needs to happen in order to bring it up to standards and create really reliable processes around them. So, it's not expected that you have a fully accessible site or 100% test coverage on day one. I'm urging you to make incremental changes where you can and consistently chisel away at the accessibility errors.

9. Implementing Small Changes for Web Accessibility

Short description:

Implementing small changes leads to a deep understanding of web accessibility and bug resilience. Automation and testing processes make it easier to build a better web for everyone. Thank you, React Advanced, for having me. Feel free to reach out for questions or connect on Twitter.

Eventually, implementing those small changes are going to add up to possessing a really deep understanding of what it's going to take to make your website accessible. And how to make it resilient against the bugs that are crawling around. And once you have that understanding, and you have your automation and testing processes in place, it'll be easier to make your websites work for everyone. And that means it'll be easier to build a better web for everyone.

So with a little bit of work on the front and slowly chiseling away at all of these different bugs, eventually you'll be able to say that you're doing a lot of good without doing anything at all. Sort of.

Thank you so much, React Advanced. I really appreciate you having me here today. My name is Yorayma Estevez. Please feel free to hit up these slides or catch me on Twitter. I'll probably be sticking around for a few after this talk. So if you have any questions, please feel free to find me and ask away.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.
React Concurrency, Explained
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
Top Content
Watch video: React Concurrency, Explained
React 18's concurrent rendering, specifically the useTransition hook, optimizes app performance by allowing non-urgent updates to be processed without freezing the UI. However, there are drawbacks such as longer processing time for non-urgent updates and increased CPU usage. The useTransition hook works similarly to throttling or bouncing, making it useful for addressing performance issues caused by multiple small components. Libraries like React Query may require the use of alternative APIs to handle urgent and non-urgent updates effectively.

Workshops on related topic

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

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

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

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

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