 All right, thanks for the introduction. Just to be clear, the computerized voice is not this. It's like, it's gonna come from the Mac. All right, it's super good to be early. I didn't actually expect so many people to wake up early and come. So thanks for being here early. That's amazing. I'm gonna talk about good components. Let me just put a timer on. All right, so first of all, let me introduce myself. I'm Siddharth because you can never spell Siddharth in one single way. So I just go by Sidd. I'm an independent developer. I don't know what that means because my past job at odd zero was yesterday. So I'm independent from today and it's a weekend, so that's awesome. So yeah, I'm figuring what that means. If you have tips on what that means, reach out to me please. You can follow me on Twitter or you can find out more about me on this website. Cool, let's talk about the good component, right? Or as I guess now we're supposed to call it the Sadharan component or the Adarsh component. I don't know, translation project is on its way. So at the core of using React is writing components, right? I remember when React came out, there was a lot of buzz that this is the new fast framework, right? This is the performance framework. And then a lot of people, Google, kind of shit on it and said, no, it's so big, the bundle size is large. How is it fast and all of that? And the kind of, the whole story was around how the DOM reconciliation and like manipulation is super smart. But then the community kind of got over that point and let's be honest, most of us don't really need performance applications every day. But what kind of stuck around was this idea of thinking about your UI in terms of small components that get together and make big components. So we kind of started blocking them down, which was really the biggest takeaway and it was kind of the coolest thing that happened. So I've spent a lot of time thinking about what is a good component? How do you write a good component? And I came up with this bunch of tips that kind of encapsulate the concept. And I'm gonna get into those tips, but there is this theory that I have, which is if you're writing good components, you don't need a lot of libraries, like you probably don't need a state management library, you don't need like a fancy state tree and all of those things. Translation is gonna be easier, composition is gonna be easier. So the key idea is that if you write good components, your app will scale till a longer point until it basically gets out of hand and then you want to bring in external libraries. So that's the stock. So let's start with the first example. I have this simple button, right? You can't really see, but it's like a gray button. It's like the, what do you say? The slightest of grays that the designer could do in Sketch. So that's what this is, as design usually goes. And as it goes with buttons, you usually end up with a bunch of them, right? You have a normal default button, you have a primary button, you have a destructive button or a danger button. And this is how I like to call them and react, right? You say button and then you say, give it the primary prop and it will be blue and stuff. So if you would take out the prop tables for this, this is what it would look like. You have a primary destructive and then there's like a bunch more secondary link. I think in the, in Cosmos, the design system I was building until now, we had like six variants of buttons and that's just how buttons are usually. And then like, this is the first time that somebody asked this question, that what would happen if I did a primary destructive, right? Like which one wins or do they merge and what, right? And my first response was, why would anyone do that, right? Like if you do something stupid, then something stupid should happen, which is you don't know which one will win. And that was kind of my very developer response to it. No, it's the fault is in the user, not in the code. But since then I've kind of come around to the concept that we even put up a warning. So we had a prop type validation where you did something like this and it gave you a warning on the console saying, you can't use primary and destructive at the same time. Make up your mind, like pick one. And I was very proud of that, like custom prop type validation and it's awesome. But since then I've kind of come around that a good component should not have conflicting props. The whole idea with writing components and like creating an API or writing props is that you want the developer who uses this, right? I'm gonna say user where, I mean, the user of the component, right? So your fellow developers basically. The component user should not have to think about what will happen when something like this happens, right? The API should be more obvious. The API should promote the user to kind of get into a pit of success, right? It's the orbit of pit of failure where you basically write code and you don't make mistakes, right? The API helps you do the right thing, right? How many of you use TypeScript? Whoa, so many of you, yeah, I don't use TypeScript. But this is what the TypeScript fans have told me, that because of all the ID integration and because of all the knowledge that you get in the compiler, you kind of, it's very hard to make mistakes with TypeScript. Like the compiler is kind of your pair programmer watching for you, helping you out. So creating a good API is kind of the same thing that you're helping people do the right thing more often than doing the wrong thing, right? So that's tip or advice, whatever you call it. Number one, which is a good component does not have conflicting props. So instead of doing something like this, let's just call it appearance, right? And you can call it multiple things. I've seen people call it type, which can get interesting because there is an HTML attribute, also called type and then there's mixing. So I like appearance. Appearance is default primary destructive, like the whole list. All right, advice slash tip number two. So I have the switch component. It's fancy, I can click it and stuff. And then usually what you want is your user wants to attach an event handler, right? You say switch something and then the function should be called when this thing changes. So you can probably do something on click, right? That works. The problem I have with on click is that it kind of focuses only on the mouse user, right? There are a bunch of people who would want to use a keyboard, right? The most common scenario, which I get into is I'm eating a sandwich with one hand and I can't use the mouse because the other hand is dirty. So I just tap, tap, tap, right? But then there are more genuine use cases like if you're using a voice reader, right? Then you can't really click. You're probably going to a tab. You're going to use the keyboard. Or if you're on a mobile device and you try dragging it, right? You're trying to drag it to the right. So on click kind of as an API forces you to only think about the click case, which is not actually true. So this is what I came up with. I was like, let's call it on toggle, right? Switch is going to toggle. So it's going to toggle between on and off. So let's put it on toggle, right? And I was really happy with this inclusive API that I built that it's toggle, right? Doesn't matter how you toggle, all of those are toggles. I'll have to zoom out here, right? So you can't see the whole thing but the idea is that internally you still map all of those things that the user interactions will have. So you say on click should call props.toggle. On key down, check what is the key down. If it's an enter or a space, you want to call toggle. If it's a drag and you drag it to the right, then it should call on toggle, right? So internally a good component should map all of the user behavior like the end user behavior. And I should say end user interactions like click and drag and map them to the API that a component user would use, right? Let's talk about this one. So this is like a text input. It's the most common input field, I guess. And then you have over here, we usually do on change, right? And we all kind of agree that on change is the thing to use, right? We kind of as a community coincided on the same prop name, majorly because HTML attributes also have an on change that come shipped with the browser, right? So it was easy to just capitalize one letter and bring it into the React ecosystem. And we kind of all agree this, but this is what happens when you put both of these components together, right? So I'm a developer, I'm trying to build a form and then I put a text input and I put an on change and then I put a switch and I'm like, okay, what is the switch prop called? So I go to the documentation documentation. I go to the prop types definition and I say, okay, what is this one called? And I say, okay, it's called on toggle. So then I come back and put an on toggle, right? So we have two components that make sense on their own, but they don't really make sense when put together. Like why are they basically have the same behavior which is you want a function or a callback to fire when this changes, right? When the value changes. So why can't we call it the same thing? So which is where the two comes from, which is a good component gives names to behaviors, not interactions, right? So on change instead of on click on key down, all of that, right? You want the user of your component, your fellow developer to think about the functionality, not the interaction. The interaction is baked in the component itself. So give names to behavior, not interaction. Another way of saying this is the same behavior should have the same name across components. So good component does not only care about its own props, but also cares about the consistency of props across the code base. This concept is like, I first came across this concept in this talk by Sebastian Magboga, which is quite minimal API surface area. You should search it, it's on YouTube. It's a great talk. His core idea was that you should limit the amount of API that a developer has to learn before they can be productive with your code base or your library, right? So if you're building a library and you ship it to people, they shouldn't spend the all day looking at documentation. Similarly, if you onboard a new developer into your team, you want to minimize the amount of time they can learn the entire code base and start being productive, right? So great talk, do check it out. Oh, by the way, this talk is from 2013, right? Which is super old, but six years later, everything is still super valid. It's amazing. So yeah, we basically just change on toggle to on change and yeah, consistency, awesome. Tip number three. I have this avatar and it has Simon's cat photo over there. And again, how avatars usually go is like you have a bunch of them. So we had this user avatar and we had a resource or application avatar. So we put the Firebase logo there and you usually see avatars in a bunch of places, right? So this is from GitHub. This is like a super big one and there's like a tiny one and this tiny one. So you usually have a bunch of sizes. We have the same thing. So we put all of those out, right? User avatars come in multiple sizes. You put, we really like using T-shirt sizes for this because you can encode T-shirt sizes to pixel values and then you get a fixed set of things, right? You get an enum. So extra small, small, medium, large, extra large. We have like these five sizes, five sizes. And because the avatar component is the same, you kind of get the same thing for free for the application one. We don't really need five sizes for application, but it's free. So who's complaining? It's all right. All right. So we put both of them together and how you would typically use this is you won't really hard code the URL in your component. You probably get it from props or a user object. So you say props.user avatar or props application logo. And now with avatars, you kind of have to think about a lot of scenarios. What happens when the avatar is missing, right? The user has not uploaded a photo, right? We don't have a logo for the application yet. So you need like a missing one. So the missing one for the app, sorry, user avatar is the silhouette of like a face and stuff. But for the application, it's a vague application logo, which is just the company's logo. So you kind of have to make a decision if it's missing and the type is user, then use this one. If it's missing and the type is resource, then use this other image. So you kind of do a fork kind of a thing. With users, we can do better, right? You probably have the name of the user. So instead of showing the silhouette, we can show the initials. And this pattern was like made popular by Gravatar first, but then Gmail really picked it up and blew it up for everyone. So you can pass the initials, which will render over here. Sure, I'll go for it. All right, what's the name again? Summit, I'll remember Summit, okay. With the application avatar, you don't really want to show the initials, right? Showing FI or FB for Firebase doesn't really help. Instead, we want to show what type of application it is. So this one supports an icon. So you can show a database, right? And now you kind of see where this is going. You have this avatar component that has all of these props. It has image size type initials. And there are some unwritten rules over here that please don't use icon with type user or please don't use initials with type app, right? Or if you want an application avatar, don't make it circular and all of that. So there are like these unset rules over here. And there's this amazing word which all credit goes to Jen Creighton. She calls it a prop collapse, right? It's a play on apocalypse, but with too many props. And the whole idea of this is a good component should follow the single responsibility principle. So this is a principle older than JavaScript, older than React. And the idea is that when you see a component trying to do too many things and this is a React symptom, which is it just takes too many props. And there are like unset rules between how props combine with each other. This is a symptom. The problem or the cause is basically your prop is trying to be a hero. It's trying to do too many things. It might make sense to create two props out of them, right? So you create a user avatar which just takes care of users, single responsibility. And you keep a resource or application avatar, which is responsible for the application stuff. Another good thing happens here, which is like the prop is the same, basically, so you call it image. And instead of initials and icons, we can just call it both of them fallback, right? What should be the fallback of data is missing? And the interesting thing that happens here is we kind of reach the same stage of tip number two, which is when you look at one component, say you're using user avatar, you know what the props are. Now, when you have to write a resource avatar, you don't have to go back to the documentation or learn it again. If you know one, you know the other because the props are the same. And that's really cool. So if you look at these two prop tables, they're basically the same because they have the same props, right? The only complaint I still have with this is that the fallback prop for one of them takes a string which is initials, but the other takes a string which has to come from a set of icons that you already have, right? So there's like, it's not fully consistent, but it's way more consistent than the four. And of course, like if you're a developer, then you're already thinking, yeah, but it looks the same, I'll probably use the same abstraction underneath. So I'll use a base avatar and I'll try to hard code some of the values. So for example, user avatar just returns a base avatar with hard coded type. And the initials is just gonna map to fallback, right? So you get something like this. Same thing with resource avatar, basically you just take the fallback, map it to the icon. And base avatar can again take both of them, which is smart, but then you can't really come up with that on day one, right? It's always safer to start with two and then find those patterns that come back. So Sandy met super big in the Ruby community. She gave this super scandalous talk which told like a thousand group of developer to do duplication over abstraction, right? And this is like core object oriented developers. They went mad, they tore the table. Nothing, everything was fine. So her core idea was that no abstraction is way better than the wrong abstraction, right? You can always take this, these two and create a common layer out of them. Doing the other way round is way, way, way more difficult. So you can start with duplication. Once you start looking at patterns, then you can create the abstractions you want. All right, we're running late, so quickly tip four. Yeah, I like this one. So you have a badge component, right? Badge components are everywhere. You see them on GitHub and other places and we actually needed a bunch of them. So we did like appearance, information, blah, blah, blah. The good part is that we still use the appearance prop. So that's nice, but the values are different. So you do account, right? And then we had this label component which took a text and put it there. Again, GitHub has the same. You have these private things, right? You have a private label over here and luckily it also took an appearance and it had basically the same appearances. Now, when I put both of these together, right? Do you see something odd over here? Let me put it here. So can you tell me one good thing about this and one bad thing about this? Just shout it out. Is that the good part or the bad part? What's the good part? Awesome, yeah, so the really good part is that both of them have the same appearance prop. So if you've used one, you can predict how to use the other. The really good part is that all of these appearance are also called the same thing, right? So when you basically use them together, if you're using a danger or a destructive badge, you can say destructive label and you know, they go together because somebody has taken the pain of keeping them the same names. The bad part is that they basically, both of them do the same thing which is put text inside them. But the prop for doing that is called different, right? It's called count for a badge, which makes sense, badges of count and text for label, which also makes sense on its own. But when you put them next to each other, it looks weird, right? It looks silly. So how about we call them content, right? Content is vague enough. It's like, what content goes inside this, right? And I did this and then I like, luckily five minutes later, I see this tweet by Brent Jackson, which is like, don't reinvent props to our children, right? React already gives you a way of putting content inside of components, right? It's called children, it's a native property of React. So if you're defining props that take arbitrary input like count in text, it's probably better to just use composition and the composition, you mean, just put it inside the thing, right? So that's tip number four. A good component is composable, right? So instead of doing something like this, just put it inside, right? So you say badge and the child is 12. Label, the child is private. The good part that happens here, there are like multiple things that happens, but the lowest hanging, whatever thing happens here is that you don't have to learn what the badge calls its children because it's called react.children. You put it inside it, right? So you immediately remove a prop, the minimal API surface becomes even smaller. And there are other really good things that you can do. For example, I have this alert, right? I have a type warning and then you can put a message. You can change the type and let me, this probably works or this works awesome. And then we kind of had a request that can we put an icon here, right? I want to put like a warning icon and I want to choose what icon. So if it's like a danger or a delete, maybe I want to put the delete icon or something. In this alert, I would probably have to go back, build it in, like accept an extra prop, put the positioning for it and then ship it back to the person who wants to use it. But if I actually accept children instead of this custom text and icon API, somebody can actually just put it inside, right? You say icon type, icon name is warning and the text inside it, right? So when you have an API like this, you don't have to ask someone else to bake this new feature in. You literally can use the icons that you have and put it inside it, right? Which makes alert more composable. You can change it. It's more flexible. The big nuance here, which like the first time I talked about this concept, a lot of people came back to me and said, what if we don't want this? So that's fair. If you want to have like design consistency where you say alerts cannot have icons, that's a rule we made up. Then don't do this, right? Then don't support children. You can always go back to supporting a fixed one, right? So there's kind of a difference. If you want a component to be super strict because you want to make it consistent, create a shape like this. But as in like 99% of cases, you want people to customize what's inside it. Just use children. That kind of takes away some development work as well. All right, tip number five. So say you have this link, right? It's a link. You click it, it does things. And this is what it would render. So you have a anchor tag, you have an HREF and you have a class inside it. This is what the component does internally. If you look at the code, it says, it's basically a link. It takes the HREF and it says, class name is link and it renders that out, right? So you essentially just do HREF and you attach this extra link class that you have already written down somewhere. But can you guys see the last line? Okay, so what if I wanted to do a target blank? Would this component open it in a new tab or would it open in the same one? All right, so this one actually ignores the prop target, right? It doesn't care about it. It only cares about HREF. And this is like one of the first mistakes I did when I started writing React. I would pick what I could think of and ignore the rest and then it wouldn't work the way it should work, right? So you do this and it ignores it, which is bad. So another case could be you write a data test key, right? You're trying to add data attributes, like custom attributes. The thing with target or ID is that you can think of them, right? There's a close set of things. So you can put all of them in if you're like really eager. But then in like the HTML world, it supports custom elements, custom attributes as well. So what if I want us to do something like data test key or data test ID? You possibly can't predict everything that's going to come here. So the wise thing to do is pass down all the props to your component, right? So you get the props, you pick what you need. You basically take them out like HREF and you basically pass all of them down to the anchor, the HTML attribute itself. So this way, whatever you pass here will basically just flow down, right? The interesting part is that children is also one of them. So you basically don't even need to do props to our children. You just pass everything and then add your own custom property, which is class name. Now, if you want to introduce new custom props for your link, right? Make sure you kind of pull those out before passing them to the anchor attribute because you can only pass HTML attributes, not react props that are not meant for the HTML. So make sure you do that. Cool, so this is what it renders. It basically takes everything, drops whatever you give, plus adds my own class over here at the end so that it's blue and pretty and stuff. Now, for whatever reason, I wanted to make a green link, right? So I pass a class name. This is how somebody using your component would do. They'll say class name green link and can somebody tell me if will this render a green link? No, right? This still renders the same link and that's because you basically are overriding whatever class come from props. So if we expand this props up, it looks something like this. You have a class name, which is props.classname. You have a class name link and then you have the rest of the thing. So what you're essentially doing, you have two class names now, one from props, one inside this component and the second one will always overwrite the first one because JSX converts into an object with react.createElement and in object, you can't have two keys that are the same, right? So the second one always wins because they get merged and squished. So you kind of end up overriding this and you never get a green link. So how do we let the user of our component customize the look? One simple way could be just flip this order, right? Put your class name first and put all the props next. So now when somebody passes a green link, the opposite happens, which is your class name comes first, your class name comes first and then comes props.classname and then they can override it, right? Now, this is again very interesting because this is pretty much a choice at this point, right? Do you want your link component to be customizable? Can the user override it? If yes, then put your native class name first and put the props next. If you don't want them to customize, if you want link should always be blue, nobody try to mess with this. Then you do it the other way around and put a warning inside it like a prop type that if you pass a custom class name, the user gets a warning that, nope, this is not allowed, please don't do this. The most common use case though is going to be something where they're trying to enhance it. So I still want a blue link, but I want it to be underlined, right? With this approach, when I say class name underline, it will override the whole thing and you'll just get a ugly link with a underline, right? What you really want is to kind of merge and say link and underline attach both classes. With class names, it's actually with most custom props, that's usually the case. So what you really want to do here is pick out class name from the props, right? I'm using object destructuring here and I'm taking all the other props into a different variables with the rest, what do you call it? Rest parameters, spread, I don't know. I can never say which one is spread and which one is rest, but the three dots thing, right? And then you say a class name is my class plus the class names that the user gave and then I can merge them together and then pass all the other props as a whole. So this way, when I render underline, you actually get link and underline together and then the rest of the props. So there are a bunch of cases where you want to enforce that enforce the consistency that you're not allowed to modify. In that case, put props before your custom thing. In some cases, you want to let complete overriding. In that case, put props first, put the, what do you say? Custom class name next. In most cases, you want to merge them, right? Think about onclick, right? If you create an onclick handler on your link and the user also wants to pass an onclick, you kind of do something similar over here where you basically say, call the users onclick, props.onclick inside of my own component onclick, right? So you also want to merge events most of the time. That's pretty common. All right, so the tip here is that a good component is extendable, right? You want to take in the user's props. You want to think about that while building the component, which is if somebody wants to customize it, they should be able to pass something and then you merge or you ignore, depending on what your component is supposed to do, right? The typical mistake I've did in the past was I just created an underline prop and then said, if props.underline, then also add an underline. Don't do that. You can have customization to like a perfect limit where you just pass without modifying. So this is a good way to do that. All right, number six. Tabs, are you like that? So number six is that you say if you're building tabs, right? Now, a typical user would use tabs something like this. You click it and you go inside it, right? But if you are a user that's not using the mouse or if you are visually impaired, then you can't really see where to click, right? In that case, you want your components to be accessible. So let me try to open accessibility. Let's say, whoa, where's voiceover? Can you hear anything? Yes, voiceover is on. Chrome, the good component. Google Chrome, window. Tab one, selected tab. One of three has keyboard focus. Right, so this is the key part. You say tab one, like this is the voiceover part of it. When you say tab one, selected tab one of three, right? So you say the three tabs, first one has focus. Then you put the right key. Tab two, tab two of three. Tab three, tab three of three. And then when you enter, you kind of get to this, you press another tab and you get inside. Enter some text, edit text. And this is the annoying part where it reads out everything you say, so. H-I-S-T-A-E. I don't know how they use this. I guess they're really good with the keyboards. And then when you tab it, it should go to the icon. Now this is like a pretty common modern UI trend where you put these cute icons which the icon is depicted enough to what it does. But to somebody who can't see, the icon is like not there. The shape of it is no information, so. Copy button, copy refresh tokens, button, refresh tokens. Thank you. And when you can change this, it will also say what's the new thing, I hope. Okay, I don't know how to do that. So the idea is that a good component should be, let me. Tab, spotlight, O, C, voice over voice. Oh, God, stop. Chrome, voice over off. Thank you. A good component should be accessible. If you create components that are accessible, your application has a higher chance of being accessible. Even if the person who's building the application doesn't care about accessibility, the fact that your component cared about it makes your application automatically accessible for a lot of, more than 50% of the cases because HTML itself is accessible. So in terms of accessibility, there's a few things that you have to do. For example, roles are really useful. So if you say, role tab list, that tells your browser it's a tab list. Then you say, this is my list of tabs. Each one of them is linked to an ID. And then you say, the one selected is, are you selected true, right? I'll drop a link, which kind of has like a good description of all of them. And then you add this, where you say, tab event listener attach a keyboard event. And then you say, if you press the left arrow, switch the tab to the previous one. If you press the right arrow, switch it to the right one. If you press enter, go inside the tab, right? And you have to kind of do all of this yourself to add keyboard support, because the browsers can't really guess what behavior do you want. So make sure you remember that there are more users than the mouse and try to do a keyboard thing. This is also pretty good. Let me bring that back. How do I, oh sorry, I want this sound back on. Bullet, bullet, bullet and selected. This is really smart. I didn't know this, but when you say a password. Bullet, bullet, bullet. It doesn't announce your password into a room. It says bullet, bullet, bullet, right? Which is like so obvious, but I was like, wow, that's smart. And you, so when you have a button, right? And you put the text in the button. Refresh tokens, button. It will tell you what the text is, right? It will read the text out and this is perfect, but. Bullet, bullet, bullet, text. Const link equals prop text. I just want to bring the whole code. Voice over off. All right. Okay, so usually when like, this is like a more modern approach where you put like an icon. And this is really weird because even, okay, right? So I have the icon reload and appearance of link. Now, even as like a non, like even as a user who can see and hover and stuff, I have no idea what this is supposed to do. Is it going to reload? Is it going to refresh the page? I don't know. So that's like bad for everyone. So the least, the tiniest thing you can do is put a title tag. And then when you put a tag, let me show you the voice of it. That's even more fun. So it's a bullet, bullet, bullet. Voice over on Chrome. The good component. Google Chrome, window. 12 characters, 12 characters. Insertion of end of text, secure edit text. Button. It's just a button. Button. Button, best of luck with that. Figure out what that means. Bullet, bullet, bullet and selected voice over off. So, and when you have, when you add a title tag, you kind of make it easier for it to read because it can read the title. Voice over on Chrome. The good component. Google Chrome, window. Refresh tokens. Button has keyboard focus. All right, let's switch to. 12 characters. Refresh tokens. Button. So we say button, it will also say what is the button title, right? So that helps. And as a mouse user, you can actually hover on it and it will show you the title. But even better than this to add a tool to text. Constantly. Voice over off. So when you hover on it, you kind of see this as refresh tokens, right? And it's really good for visual users. But then the moment you remove that title and you move that information elsewhere, you lose that information on the button because it's somewhere else now. So when you're tab on the button, you're not actually tabbing on the tool tip because the tool tip is not visible. So again, visually impaired users can't really see anything. So that's where you can be slightly better and do something like this. So you have, this is my tool tip component. And what I do here is I attach an ID to the tool tip. And in the button, I say the way, let me share the output first because that's more useful. I don't have the, sorry, let me go back. All right, so what we want for the button is to add this aria label cause aria described by. It comes in multiple forms. And you can also call it aria labeled by. There's a very tiny nuance difference between the two. But essentially you say, the button is described by this other element and the ID of that element is this, right? So inside the component, you create a unique ID. You pass that ID to your tool tip and then you basically pass this aria described by to the button itself. And that will tell the screen reader when you're on the button, the description is elsewhere. Go there and read it out. So this works. And again, there are like multiple ways of doing this. One way is you can tell your users that please remember accessibility, right? Unfortunately, most of us don't really know what that means, right? To make this talk ahead to research and like make sure I'm saying the right thing. So a good component should be accessible by default. It should try to offload most of the work, unload most of the work to itself so that the user doesn't have to do it. An easy way of doing this is you clone the children with a tool tip usually just have one child. So you clone the child and you pass this label to it so that what your user has to do is put this content which they anyways will because the tool tip needs some content. And that is what the button will get by default. The developer might not even care about it. So a good component is accessible by default. This is like a great rate it's called inclusive-components.design. It's like a really fun series of blog posts which is like really good to read and it explains so much. This is where everything I learned from. All right, number. Cool, is that five minutes, 10 minutes? That includes questions? Okay, let's speed up now. All right. Let's, I already said this, we can skip this. We don't, okay, cool. Let's talk about this. So when you're testing components, right? How many people write tests? How many people are lying right now? Wow, good, actually hands went down. Cool, I'm very happy that so many people are writing tests. So when you're writing something like this, right? The same tool tip example. In this case, what you want to test is when the user clicks or enters, hits enter on this refresh tokens, does this thing change? Does the value change? And what this renders to is this div soup, right? It has like a bunch of things. It has the classes over there. And the thing about react components is that you don't, when you're using a react component, you don't really care about what's the DOM output most of the time. And if the DOM output changes inside without breaking the API, your test shouldn't really break down, right? So the best way to do that is attach these data test IDs, right? Instead of relying on something like first child of component and then the second child of the component, give IDs to things. And then you can have, even if the structure completely changes, the test IDs will remain there. So you can still use them. And then you can do something like this where you say, if you're using enzyme, you can do wrapper.find with the test ID. And then you simulate a click and then find the input by the test ID. Or if you're using react testing library, which is awesome, you can just do get by test ID and then give your ID over there. So attach test IDs, it just makes testing easier, right? A lot of people have a hard time. Where do I start with testing? This is a great place to start because it makes the actual task of writing the test so much easier. All right, so good component is easy to test. Number eight. Oh, number eight is how do you, I told you so many things which is basically just rewrite everything you wrote, right? And the moment you start doing that, you're gonna burn some people, right? They'll have a pull request, you've made some changes, they're gonna back merge, they're gonna complain about it. If you work on a library, you're gonna make breaking changes, the users are gonna be mad. So how do you bring changes smoothly? You basically support the old style of doing things like in this batch, the count prop and the new style for a while, right? And to do this in your component is fairly easy, right? You say, prefer the new prop, but fall back to the old prop and then both of them work. And then in your change log or documentation or prop type definition, you add like just like a hint that please don't use count as deprecated, switch to children, we might delete it at some point of time, right? And if you maintain a change log or if you write good documentation, then this is a easy way to do it. You say soft deprecations don't be scared, but this will go away at some point of time. So the way to do that is you kind of can do prop types. You can add custom prop types validation where you say, if the user gave a count, throw an error that count will be deprecated in whatever release 1.2.3 or more like 2.0.0, please use children instead, right? So a good component changes smoothly. It gives developers enough time and warning to upgrade, all right? So this is like the long list, which like, you can't really remember all of this. So I put this on a page where it's on sit.studio slash good component. And you can see the list. I wrote blog posts about most of them. So you can go in and kind of explore the examples and read more about it. I send this stuff every Friday, all of like everything you just learned except the accessibility part. It's on my newsletter. Maybe some people have already read it. So sorry for the redundancy. But yeah, I send react stuff every Friday. I think that's it. Yep, that's all I have. Thanks, Sid. I know we already have one question lined up. Yes. Can someone, one of our mic runners get a mic to the questioner? No, you can have my mic. Can you please raise your hand? I've already forgotten your name. Sumit had a question earlier. In the middle row there. So basically I have two questions, not one. So the first question is in the batch component, you show, not in the batch component, in any of the component like avatar component, you show the props.missing. Yeah. So don't you think that it becomes the responsibility of the developer that if nothing is coming from the props, he has to explicitly pass the missing props in the avatar component based upon its appearance. I would say no. The responsibility of making sure that your design is consistent should fall back on the building blocks of it. So if there are no props, instead of each place where the developer uses or each developer in your team, trying to figure out what is the right missing icon for this, you bake the design decision into the component itself and that makes it consistent. Plus it kind of takes away the responsibility into the component itself. So I see your point that if you're a developer, you should test it out. You should know what you're doing, but knowing versus doing the work can be very different, right? If you're a new developer in the team, this is how you learn. You make a mistake, the component takes care of it and you're like, oh, this is the icon we use, right? So the more logic or the more fallbacks you build into the base building blocks, the better your entire application is going to be for that. And the second question is you said that every component should have a similar kind of the behavior. So for example, in our application, if I have, like you show the switch, like the switch, so switch is basically a checkbox. So if I have the custom checkbox and the custom switch, so both are doing the same kind of the behavior, but they're entirely different in terms of the appearance. Should I make the same component or the different component? Awesome. So usually what you want to do is you want your developers and your users to think about the behavior, right? What the end user, what is the user trying to achieve? The answer is never going to be, I'm trying to toggle a switch or I'm trying to click a checkbox. The thing is going to be, I'm trying to verify I'm not a robot, right? Or I'm trying to subscribe to something, notifications, right? So the user doesn't really care. As a developer, you want one way of doing a single thing, right? So ideally you should just have one of them. But even in the case where you end up with two different appearances on two different pages, just by making the behavior the same, you kind of get to the same thing where your developers are thinking in terms of the user or in terms of the functionality that how do I make this user say he's not a robot? Instead of how do I make, what appearance should this user be clicking to verify he's not a robot, right? So if you always focus on the behavior and let the interaction be inside, that always helps. I'm sorry, but we are out of time for questions. Please take this offline with Sid during one of the coffee breaks. Thank you, Sid. That was great. Thank you.