The Worlds Most Expensive React Component and How to Stop Writing It

We need to stop building expensive React components — components that promise the world but are impossible to maintain. Let's fight the apropcylpse and set aside our prop drills with this proposal for a more productive way working in React.

Rate this content
Bookmark
Video Summary and Transcription
The talk explores the concept of expensive React components, highlighting a common issue with component API design. The speaker illustrates how a billion-dollar component, featured on the front page of ReactJS.org, has led to unnecessary costs due to its inefficiency. The discussion emphasizes the importance of simplifying React components, advocating for using basic HTML and JavaScript functions over complex props and components. The story of 'The Lady Who Put Salt in Her Coffee' is used as a metaphor to show how overcomplicating solutions can lead to more problems. The speaker encourages developers to ask if the work being done is necessary, suggesting that communication issues, rather than code, often drive complexity. He proposes that sometimes, simpler solutions like a function and markup can be more effective, urging the audience to reconsider the necessity of complex React components.

FAQ

Michael Chan is a front-end architect with over four years of experience in that role and a total of 12 years in design infrastructure. He is known online as Chantastic, hosts the React Podcast, and has contributed to bridging React versions 17 and 18 with the React Working Group.

Michael Chan's talk at React Advanced focuses on the concept of 'expensive' API design in React components, specifically addressing a common component that he believes has cost the industry billions of dollars due to inefficient design and implementation.

According to Michael Chan, the 'most expensive' React component is a commonly used API design pattern that is featured on the front page of the ReactJS.org documentation. He argues that this component, due to its poor design, has led to significant unnecessary costs across the industry.

Michael Chan suggests that developers should reconsider the necessity of using complex components and props for certain tasks, advocating for simpler solutions that utilize basic HTML and JavaScript functions, which might be more efficient and cost-effective.

Michael Chan relates his talk to the story 'The personified cat that put salt in its coffee', using it as a metaphor for overcomplicating solutions. The story illustrates how simple solutions are often overlooked in favor of more complex and costly alternatives.

Attendees can find more resources, links, notes, and the presentation related to Michael Chan's talk at chan.dev.expensive. After the presentation goes live, a YouTube link will also presumably be available there.

Michael Chan recently joined the team at Chromatic, a company focused on improving the user experience of the web through products like Storybook. His role involves working towards enhancing web UX.

Interested individuals can join the community built by Michael Chan by visiting Chan.Dev.Discord. The community engages in various learning activities, often centered around lunchtime discussions.

1. Introduction to Expensive React Components#

Short description:

Today we're going to talk about expensive React components and expensive API design. I'll show you how to stop making that component and share a favorite story. Who am I? I'm Michael Chan, a front-end architect with a passion for design. I host React Podcast and work with the React Working Group. Join my Discord community at Chan.Dev.Discord. Check out chan.dev.chromatic to work with me at Chromatic. Visit chan.dev.expensive for related links and notes. I previously gave a talk called Hot Garbage Clean Code is Dead.

Hey there, all my friends at React Advanced, thank you so much for attending this talk. Today we're going to talk about expensive React components, but probably not the type of expensive that you're accustomed to hearing about or thinking about. We're going to be talking about expensive API design, specifically a single component that I think has probably cost us billions of dollars as an industry and is therefore the most expensive component that I've ever seen. I want to show you how you can stop making that component on your teams and in your communities.

The next 19 minutes, this is what this talk is going to look like. We're going to talk a little bit about me, who I am, why I'm here. I'm going to share with you one of my favorite stories, and after that, we'll look at some code and try to make some takeaways from the relationship of the story to the code.

First things first, who am I? My name is Michael Chan. I go by any part of that, Michael, Chan, Chan. Michael Chan, whatever you like, whatever you're comfortable with. I go by Chantastic most places on the internet that you might care about as a developer. I've spent the last four years as a front-end architect and the last 12 years in some form of design infrastructure role. So I'm really passionate about design and component design. I have hosted the show React Podcast. So if you're hearing my voice, but it sounds slower because it's not on 2X, that's me. I also have spent the last year and a half working with the React Working Group to help bridge the gap between React 17 and React 18 coming up. I am building a community, a Discord community. You can find it at Chan.Dev.Discord, where we do a lot of stuff over lunch. A lot of lunch-based activities for us to learn from each other and learn new technologies. And finally, I recently joined the team at Chromatic, the company that makes Storybook. Our goal is to improve the UX of the web. I wanted to invite you, if you're interested in working with me and the team there, check out chan.dev.chromatic. And that'll get you to the right place.

Now, I want to share one last link with you before we move on. That's chan.dev.expensive. There, you'll find anything related to this talk, whether that be links or notes or this very presentation. And after this goes live, presumably a link to the YouTube video. Now, why am I here? Well, it's kind of an interesting question that starts a handful of years ago. I gave this talk a long time ago, three years or so ago, called Hot Garbage Clean Code is Dead. If you end up liking this talk, you'll probably love that one.

2. The Lady Who Put Salt in Her Coffee#

Short description:

It started as a technical presentation on things that didn't work well in complex applications. But it became a personal journey of overcoming imposter syndrome and the cost of coordination. I'll share a story called The Lady Who Put Salt in Her Coffee, where a cat accidentally puts salt in its coffee and seeks help from a chemist.

If you don't like this talk, you'll hate that one. It was a really interesting journey because it started more as a technical presentation of things that I thought really didn't work, patterns that I thought didn't work well in complex applications.

However, it slowly started to take shape as a personal journey as I learned kind of my own sense of belonging and overcoming imposter syndrome and just doing the work to overcome my demons. But I did feel like there was a little bit left unsaid, specifically around the cost of coordination, because coordination is costly.

And while I did the work several years ago to understand where I was in my career, that work is happening kind of at different paces for different people, and it can make it really hard to coordinate. Now that we've established that, I want to tell you a story that really kind of changed the way that I think about how we make decisions in code. And it's giving me kind of a fun example in my head to think about, and I just want to share that with you. So let's dive in.

Now the story is this book called The Lady Who Put Salt in Her Coffee. Now it's super old timey, and unfortunately, as I was reading it again, it's very distractingly gendered, which makes me uncomfortable sharing it. Um, with that, and the hope that I don't violate and incorporate right laws in giving this talk, I decided that I would give a an abridged and interpreted version of the story, using emoji cats and kittens. So I've titled this the personified cat that put salt in its coffee.

So the story goes like this. There's a cat, and it's morning time and this cat makes a cup of coffee. Now, it's just about to put some cream in this coffee when it realizes that instead of sugar, it has put salt in the coffee. And salt is definitely not sugar when it comes to dressing up your cup of coffee. Now, fortunately, it had all of its kittens around, and so they all gather around and try to figure out what can be done to salvage this cup of coffee that now has salt inside of it.

Now, there was one kid that had gone to college and was feeling very smart and said, you know, I went to college, I'm very smart kitten, and coffee is just chemistry. So, we should consult a chemist. And of course, the kid had gone to college, and they all assumed it was very smart. So, they agreed that they should first consult a chemist. So, they go out to the chemist that they know, they find the chemist, and there is one thing that you should know about this chemist. This chemist is not a very good chemist. They've devoted most of their life to the pursuit of turning objects into gold, a pursuit that they have failed at dramatically, and at this very moment, they're trying to figure out ways to find more gold to conduct experiments with. First, the chemist is like, I don't have time for this. I am very busy about my work. But the cats are very aristocratic cats, and they have plenty of gold. He's like, well, we'll give you the gold to figure out how we can salvage this cup of coffee. Of course, the chemist was in. So the chemist starts applying all of its science and chemistry and and thinking everything that it knows to this cup of coffee.

3. The Journey to Fix the Coffee#

Short description:

The cat and the kittens try various ideas to fix the coffee. They consult a chemist, but the coffee doesn't taste like salt or coffee. Then they consult an herbologist, who infuses the coffee with new herbs and spices, making it disgusting. Finally, they consult their wise neighbor, who suggests making a new cup of coffee. The kittens are delighted and the cat is happy.

It has no idea how things are going to turn out, but it has a couple ideas of things that it could try. Unfortunately, when the chemist gives the cup of coffee back to the personified cat, well, it doesn't taste like salt anymore, which is a good thing, but it doesn't taste like coffee anymore either.

Now, that's actually good enough for the chemist, so they present their bill and walk off with the gold. Never to be seen again. Well, the cat's still sad. It has a cup of coffee with salt in it and so the kittens reconvene to see what else can be done.

Well, it's about this time that the collegiate kitten has another brilliant idea. Let's consult an herbologist. So, they consult an herbologist. They go and they go into the woods and they find an herbologist whose house is just riddled with all of these beautiful spices and herbs and plants of all forms. Things that they'd never seen before.

Now, one thing that's interesting is that unlike the chemist, the herbologist didn't really care about money. But they did...they were a little prideful and felt misunderstood in their endeavor. And they had a great interest in sharing their passion and evangelizing the discipline. So, they agreed to do the work. They come and they apply everything that they know about herbology to this cup of coffee. Infusing it with new herbs and spices and things that nobody had ever heard of before.

Unfortunately, this resulted in a cup of coffee that was just nauseating to all of the cats and the kittens. So, it didn't taste like salt anymore, but it was also extremely disgusting. Of course, the arrogant herbologist blamed the coffee, saying that it was bewitched and moved on to share her good news with others who were less cursed.

Now, this left the kittens in a little bit of a lurk. They were at wit's end and the cat was getting cranky because it was fairly late in the day and it hadn't had its coffee yet. Now, at this point, they reconvened a third time to see what might be the next possible step. This time the collegiate kitten feeling much more quiet and demure, giving room for the other two kittens to make their suggestions. And what they suggest is to consult with the wise and experienced neighbor next door.

So they do. And the response of this wise and experienced neighbor is simply to ask, can't you make another cup of coffee? Now this was an extremely profound suggestion to all of these kittens who had been searching all day for a much more complicated way to salvage this cup of coffee. And they respond in delight. Why didn't we think of that? They cried. They made a new cup of coffee and the cat was happy.

4. The Billion Dollar Component#

Short description:

Now let me show you the billion dollar component, the most expensive I've ever seen. It exists on the front page of the ReactJS.org docs. I'll explain why it's expensive and show you the process. Our story starts with a request to improve greetings with customized punctuation. We add new props, commit the changes, and receive another request to further customize the message with cute greetings.

The end. Now I know that we're... I'm on this end of the screen, we're an ocean away probably, but I can feel your judgment about this story and possibly the way that it's ended. You know, because it's, you know, completely unrealistic right? Nobody is so daft as to not realize that you fix salted coffee by just making another cup.

Well let's jump into some code. Now I want to show you the billion dollar component. The component that I have come to believe is the most expensive component and definitely, disproportionately expensive that I've ever seen. So I'm going to show it to you now. Now you might have seen this because it exists exactly on the front page of the ReactJS.org docs. Now I want to show you this in practice. I want to tell you not just that it is the most expensive component, but show you kind of some of the reasons why I believe that it is. And kind of go through this process with you.

So I've put this inside of a code base as is, but using hooks because why does the front page of React.js still have classes on it? So our story starts with this request. Hey, we'd like to improve the friendly factor of our greetings with customized punctuation. Our team tried to just add punctuation but failed. If we look at this component we see that it is a div so that's unfortunate. It is going to fail any time that we try to put punctuation outside of that component. So we just need to add some new props with the default. We do that. We choose trailing punctuation as the prop name because we have been deeply hurt by things being too generic before. We know that there may be some other punctuation questions later. So this looks good. We commit it and everyone's happy. We had another alert from the UX team. Hey, UX team here again. Great work on the last feature. Teams have already been using trailing punctuation. Yada yada yada. We'd like to further customize the message with cute greetings like yo howdy what's good.

5. Customizing Messages and Improving Accessibility#

Short description:

We can further customize the message with cute greetings by using a new prop with a default value. To fix the punctuation of the greeting on the dashboard, simply add a comma. For the birthday Bonanza project, apply a class name to achieve the desired animation. We can also improve accessibility by changing the HTML markup to be more semantic using a component prop.

We'd like to further customize the message with cute greetings like yo howdy what's good. You know things of that nature. Can you help us? Well yeah actually. We can kind of repeat the same process that we did before using a new prop with a default. So that looks something like this. We'll just move what we had statically in there. Move that up as a default. Have a prop for it. We can change that and then here we go. Easy peasy.

We get another request. Our marketing team is creating videos and content reviewers concerned about the punctuation of the greeting on the dashboard. Instead of hey Joan it should have a comma. Is this something that we can easily fix? Yeah and actually because of the way that we made salutation and it's just kind of a coincidence but you can fix this on your own just put a comma in there. Great don't even have to do anything with this. Checked off so this one's interesting.

We're collaborating with UX on a birthday Bonanza project. Our goal is a one-time birthday balloons animation over the user's name. Give a little example here but it uses a class name. I'm not going to read the whole thing. We just need to apply a class name, that's fine. So we go into our code should be pretty simple. In fact there's actually a really well-known pattern for this. It's using object rest properties to pull off all of the attributes and then use JSX spread to put them onto the DOM element. So we do that pretty simple. Now we have another request and this is kind of interesting. We might have been able to suspect that this is something people would want to do eventually. But in our accessibility testing we realized that we could have some low hanging fruit that we could take advantage of by changing the html markup to be more semantic. So there's a question of like how can we fix this now that we already have a component that just does a div. Well we can actually do this in a non-breaking way with something that's really fun, a component prop.

6. Using Polymorphic Props and Delegation#

Short description:

Or if you want to be really fancy and show off to all of your friends you can use a more distinct and distinguished name like the polymorphic as prop. We're starting to notice layout issues because greet message was used all over the place. We can solve this with a little bit of delegation or inversion of control. Finally, we could have taken the path of asking our wise and knowledgeable neighbor, who might have suggested that at no point was any of this necessary. We didn't need a component and we didn't need props, we just needed a function and markup.

Or if you want to be really fancy and show off to all of your friends you can use a more you know distinct and distinguished name like the polymorphic as prop which seems to be popular these days. Not too hard to implement we use a little bit of fancy JavaScript renaming with our destructuring and we're good to go. Now we just start to come into some problems though. We're starting to notice a few layout issues because greet message was used all over the place but now that we can change the markup well we're starting to have some confusion around why it shifts the layout when we change that markup.

Now this is because we changed it so that we allowed people to make a div and this is kind of like this weird type of soft breaking change but we kind of press on and we think well maybe we can just solve this with default props. Well you know add some default styles and then just kind of put those on the element. Unfortunately that's not really good enough because sometimes someone might pass in these styles but then they come in at such a high precedence even when they don't pass in styles that we kind of have a problem where it's always going to be display block even if we want it to be display in line. So we can solve this with a little bit of delegation or inversion of control some really cool computer sciency terms making us feel really good about our choice to be front-end developers in 2021. And we do a bunch of fanciness to say that well you know if it's an object we'll try to merge it with some defaults but then otherwise we'll call it as a function which is kind of funny but you know it allows us to give the functionality that we want provide the defaults not break anything without actually creating a new api to opt out of those default styles.

Now finally with this request for internationalization you know it's time that we start thinking about right to left and so we have this new function that we can use and we can just you know use instead of having our own salutation we can now process that by just giving the name to this function and then it will provide the message that we need. And so this is what our component looks like at the end of the day after exhausting so many of the the patterns that we use as react developers whether that be you know delegation component prop poly or polymorphic as if you like to call it that defaults destructuring assignment all of these really cool things to make an extremely flexible and reusable component. But I'm left here wondering if we're not just doing what the cats and the kittens did to unsalt their salted cup of coffee. And if it's not satisfying to us, because we're not following in the footsteps of the collegiate cat to just feel fancy in pursuing all of these things that make us feel knowledgeable. Infusing it with some new chemistry or herbs. When we could have taken the path of asking our wise and knowledgeable neighbor, who might have suggested that at no point was any of this necessary. That choosing to use a component and props actually put us on a path where we were forced to solve some of these things that didn't actually need to be solved. Because all this time we'd actually had these tools available to us and we were just recreating in our own terms things that we had available to us in javascript and html. We didn't need a component and we didn't need props, we just needed a function and markup. Now I have less than three minutes, I have like a minute and a half to finish up to try to make some takeaways from this. My goal really isn't to tell you how to code but to throw an error. I want to throw the air that this is actually not the Hello World of React. There's a step below that we kind of missed in jumping right to components and props and that going right to this step as like the first step of understanding React and React component has cost us as an industry so much money and that every pattern that we have for props actually exists as a means to subvert using props in this kind of hysterical backwards way. And as I've talked with people about And as I've talked with people about why this happens, I've learned that it's really hard for us to throw these errors for a number of reasons, and the reasons that we don't throw them sound like this. I'm just doing what the linter tells me. It's safer that way. Refactoring is an acceptable form of procrastination. Demonstrating mastery of the patterns proves that I'm competent. Tech lead, read a blog on a pattern and won't merge without it. Most complexity makes more complexity makes me feel more clever. Fast fixes are rewarded.

7. The Cost of Communication and the Right Tool#

Short description:

Slow solutions aren't. The problem isn't code. It's communication. The rise of the component has forced us to move closer together. This problem is costing you, it's costing me, and it's costing the companies and communities. We need to ask, is the work we're doing the work that needs to be done? Are props and components the right tool? Let's stop making the most expensive React component.

Slow solutions aren't. I don't get paid more for collaboration. The energy required to reframe the scope of a problem is a lot more energy than it takes to push a patch. I'm an engineer, not a manager. If I can't, if I can fix it, no matter how hacky, why wouldn't I? Try dogma and criteria comes down but it doesn't go up.

The problem isn't code. It's communication. We want people to see us as smart little kittens. The rise of the component has forced us to move closer together than we ever have before. And there's this immense organizational, cultural, and social tension that leads directly to the pain that we experience in working with and designing components. And I believe this problem is costing you, it's costing me, and it's costing the companies that we work for, and the communities that we support.

And as I think about it, the only people that really win from all of this are consultants and educators. So we need to get better at asking the question, is the work we're doing the work that needs to be done? And specifically for us React developers, are props and components the right tool for the job that I have when children and functions exist? The basic building blocks that have always existed from HTML and JavaScript. Now, only if we can do that, can we stop making and remaking the most expensive React component in the world. Hey, thanks so much for listening. Again, I'm Chantastic, and I hope this talk helps you think about the work that you're doing a little bit better.

Michael Chan
Michael Chan
23 min
25 Oct, 2021

Comments

Sign in or register to post your comment.

Check out more articles and videos

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

A Guide to React Rendering Behavior
React Advanced 2022React Advanced 2022
25 min
A Guide to React Rendering Behavior
Top Content
This transcription provides a brief guide to React rendering behavior. It explains the process of rendering, comparing new and old elements, and the importance of pure rendering without side effects. It also covers topics such as batching and double rendering, optimizing rendering and using context and Redux in React. Overall, it offers valuable insights for developers looking to understand and optimize React rendering.
Building Better Websites with Remix
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Top Content
Remix is a web framework built on React Router that focuses on web fundamentals, accessibility, performance, and flexibility. It delivers real HTML and SEO benefits, and allows for automatic updating of meta tags and styles. It provides features like login functionality, session management, and error handling. Remix is a server-rendered framework that can enhance sites with JavaScript but doesn't require it for basic functionality. It aims to create quality HTML-driven documents and is flexible for use with different web technologies and stacks.
Don't Solve Problems, Eliminate Them
React Advanced 2021React Advanced 2021
39 min
Don't Solve Problems, Eliminate Them
Top Content
Kent C. Dodds discusses the concept of problem elimination rather than just problem-solving. He introduces the idea of a problem tree and the importance of avoiding creating solutions prematurely. Kent uses examples like Tesla's electric engine and Remix framework to illustrate the benefits of problem elimination. He emphasizes the value of trade-offs and taking the easier path, as well as the need to constantly re-evaluate and change approaches to eliminate problems.
React Compiler - Understanding Idiomatic React (React Forget)
React Advanced 2023React Advanced 2023
33 min
React Compiler - Understanding Idiomatic React (React Forget)
Top Content
Watch video: React Compiler - Understanding Idiomatic React (React Forget)
Joe Savona
Mofei Zhang
2 authors
The Talk discusses React Forget, a compiler built at Meta that aims to optimize client-side React development. It explores the use of memoization to improve performance and the vision of Forget to automatically determine dependencies at build time. Forget is named with an F-word pun and has the potential to optimize server builds and enable dead code elimination. The team plans to make Forget open-source and is focused on ensuring its quality before release.
Using useEffect Effectively
React Advanced 2022React Advanced 2022
30 min
Using useEffect Effectively
Top Content
Today's Talk explores the use of the useEffect hook in React development, covering topics such as fetching data, handling race conditions and cleanup, and optimizing performance. It also discusses the correct use of useEffect in React 18, the distinction between Activity Effects and Action Effects, and the potential misuse of useEffect. The Talk highlights the benefits of using useQuery or SWR for data fetching, the problems with using useEffect for initializing global singletons, and the use of state machines for handling effects. The speaker also recommends exploring the beta React docs and using tools like the stately.ai editor for visualizing state machines.
Routing in React 18 and Beyond
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Top Content
Routing in React 18 brings a native app-like user experience and allows applications to transition between different environments. React Router and Next.js have different approaches to routing, with React Router using component-based routing and Next.js using file system-based routing. React server components provide the primitives to address the disadvantages of multipage applications while maintaining the same user experience. Improving navigation and routing in React involves including loading UI, pre-rendering parts of the screen, and using server components for more performant experiences. Next.js and Remix are moving towards a converging solution by combining component-based routing with file system routing.

Workshops on related topic

React Performance Debugging Masterclass
React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Top Content
Featured 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 2021React Advanced 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 2021React Advanced 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 2021React Advanced 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