How to do Good Without Doing Anything

Rate this content
Bookmark

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.

Yuraima Estevez
Yuraima Estevez
32 min
25 Oct, 2021

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

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 Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
Top Content
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
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 new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
React provides a contract to developers- uphold certain rules, and React can efficiently and correctly update the UI. In this talk we'll explore these rules in depth, understanding the reasoning behind them and how they unlock new directions such as automatic memoization. 
Using useEffect Effectively
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Top Content
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.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
(Easier) Interactive Data Visualization in React
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
Top Content
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured WorkshopFree
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 🤐)
Concurrent Rendering Adventures in React 18
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
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.
React, TypeScript, and TDD
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
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.
Web3 Workshop - Building Your First Dapp
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
Nader Dabit
Nader Dabit
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
Designing Effective Tests With React Testing Library
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Top Content
Featured Workshop
Josh Justice
Josh Justice
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