Accessibility as a First Class Citizen

Rate this content
Bookmark

All too often A11Y is only an afterthought and will be added to a project "when we have time" i.e. never. But there are a many reasons why you should develop with a11y in mind from the start including some that will convince The Higher-Ups. We'll explore tools we can use to help us develop more accessibly and talk about some of the quirks and limitations that React Native has.

24 min
17 Jun, 2021

AI Generated Video Summary

TypeScript and React are popular languages for software development. Accessibility is important for inclusivity and preventing lawsuits. Building accessibility from the start is crucial, considering design and engineering aspects. Tooling for React Native accessibility is limited. Setting the accessible prop and role in components is essential for screen reader users. The React Native documentation is helpful, but some accessibility needs may require additional attention.

1. Introduction to Accessibility and React Native

Short description:

TypeScript and React are the most popular languages. TypeScript is great for learning JavaScript. React is about making connections. Welcome to my talk on accessibility as a first-class citizen. I'm Sophie Au, a front-end full stack developer with a focus on React Native. I've delved into accessibility due to my role as a diversity advocate. Check out my website and follow me on Twitter. This is part 1 of 2, with a focus on accessibility in general and React Native.

So, what's the most popular language? TypeScript. And, of course, React. TypeScript is the best language for learning JavaScript. And it's really not about type. It's about the type. It's about the word. The language is about how to write it. It's about how you can learn it, it's about the way to express it, and, yes, it's about the language coming up. It's about making a connection. And, of course, React is about that. Most people don't do a lot of research when it comes to languages or languages. But it's about making a connection. So, if you're working on a course, it's about making a connection. If you're working on a course, it's about making a loop. And that's it.

Hey, everyone. And welcome to my talk. Accessibility as a first-class citizen. My name is Sophie Au. The pronouns are she, they, or he. I'm not too fast. People generally go with she, though. I'm a front-end full stack developer. Coming from the back-end originally but for the last one and a half years, roughly, I've been doing front-end, React Native specifically. And in my time in the React Native front-end, I've also been somewhat of the token diversity person in my company which also essentially led me down the accessibility rabbit hole, which is I guess part of the diversity. If you want to know more about me, you can find me on the internet on SophieAu.com. My website among other things, I have a whole block series on accessibility and you can also follow me on Twitter at Sophie Au.

Before we jump in, just a quick note that this is somewhat of a part 1 of 2 together with Jean-Luc's talk on accessibility on the web, which is going to be airing, or she is going to be airing in about an hour, I think, one and a half hours. So I'm going to focus more on accessibility in general in the first half of my talk, so who is it for? Why do we do it? How do we do it? And then I'm going to focus on accessibility in React Native, specifically. So, let's jump right in.

2. Who's Accessibility For and Why Should We Care?

Short description:

Who's accessibility for? It's not just for blind people or those with disabilities. It's also for those with slow or no internet, old devices, and different sensibilities. Building accessibility is the right thing to do and can prevent expensive lawsuits. It also attracts users and employees who value inclusivity. Around 50% of the world population is disabled, including those with minor impairments.

Who's accessibility for? When I ask my engineering buddies, usually the number one answer that I get is for blind people, people with visual impairments, which technically isn't wrong, it's definitely for those people, but that's only a small sub-group of people who we need to build an accessibility for.

When I try to dig in deeper, asking who else could accessibility be for, usually what I get is people who are disabled, which, amongst other things, includes people who are deaf or have a hearing impairment, people who have a motor impairment, people with neurological or mental disorders, or people with learning disabilities. And again, this is definitely people that we need to build an accessibility for, but it's not everyone, because what accessibility also contains is building for people who have slow internet, or no internet, or spotty internet connection, people who have old and slow devices with different screen sizes, some are tiny, some are huge.

Like, for example, me personally, I have a Samsung Galaxy S5, which is probably older than most people who are going to watch this talk, and if I turn on Bluetooth, my battery is just immediately going to drain, which means that, for example, I can't use the German COVID app, because my phone just dies immediately. But also, things you need to be aware of are people's personal sensibilities. Some things that you think are normal and fine are offensive to people, are hurtful. And also one thing, especially in mobile development, is you need to be aware that some people are left-handed and some people have small hands, and you need to make sure that your app can be, like, that the corners of the app can be reached by everyone.

So now that we have the list of people who we build an accessibility for, why should we care? And really there's kind of two big things. Number one is it's the right thing to do. You don't want to on purpose exclude people. Of course, you know, if you're not aware of the issues that your app has in terms of accessibility, that's fine. You know, everyone starts somewhere. Do your best. Get there. But if you are aware of your issues, you should fix them to help other people out. And then the one point which usually goes down really well with the C-level types, your managers is, you know, not being accessible can get really expensive. And why is that? Because if your accessibility is bad, you run the risk of getting sued. In the U.S., there's the Americans with Disabilities Act, there's different types of legislation in, I guess, most countries around the world where if your app or your website is inaccessible, you can get sued, and those legal costs can run really high. It happened to Beyonce. It happened to Domino's Pizza, and you don't want to run, you don't want to join that club. And then it's not only the legal costs that are going to cost that, that are going to make it expensive. It's also fixing that issue if you don't want to get sued like two months later. So fixing the issue takes engineering time, it takes design time, you might have to overhaul the whole feature because it's just not possible to do this accessibly. And it's going to cost you time as well, which might give your competitor the advantage to shoot ahead and like take part of your, of your market. And then not only is it costly in that situation, it's also costly in the future where, you know, nowadays, people want to work for companies that do good, and users want to use apps of companies that do good, and to attract a valuable user, to attract good employees, you want to show them that you are a company that values people, which also includes making your app accessible, making your website accessible. And speaking of users, up to or according like, depending on the statistic, with the World Health Organization, it's around 50% of people. Yeah, 50% of people are of the world population are disabled. And that doesn't include, for example, your, your parent who, even though they can barely going to wear reading glasses because they're not that old and they can read just fine, or your grandparents who even though they can't hear a thing, just tell you no, just speak up louder. It's fine, I don't need a hearing aid. Those people aren't even counted in that statistic.

3. Building Accessibility and Design Considerations

Short description:

Building accessibility from the start is crucial. Consider accessibility implications for every feature and product. Estimate stories and features with accessibility in mind. Designers should focus on high contrast colors, zoom levels, tap areas, loading and error states, and simple app flows. Content should be at a middle school level for easy understanding.

So you know, if you actually cater to people who have accessibility needs to suddenly have a huge untapped user base that quite often you will be one of the few companies that actually cater to them and therefore get somewhat of a monopoly in your industry.

So going from there, you've successfully convinced your C-level, your managers that you need to put in accessibility, but how do we become more accessible? And the big thing is, you need to build it in from the start.

If you chuck in accessibility later on, it can get you to a certain point, but you're going to at some point hit a brick wall and it's going to take a lot more time, a lot to be accessible, if you only try to tack it on later on.

So you need to start with feature discovery or product discovery depending on what specifically you're working on. And that means for every feature, every product that you build, you need to consider all the accessibility implications.

Do you, for example, want to put in a chart that's interactive? How can you make this interactive for people who use a screen reader? Or you want to put in a cool video, a cool animation. How can you make this accessible for people who, yeah, again, use a screen reader? Or even for people who might be really sensitive to certain flashing animations. Can you put in alternatives for people to use the app still?

And then when you have all those implications listed, estimate your stories, estimate the whole feature with accessibility in mind. The last thing you want is that people, that you build your app, but you end up being late The deadline was last week. And you have to tell them, well, you know, we still haven't done the accessibility part.

Because that just signals that that signals that to them that, you know, accessibility takes time, accessibility is costly. And then the next time you do feature discovery, they're gonna go, you know, maybe we should go lighter on accessibility. And that's not something you want to happen.

So you've done the discovery, you've listed everything you need to do. Usually in my experience, next step is the feature getting into design. And then big caveat, I'm not a designer.

So if you're a designer, if you talk to your designer, really the best point for them to go is to Google, there's tons of great blog posts out there, there's books on accessibility and design that they can read.

But here's just a quick selection of things that designers need to look out for to make sure that your app, your website is accessible. And there are things like having high contrast colors, especially text and background, being able to accommodate zoom levels. So when you zoom in on the font, the design shouldn't break. The tap areas, the interactive areas should be big enough that you can easily click on them. You need to be building for loading and error states. When the data is loading or internet is down, for example, and your app flows should be simple and short so people don't get lost halfway through. Like I said, this is just a short selection. Honestly, Google it. I'm not an expert. So I'm probably not the person to ask there for a complete list.

In somewhat of the same vein as design, when it comes to content, you should keep your level to around middle school. That is generally speaking something, a level that is easy for people to understand at both native English speakers and non-native speakers that are on a reasonable fluency level.

Of course, this depends on your target user, right? If you target your app at English PhD students, your language level can probably be higher, but if it's somewhat aimed at the general public, it should be at around middle school level.

4. Building for Accessibility and Engineering

Short description:

Make sure your language isn't offensive or hurtful. Avoid gendered language, religious language, and sarcastic or edgy jokes. Condescending language can make users feel stupid and harm your app's reputation. Engineering is crucial for building accessibility, especially for screen readers. Engineers ensure the app runs on low computing power, slow internet, and doesn't drain the battery. Tooling allows us to check design and content accessibility and ensure the app is accessible before release.

Also something you should be aware of, which I already mentioned earlier, is make sure your language isn't offensive, so, or hurtful to people, which means avoid gendered language, avoid religious language, and especially avoid jokes, like very, very especially if they are sarcastic or if they are somewhat edgy. Because people will take offense, people will misunderstand them and suddenly you find yourself in a Twitter shitstorm and that is something your PR team does not want.

And somewhat similarly, you want to avoid condescending language even if it's accidental. So don't tell your user, do this quick thing in five user steps and they are stuck for five hours, because that just makes them feel stupid. And someone who feels stupid is not going to recommend your app to anyone. In the worst case, they're going to tell their friends and their family, hey, don't use this app, it's crap when really you might have a nice app, but just making a user feel bad, it's not going to help your marketing.

Now we're finally on the engineering step where also the main reason for why everyone seems to think that we're building for blind people comes in. Because engineering is the one part in the chain that is building specifically for screen reader. Designers don't have much influence on screen reader's content. The content team doesn't really have much influence except for them obviously supplying the content, but as engineers, it's our job to make sure that the app, the website, is usable on a screen reader. But that's not all we do. We also need to make sure that your app runs on low computing power, that it runs on slow and spotty internet, and also that it doesn't just completely drain the user's battery.

And then finally, one thing where we as engineers are very lucky is that there's a lot of tooling out there, especially for the web, which Jen is going to go into later on, that allows us to double-check that design is accessible, that the content is accessible, to allow us to put in a last gate to make sure that the app that's going to get released into production is actually accessible for the user. And with that, we're already done with the general part, so if you were only here for that, now's the time to grab a coffee, maybe watch the other talk on the SummerTrack, just maybe take a break, you know, but of course you're also very welcome to stay on for the

5. Tooling, Accessibility API, and Demo

Short description:

There's a lot of tooling out for web development, but unfortunately, there isn't a lot for React Native. The one big tool for Mac developers is the Accessibility Inspector, which works as a fake-ish screen reader and allows us to run audits. The main focus of the React Native Accessibility API is the accessibility props, which cover around 90 to 95% of accessibility use cases. Now let's jump into the demo, where you'll see a one-screen quest app where you need to find seven keys to restore magic.

First off, like I said, there's a lot of tooling out for web development. Unfortunately, for React Native there isn't a lot. The one tool I'm going to go into because I'm actually giving this talk on a Mac and the app, the demo that I'm going to go into later is also an iOS app.

So the one big tool that us Mac developers have is the Accessibility Inspector. It works as somewhat of a fake-ish screen reader, but it also allows us to run an audit, as you can see from my view of right side. It can run audit telling you, hey, for example, the hit area. So the tappable area is too small. And on the left side, you can also see that you can influence, for example, the zoom level on the font size.

So yeah, before we go into the demo, one quick note though on the React Native Accessibility API. The main thing that you need to focus on are the accessibility props. There's a few other things out there. But if you want to cover around like 90, 95% of your accessibility use cases, the accessibility props are what you want to go for. And that means those props are available for every core component, which means view, text, the various lists that you have, all the touchables and the new pressable as well. And there's 14 of those props. Six of those are for either iOS or Android only. So they're generally a bit positive to use. And then on the other eight, really the only ones you need are accessible, accessibility label, accessibility role and accessibility state. Those cover in my experience around 90 to 95% of your accessibility needs.

And with that, let's jump into the demo. So as you can hopefully see, I've prepared a short app. It's a one screen app. It's a quest app and your current quest is restoring magic. And to restore magic, you need to find seven keys. These are held by various people. And you have a button that allows you to set the next key as found. So if we just click through this real quick. When I click the button, as a sighted user you will be able to see that the first key has now been selected as found, which is indicated by a higher contrast on the fonts. And the key icon that is on the right of the list item is now golden. And then you can do this for every list item. And when you have found all seven keys, the button to set the next key as found is disabled.

6. Using the Accessible Prop for Screen Readers

Short description:

When using a screen reader, each text element is read as a single element, even if they belong together. To ensure that screen reader users know that these elements are related, the accessible prop needs to be set. By setting the accessible prop to true, all children are grouped into a selectable component, and the screen reader will read the concatenated text children as the label. Touchable and pressable core components are accessible by default, while everything else is not. Setting the accessible prop to true in the list item will make it accessible.

And when you have found all seven keys, the button to set the next key as found is disabled. All right. So first a quick caveat. The accessibility inspector, unfortunately, is sometimes a bit buggy. So if it crashes, please bear with me. Restarting it is really quick. So yeah, let's just quickly go through it with the screen reader to understand what a non-sighted user will actually see or hear in this case, actually. There you go. I warned you, it is a bit buggy. I'm very sorry about that. But usually that resolves itself eventually. Or not.

All right. So as you might have just heard and or seen, and as you can see on the left in the basic label field here, doesn't focus unfortunately, every single text element is read as a single element. So for a list row that includes the realm key and fairy queen for example, fairy queen being the owner of the realm key, it will read realm key and then fairy queen as if they have no relation. But of course they're in the same list row. So you want to make sure that a screen reader user knows that they belong together. And to do that, you need to set the accessible prop. The accessible prop, as I just said, groups all children into a selectable component, and the label, so what the screen reader is going to read, is set by concatenating all the text children. Now one note on that is that all touchable and pressable core components are accessible by default, which means it's the touchable opacity, the touchable highlight, and there's a third touchable that I just can't remember off the top of my head now, but they're all set to accessible by default. Everything else is set to accessible faults by default. So let us set that prop. For that, have a look in line 8 here after the style. So on this end, when I now select that commit, you will now see here that the accessible prop is set to true in the list item. And yeah, assuming that the simulator doesn't crash, or the accessibility inspector, let's see what happens. It crashes. I'm sorry. All right. Nothing happens, which is also great. Oh, there you go.

7. Setting Accessibility Label and Role

Short description:

The accessibility label describes what the component contains or is used for. It should not replace good design but rather convey information that cannot be conveyed via text. By setting the accessibility label, screen reader users can be made aware of whether a key has been retrieved or not. However, for interactive elements like buttons, it is necessary to set the accessibility role to indicate that it is pressable and interactive.

So you just saw and also heard that now this row for the key is read as illusion key father Po, which like I just said, is the concatenation of the title and the owner, but this doesn't actually tell the user anything about the state of the rose. So as a sighted user, you now know this means that the key hasn't been found, but the label doesn't actually tell you that. And now when I like set the key as found and I run the inspector again, hoping that it doesn't crash, which it does. Come on.

You just heard that even when it is selected, it doesn't actually do anything. So what you want to do is you want to set a label to let the user know that, Hey, this key has been found, all this fee has not been found. And for that, you need to set the appropriately named accessibility label. Like I just said, it describes what the component contains or what the component is used for. And it should not be used as a replacement of good design of good, like visible components. It should only be used to rearrange the component content and let a screen reader user know any information that cannot be conveyed via text. So yeah, let us set this prop. You will now see it after the accessible true prop in line 9 to I think 11. Actually, it is 11 to 13, I'm sorry.

So over here, you can now see we're setting title held by the owner. And then if the key has been found, it's set to retrieved. If not, it is set to not retrieved. So let's see if that works. And then the next element is red. All right, there you go. Now the screen reader user is made aware of, you know, has this key been retrieved or not. And that is actually pretty much it for those list items that are not interactive. But as you might have noticed while the screen reader went through the list, when it comes to the set next key as found button, there's no indication to a screen reader user that this button is actually pressable, that this is actually a button. So assuming that thing doesn't crash, I'm really sorry. For some reason since the newest upgrade, the accessibility inspector has been specifically buggy. But as you can see here, we are now in the reader on the button. But the label is set next key is found, which is essentially the same as any text item. So how do we let the user know, hey, this is actually a button, this is interactive? For that, you need to set the accessibility role. What the role does, it describes, like the name says, the role of the button, the role of the component, which is in many cases the button. Like, honestly for me, 90% of the time, it's really just me setting the role to button. But there's also others such as link and header.

8. Setting Accessibility Role and State

Short description:

To ensure that interactive elements are properly recognized by screen readers, the accessibility role needs to be set manually. Setting the accessibility role to 'button' for a touchable or pressable component will indicate to the user that it is interactive. However, if the button becomes disabled, the screen reader will still read it as interactive. To address this, the accessibility state can be set to 'disabled' to accurately convey the button's state to screen reader users.

I think in total, there's around 20. You can look them up in the docs. The thing with the role is you need to always set it manually. There's no default. Which means that if you have a touchable or a pressable, which in most cases are a button, you need to make sure that you still set the role. Otherwise, the user will not be aware that this is actually interactive.

So let us set the button. For that, we need to go into the refresh button component. And now when you look at line 11, we have now set the accessibility role to button. And already on the left in the accessibility inspector, you can see that the trait button has been set. And then, assuming that it doesn't crash, there you go. It now announces that the button is an actual button. Which is great. You now have covered around 90%. But there's still another 5% that we can get out of this. It just announced button. Meaning that we can interact. But like I showed in the beginning, once you've found all keys, the button is disabled. Because there's no more keys to be found. Unfortunately, the screen reader will still just read buttons. So a screen reader user will think this button continues to be interactive.

Sorry. There you go. To fix that, we need to set the accessibility state. The accessibility state, like it says, is the state the component is in. And it can be, for example, loading or disabled. It can also, I think, be selected or checked. And it's an object, so you can give it multiple states. So let us set the state on this element. You can now see in line 12 here, we just set the state to disabled, based on the prop, which is a boolean.

9. Final Thoughts and Q&A

Short description:

Now it's announced it's not enabled. What happens if the button is enabled? The React Native documentation is good for everything else. The Pareto principle applies to the last few accessibility needs. That's it from me. Thank you!

And let us see what happens now. There you go. Now it's announced it's not enabled. What happens if the button is enabled? So let me just sneakily reset the whole thing. There you go. Now the user is aware that this is a button, there's no mention of it not being enabled, so it has to be enabled.

And yes, that is actually pretty much it already. already allow you to cover around 90 or 95% of your accessibility needs for everything else. The documentation in React Native is actually pretty good on all the other things. There's cool things like you can do conditional stuff based on if a screen reader is turned on or not, but I'm not going to go into those, because at some point, the Pareto principle hits where you know, those last few percents you want to get out, they are a lot of work.

So yes, that is already it from myself. Thank you very much, and I think we're now ready to go into the Q&A.

Check out more articles and videos

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Advanced Conference 2021React Advanced Conference 2021
47 min
Design Systems: Walking the Line Between Flexibility and Consistency
Design systems aim to bring consistency to a brand's design and make the UI development productive. Component libraries with well-thought API can make this a breeze. But, sometimes an API choice can accidentally overstep and slow the team down! There's a balance there... somewhere. Let's explore some of the problems and possible creative solutions.
React Summit 2023React Summit 2023
23 min
React Concurrency, Explained
React 18! Concurrent features! You might’ve already tried the new APIs like useTransition, or you might’ve just heard of them. But do you know how React 18 achieves the performance wins it brings with itself? In this talk, let’s peek under the hood of React 18’s performance features: - How React 18 lowers the time your page stays frozen (aka TBT) - What exactly happens in the main thread when you run useTransition() - What’s the catch with the improvements (there’s no free cake!), and why Vue.js and Preact straight refused to ship anything similar
TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

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

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
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
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions