Building Accessible React Components

Rate this content

With the growing community and great tutorials, it's fairly easy nowadays to start building web applications with React. However, the vital aspect of accessibility is often missing which leads to web applications creating exclusions. Nothing in React prevents us from building accessible web experiences, but we need to learn to harness its power in the right way while dealing with some unique challenges caused creating web pages with JavaScript. This talk will focus on how to solve these issues in the context of React. It'll also emphasis why it is important to build accessible web apps. In the end, I will also share some cool stuff and tools in order to make your web app more accessible.

34 min
14 May, 2021

Video Summary and Transcription

Today's Talk focused on accessibility in web apps, covering topics such as WCAG guidelines, handling required fields and field formats, error handling and disabled buttons, and the importance of DOM and visual order. The Talk also discussed the accessibility of hidden elements and links, the impact of animations on accessibility, and the use of development tools for accessibility testing. The Q&A session addressed questions about asterisks in required fields, date inputs, and automated testing tools. Overall, the Talk emphasized the importance of building web apps that are accessible to all users.

Available in Español

1. Introduction to Accessibility in Web Apps

Short description:

Today I'll be talking about building web apps for everyone and how to take care of accessibility. I'm Manjula Dube, a Google Developer expert in web. Vanguard is a client-owned asset management company focused on technology and accessibility. We believe in equal access for all users. In this presentation, I'll cover what is accessibility, common practices in building web apps with React, and how to test accessibility. Accessibility is an innovation that includes everyone and should matter to you because it affects people with different backgrounds and abilities.

So, hi, hello, everyone. And today I'll be talking about building web apps for everyone. How do you take care of accessibility in the same field?

So, let's quickly introduce myself. I'm Manjula Dube. I basically work at Vanguard. And Vanguard is only a largest asset management company that is wholly owned by investors and has no owners or shareholders. So, this client-owned structure helps us to focus on the best outcomes for our clients. And I'm also a Google Developer expert in web. I'm also an organizer at React India and JSConf India. And that's how you will find me on Twitter and GitHub.

A few things about Vanguard. We are growing in Europe and Australia, and also in Asia. One thing I would like to talk about is, although we are a financial-focused company from outside, but internally we focus a lot on technology and accessibility in general. Very good example of this is, we have around 7,000 people working in the technology team. What we believe is all the users have equal access to information and functionality regardless of their ability. One thing we always believe at Vanguard is all the users have equal access to information and functionality regardless of their ability. And if you want to really check more about what we do at Vanguard, you could quickly go on this link.

So before I start, we, I would like to, you know, always start with the sentence saying that because what we believe at Vanguard is we work to ensure that all the investors can access our products and services to help them reach their financial goals. And today what I'll be covering in this presentation is all about what is accessibility, what are the common practices you can take care of, you know, while building your web apps with React. And we'll be covering all sort of common practices, how we'll be handling forms, error handlings, images and icons, animations, and you know, how could you basically test accessibility. So to start with, I always start with saying that it's not a barrier to innovation. In fact, it is an innovation to web because you're building and including everyone to use your product. And when I say accessibility with React, it's not something to be, you know, afraid of or, you know, do that. It's, you know, it's how semantic you write your HTML. And why should accessibility matter to you? I mean, you know, we are in this world where we it's not just us. It's our friends. It's our grandparents. It's also the organizations that are monitoring our websites. And it is people with different and varied backgrounds. So, to start with, I would say, you know, there are people with disabilities around.

2. Understanding Accessibility and WCAG Guidelines

Short description:

There are different types of disabilities, and it's important to consider all of them. WCAG is a set of guidelines published by W3C to ensure website accessibility. Following the AA standards is crucial for accessibility compliance. Many top websites still have WCAG2 failures, such as low contrast text and missing alternative text for images. Accessibility is not just about blind people; it's about building for everyone. The four core principles of accessibility are perceivable, operable, understandable, and robust. When designing input components, it's important to include labels.

There are visual disabilities, cognitive. And I would say we need to serve all of them. And to give you a stat, I would say one in every ten users will always have some kind of disability. And sometimes disability can be situational. I mean, you know, so I often say this that accessibility depends on situations as well.

To quickly start with, I would say what is WCAG. We often come around with these terms, you know, when seeing accessibility in general. So, WCAG is a set of guidelines or techniques published by a working group at the accessibility initiative of worldwide web consortium, which is also known as W3C. And you see this AA and triple A. These are the three compliance levels for WCAG 2.1. And each level includes guidelines that must be met to consider if your website is accessible or not. So these levels are nothing but these are like three principles, which means must, should and could. So if your website wants to be accessibly compliant, you should at least follow level A. Or else, if you are not following it, you might have to deal with several As in your life. So better start following the AA standards.

To give you a short report, what I also found out that web AIM 2020 did a small random research on all of the top websites and what they found out is 98.1% of the top websites homepages have WCAG2 failure, which means you know, what are these common problems? So the common problems that are is, you know, low contrast text, missing alternative text for images or maybe they have like an empty links, they have missing form input labels. So although these websites like are top notch, but still they have WCAG2 failures.

And when I say, you know, I had a very wrong view of disability, I always thought that, you know, it's all about blind people, but it's way beyond that. I mean, we all have different perspective, but you know, we should start thinking and building for everyone. To quickly talk about principles of accessibility, there are four core principles, which means your website should be perceivable by everyone, which means captions and other alternatives should be available. It should be operable. I mean, functionality is available from keyboard. Any random stuff that you are trying to use is used by and is accessible by everyone. It is understandable, which means text is readable, content appears and operates in a predictable manner. And it is robust, which means, you know, content is compatible with current and future user tools. So, building for everyone, irrespective of what framework you're using, it's React, Angular doesn't really matter. How you would imagine your input component to be? I mean, let's say you have an input component, you know, how would you design it? The way I would design it is, you know, I would have my ID, type, name, all the things past as a prop. The one thing to notice here is you've passed required is equal to true. Now, when I see this input component, it looks something like this. So, all the input components are basically tied up using label and input and trust me, it's a good idea to always have a label with the input.

3. Handling Required Fields and Field Formats

Short description:

When passing the required prop to an input component, it automatically indicates to screen readers that the field is required. Additionally, including the area required attribute as a fallback is recommended. For multiple required fields, provide prior information to screen reader users by indicating that fields marked with an asterisk are required. For fields with specific formats, use the area labeled by attribute to give screen readers instructions on the format. Alternatively, the area described by attribute can be used to provide more information about the label.

And if you see here, since I passed required equal to true as a prop, you know, it already knows that this field is a required field. And when you pass required equal to true, it already takes care that it is also, you know, going to hint the screen readers, if they are navigating through your input component. And this is how you would basically do it. So if you're passing input, if you're passing required as a prop, you will make sure that, you know, your input props is required true.

Now, one thing, if you saw here, is, you know, I also mentioned that area required should be true. So you should be doing this, you know, as a fallback, because there could be, there might be sometimes that you know, you don't have an HTML5 support. So often good to also include area required as true.

So let's say you have multiple required fields. And you know, how would you handle that? The way you would do that is, you know, providing some prior information to the screen reader users already. Saying that, you know, all the fields marked with asterisk are required. So you know, they already have the context while they're navigating through your web app. Provide more instructions more often. So there could be a there could be a field that is required and that, that has specific format. For example, a very good example is date. So let's say we have this input component we passed required to it. And this has, you know, all the props that needs to be passed to it. Now what happens here is, you know, you, you're sort of giving it a date, but you don't know where it specifies that what should be the format of your date. So here, what I do is, you know, I basically pass area labeled by to it. So saying that, you know, instruct. And this instruct is nothing but a span ID where you say, you know, your date must be of DDMMYY format. Now, this thing will give the screen readers enough information about this particular field already. So, you know, you're providing more information because your screen reader users might not know of what and how the format should be. So, when we use area labeled by, it is mostly intended to identify the element that labels the current element.

Which means, now, let's see what we did here. So, we were trying to provide more information about the label. So I always prefer doing it in a way where I use area described by instead of area labeled by. I'll quickly tell you the difference between them as well. So, here, instead of using area labeled by, I would go and use area described by, and I would pass instruct to it, nothing, a span element, and I give it an ID. Why did I use area described by? Because I'm providing more information about the label. And using area labeled by is generally used when you want to overwrite the label and not provide more information about it.

4. Handling Errors and Disabled Buttons

Short description:

I prefer using area described by for error handling. Always tie the input component and error component together. Pass an area described by to give a reference when there's an error. The error component should have a div with a role alert. Use area invalid in conjunction with associating an array. Disabled buttons should not be used as they're often removed from the accessibility tree.

So, I prefer using area described by here. How would you handle errors? Let's quickly see because all of us have this error in the forms. So, it turns out that area described by is perfect when you want to basically deal with error handling. Let's quickly see how you would deal with. So, this is like a very small example where you say invalid email address.

So, let's have an input component. Make sure that your input component and error component is always tied together because that's how it should be, you know. When the screen reader is navigating through your website, they should know where the error is, what is the context. Which field has the error. And since these users are the screen reader users, they need to have that context of where the error is. So, you always make sure that you pass an area described by, and the error is nothing but a component, which I'll show you further in the next slide, is basically a component and has an ID email errors. This means your input and errors are always tied together. So, whenever there will be an error, it would always give a reference that this field has an error.

How your error component will look like is you'll have a div with a role alert, which is very important because, since the screen readers might come across this element, they need to have that information. Okay, there's something more important that I need to fix and the role attribute that you pass to the div will give that information. So very important stuff. So all I say is a field should always be mapped to the container error by area described by, and that's like the first important thing whenever you're dealing with errors. And you also saw in the code I passed an area invalid to it. So you see here area invalid and errors.length is greater than zero. Why I did that is because area invalid should always be used in conjunctions with associating and array, which means, you know, it will always check for. I mean, if you've passed required field, definitely it will check for required field. If there is an error, it will check, okay, if the error length is greater than zero, now let me pop up the error. So that's how area invalid works. And it's basically a hint to the screen reader that the field is an error.

How would you handle disabled buttons? So talking about disabled buttons, I mean, you know, all of us have gone through this, that when you disable the submit button, then you want the user to wait until whatever happens. So you'll only make it enable then. But this is not a good idea. I mean, to not disable the button. First thing, they're often removed from the accessibility tree. So it's not really a good idea.

5. Dealing with Disabled Buttons

Short description:

If you have a component like a button and pass a disabled attribute, it gets removed from the accessibility tree, making it inaccessible to screen readers. To work around this, disable the button for screen readers using area disabled and apply visual styles to prevent touch and click.

What I would suggest is, I mean, if you have a component, let's say, you know, action component, which is like a button to me, and I pass a disabled attribute, how you should, you know, basically deal with it. So, you would do something like this, right. And as soon as you pass a disabled attribute to it, you know, it gets removed from the accessibility tree, which means if screen readers is going through that disabled button, they will no longer have an idea of whether this button is already there or not there. So, to work around this problem, the submit button should never be disabled, which means it should be disabled, but in a way, you know, only visible for the visual users. So, how I would do it is disable the button for the screen readers using area disabled and apply some visual styles for preventing touch and click.

6. Disabling and Enabling Buttons

Short description:

To disable a button for screen readers, use the area disabled attribute and apply CSS properties like cursor, not allowed, and opacity. For keyboard users, prevent the click event. To enable the button, set the area disabled to false and remove the disabled classes.

So, let's quickly see how you would do this. Which means I have a button. I've passed an area disabled. Which means now my screen readers will know, okay, this button is disabled. But to make it look visually disabled, I'll pass some CSS to it. And, you know, the CSS that you would use is cursor, not allowed, opacity, so you cannot have a pointer events. Let's see what you would do for the keyboard users. You will prevent the click, right? You want the click to be prevented. So, are we done now? No. So, you would want to enable the button at some point. Make you set the area disabled to false, remove the disabled classes to visually make it look enabled, and this is how you would do it.

7. Handling Disabled Attribute and Focus Indicators

Short description:

There are some rare cases where you could use disabled attribute. Next, focus indicators should not be removed unless you have an alternative. Instead of setting the outline to none, make it transparent. Programmatically test your focus by taking charge of it. Test your favorite websites by pressing tab. Handling dialogs is difficult, but there are accessible models in the React community. Check out the area React model and React so each UI dialogue model. There are some issues with screen readers, so check the attached GitHub issue.

There are some rare cases where you could use disabled attribute, I mean, definitely. There could be some scenarios where you cannot skip. So, these scenarios are often, you know, maybe you have a carousel and you want to reach to the first or the last element, it makes sense to use that. There might be some off-screen controls that should not be focusable, makes sense there as well.

Next I would go to, you know, focus indicators. I mean, often by default if you have some links or buttons and if you press tab, you often see this, you know, focus ring around your element, and this is by default provided by the browsers. Do not remove them unless you have an alternative. And even if you have an alternative, for example, you know, what you would do, you know, your designer comes to you and says okay, you know, remove the default outline and, you know, make it more custom so that it is consistent across all the browsers. What you would do is, instead of setting the outline to none, I would say make it transparent so that, you know, in high contrast mode, sometimes box shadow behaves a little bit weird. So I would say don't remove it. I mean, make the outline as transparent.

How would you programmatically test your focus? I would say, you know, whenever you are dealing with link component, you need to be aware of where the focus is. So, you know, take charge of your focus. So simply if I land from one page to another, make sure that on that page you are focusing some main element that should be focused. Take charge of your focus. If you really want to test, you know, test your favorite websites by pressing tab, which means you'll start moving forward on all the interactive elements present on your web app. And if you want to go backwards, shift plus tab.

I often say handling dialogs is very difficult because, you know, you need to make sure that they're accessible as well. Which means once you open a dialogue, you know, the focus should be somewhere on the main element. And area React model is what I prefer is one of the accessible models already in the React community. Go check it out. React so each UI dialogue model is also something that I have tested. I mean, used. But there are some issues with the screen readers. They behave a little bit weird. So, there's also an issue attached to this. So, go and check out. I mean, there's a GitHub issue attached to this link. There's also React LI dialogue. So, worth checking that as well.

8. Accessibility and DOM Order

Short description:

All these models are accessible. Consider the DOM and visual order to keep them in sync. Balance performance and accessibility with content visibility auto. Use it cautiously and avoid hiding content. Instead, use CSS with clip path to hide content while remaining accessible.

And all these models are accessible. So, you know, you can definitely use them.

Often I also consider DOM and the visual order should always match because, you know, you often have a power of using flexbox. But, you know, you need to be careful that it does not desynchronize the DOM. And your visual and the DOM order are both in sync.

You know, we all of us love performance. I mean, yes. But, you know, with performance, you should also take care that you're not ruining the accessibility. So, all of us this is a new thing that has come up, content visibility auto. And what it does, it enables the user agent to skip the elements rendering until it is needed, which means your page load will be much faster and allow for the faster user interaction with the on screen content. But one thing to note is, you know, you should use it at a right place. If you use it to an element that shouldn't be inside that, for example, headings and other content, it'll be suppressed by the content visibility. So, use it cautiously.

Also a nice article by Marcy Sutton which I always tell people to read it. Hiding content. Again, don't use it. Because, you know, it is it again gets removed from the accessibility tree. So, not a good idea. I mean, yes.

Instead what you would do is, you know, there are some of the valid cases where you would want to hide and show the wicket. I mean, all of us want to hide and show something on the web app. Now, how would you do something that is accessible to the screen readers and still hidden from the users? I mean, I told you not to use display none or, you know, visibility. How would you do it? I would like to create some sort of CSS using clip path. And one thing to note here is clip path is actually deprecated. So, they've got something new called a clip. But I often also keep the clip path because there are not all the browsers that support clip yet. So, always good to have a fallback. So, using the CSS, it will make the content of screen but still be accessible to the users. So, good idea. Whenever you want to use, you know, whenever you want to hide something that is visually hidden, always use this.

9. Handling Hidden Elements and Links

Short description:

You could create a helper or a component to visually hide elements. Use area hidden true to hide content from screen readers while providing meaning to icons. The icon component can display the SVG icon with area hidden if no label is provided, or visually hide the label for screen reader users. Apply alt text to image components and consider adding pauses with punctuation for better understanding. Provide a spoken and visual warning when opening links in new tabs.

You could create a helper. I mean, in the CSS, if you're using style components, whatever. You could just create a helper and always use that CSS in that element. You could also create a component. I mean, wrap the component that you want to visually hide.

And quickly, let me give you some context of what would happen when you to hide something from the screen readers as well. So, you know, you would use area hidden true. Valid cases would be visually content of your icons meaning, which means here you want to give some meaning to your icons, and still make sure that you want to hide something from the screen readers. So, this is a nice table where I, you know, where I say, you know, often use certain attributes and classes, but make sure how visible and accessible it is. So, it's a quick table that summarizes the stuff.

Let's talk about icon component. I mean, all of us have icons in our project, right? How would you deal with that? So, having an icon component, and here if you see if passed, and icon, and my arrow top right is nothing, but it is some sort of icon, which is like an SVG, and I've also passed a label as a prop. Now, how I would handle this is I would have an icon component, you know, I would check, okay, you know, if there's no label, just return the return the SVG. I mean, return that particular icon with area hidden, which means because we don't require that icon to be known to the screen reader users. So, you know, that this is why we want to use here. And, you know, if there is a label already passed to the icon component, you could just display it and make sure that it is visually hidden, because, you know, you want to you want to give this information only to the screen reader users. And there's also a good example of link icon as well, which you could check later. If you want to know more about working with SVG icons, there's a good article by Florence. So, definitely worth checking.

How would you deal with image component? Same, I mean, you should make sure that, you know, you're passing alt source. And if you want to apply some sort of CSS, do that. Now, here you see what I've done is, you know, if you're passing the alt text, make sure you apply to it. And make sure, you know, sometimes you might just trim, you would like to apply trim to it because it makes sense. And what you also see is I have added a period to it, which means, you know, the screen reader would know that he or she, they need to take a pause here for that particular sentence. And it really helps the screen reader users to understand.

How you and, you know, all of us deal with opening a link in a tab and how you would deal with this. So, I prefer when the screen reader is sort of navigating on your website, whenever they open a link on a new, you know, on your website, there should be a warning that is spoken so that they know that this particular link is opening on the new tab. There should also be a visual warning in the text that the link is opening in the new tab. So any of the two things, quickly, if you take the component, I've done the same thing. You've passed something as a visual hidden class, which will only be visible, which will, you know, visually hidden.

10. Accessibility of Animations and Development Tools

Short description:

Animations should be used properly to ensure accessibility. Not all users enjoy animations, and some may experience dizziness or nausea. Avoid excessive animations on your website and provide a toggle for users to turn them off. You can disable animations in system preferences or use a media query for reduced motion. Be mindful of what you animate and consider inclusive motion. Check out the article by Josh and the talk by Well Had for more information.

Which means not available to the visual users, but still accessible to the screen readers. And it says opening in new tab. Which means now when you're trying to open something in a new tab, the screen readers will already have enough information about that.

Creating accessible animations, I often say, I mean I am a huge fan of, animations, but you should use it properly. I believe that tons of users do not like it, and you need to be mindful of the fact that not everybody experiences the way they do. So, some might feel dizziness, nausea. So, you should not have too much animations on your console. And if you have them, make a toggle, that if the user is trying to toggle that, it's off, and, you know, they have that thing on your website. So, there's already a way you could do it on your Windows or Mac machines. You could have in the system preferences and turn off the reduce motion, which means all your animations will be turned off. Or you could have like a media query, which is preferred reduced motion and use that. Which means all your animations would be off on that particular website. There's a good article by Josh. Definitely worth reading it on animations. One thing I also say is be careful with what you animate. So, I mean, I always provide an option for the user to toggle if they don't want animations. There's a good talk by well had. She talks about like, you know, inclusive motion. So, worth checking it out.

11. Development Tools and Accessibility Principles

Short description:

The development tools for accessibility include Jxli, aXe core, and Peli. Jxli statically checks for accessibility mistakes, while aXe core provides console warnings. Peli is an automated accessibility testing tool. Additionally, using Storybook add-ons and web browser extensions can help check for accessibility issues. Manjuta also wrote a book summarizing her learnings. The correct answer to the question is that reproducible is not an accessibility principle.

What are the development tools that you would use? And what are the lintings that you would use for accessibility? So, Jxli is one of the tools that statically checks for accessibility mistakes. So, worth checking it. There's aXe core which you can put up in your React application and it will give you all the console warnings already. If the issue is moderate, serious and you can start fixing it. There's automated accessibility testing which is Peli. Known as Peli. It runs accessibility test on your pages via the command line. So, basically NodeJS. And definitely worth checking that out. Make sure that, you know, if you're using sort of design systems, make sure you're using Storybook add-ons so that all of your accessibility stuff is right looked at the start. You can also use web browser extension, you know, to check all the accessibility issues.

I also wrote a book just to summarize whatever I learned from the past two years. And just go and check out. And yeah, thank you so much. And yeah, have a lovely day, everyone. That was an awesome, very informative talk. I learned so much already. A big thank you to Manjuta.

And let's go and check the answer to the question. So, Manjuta asked which one of these was not an accessibility principle. And you, 51% of you said that one that is not one of the main accessibility principles is that something is reproducible. Well, let's find out the answer. I have Manjuta with me. How are you doing today? Yeah, I'm doing good. How are you? I'm good. Thank you. So, can you tell us which one of these was the correct or incorrect answer? Yeah, that's correct. Reproducible is not the accessibility principle. Yes, I'm glad I got it right as well. I'm super happy.


Q&A on Accessibility and Testing

Short description:

We received several questions from the audience regarding accessibility. One question was about blind or disabled users being able to see the asterisk in required fields. Another question was about the preferred input method for date inputs, whether it's better to use text inputs with clear instructions or date pickers. We also discussed the use of automated testing tools like Peli for testing accessibility. Additionally, principles for checking accessibility in an Agile implementation were mentioned, including the use of tools like X-Core and user testing with screen readers.

But we've got a couple of questions. We actually have so many questions. People love this talk and wanted to learn so much more about it. So, I'm not going to be able to hit all of these talks. I just want all of these questions, but I just want to remind you that there will be a speaker room where you can ask your question if it was missed.

So, we'll go through. I'm going to do them in order just to be fair. We've got a question from Jordan who's asked, would blind or disabled users necessarily be able to see the asterisk? And would that be indicated fully when they are focused on the field? No, they would not be able to see, definitely. But when the screen reader will read it, it will read it aloud saying that asterisk. But basically, asterisk has some problems with all the screen readers, and that is why we have this required fields that which goes through and you know, basically hints them that this is required field. I mean, not all the screen readers read asterisk very loud, which might be misleading for the blind user. Yeah, that's something I've never thought about, but I've learned it today.

We've got another question from Benito about dates. So for date inputs, are text inputs with clear instructions better for accessibilities than date pickers where you can't type the date in? Can you repeat the question again? So they asked about date inputs. And they're asking about whether for a date input, would it be better to use a text input with clear instructions on formatting or a date picker? I would suggest creating your own sort of date picker that also handles text, because sometimes this is really necessary for the screen reader users. I mean you can have a third party library but make sure that you also have an alternative that supports screen reader that might be visible only for the screen readers, although it is not visually, you can see it, but yes, I mean having a text input is really a great idea.

Cool. Now we had a talk earlier about testing and let's bring this to the field of accessibility. We've got Hama who asked, which library would you suggest to use for automatically testing accessibility? I think I discussed in my talk as well Peli, which is a like sort of automated testing tool and it basically runs on your terminal. So if you sort of get it on board in your project, you can basically run, you can have it in your build process and you can have it as an automated testing process. So while your build is running, you can also automatically test that you know if there's anything failing or if there's anything, you know, not okay. So I would suggest Peli is one of the great tools.

Nice. Hama also has another question, what kind of principles do you have in your company for checking for accessibility as part of Agile implementation? Is there a specific part of that process where you talk about accessibility? I think we do use tools and it's always good to use tools. But you know, not all the issues could be solved by using tools. We use X-Core, which is made by Deque. It's one of the good tools to use, but we also make sure that we do a lot of user testing using screen readers, which is, I would suggest everyone, although, you know, try running your website through keyboard as if you're like a blind user and see if you can navigate to your website. Awesome. So, I think that is a very good idea to start with if you're already, you know, bringing accessibility in your company. Awesome. There's always easy steps for things to people to take. Thank you so much, Bhanjula. It's been great spending time with you. Thank you.

Check out more articles and videos

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

React Advanced Conference 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
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 Advanced Conference 2023React Advanced Conference 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
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. 
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.
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.
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 Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Top Content
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

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

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Top Content
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

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

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Top Content
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn