Components

[00:00:00]
>> All right, so we talked about reusable styles, we talked about reusable values. And just like JavaScript, now we'll go up one level of abstraction, let's talk about reusable components. Again, this is where my job gets really easy because when I say the word component, it's not like but it's deep now, it's like kind of the same thing, right?

[00:00:23]
It's like a reusable piece of UI that you can use and change and update things. There are some nuances that we'll kind of get into, but let's start with the very basics in this case. Which is let's say we wanted to create a little kinda like fake button, just like we did before, auto layout will say Button or Button, in this case, Button, all right?

[00:00:47]
And we'll say make that an auto layer frame, awesome. And let's go ahead and let's actually say. I don't wanna use the cozy padding, so we'll say. Rounded and I'm gonna then say that that is, I think I like 16 for buttons. Good part about variables, I can change it if I don't like it, and we'll scope that over only a quarter radius, corner radius.

[00:01:24]
Cool, and so let's go ahead, and we'll say that that is gonna be our rounded value and then the fill is gonna be primary 400. Now that's too roundy. So go ahead, change that to an 8. Nice, that looks like a button. Again, I can maybe make another variable that is button label, just like you saw in those other examples before.

[00:01:58]
For the sake of staying on topic, I'll skip that for a moment. So I have this button, most of the UIs I've worked on tend to have more than one button. There are a lot of buttons, almost as many as they have input fields, there's a lot more input fields.

[00:02:13]
But I might wanna have more buttons, I might wanna use them throughout my design. Even though making that button was somewhat simple. And even though I'm referencing at least for the border radius and for the fill color, changeable things, I don't wanna make this button that many times, all right?

[00:02:28]
In fact, cuz there are other things about this, like could I make more variables for the padding? Should I? Absolutely, I should because I'm gonna use the same kind of values multiple places. But the idea of a button I might seek to have in more than one place.

[00:02:43]
So as you sort of build out a design system and some companies have a design system team to build out a design system a long enough period of time. You always, there's a design system you intended to build and the design system you ended up with just because your application grew and has more than one button.

[00:03:01]
Are there are various different things that you use, so with this we can go ahead, and I can either click this up here, or I can right-click on it and say create component. Or I'm sure there's a keystroke that I can press was obviously, Options+Cmd+K, and it'll go ahead, and it'll create a button, and then it gets this purple thing, right?

[00:03:25]
And that seems real cool. I like that, and if I go into assets, under local components, I have the concept of a button. And with this button, I can make many buttons. This is also a button, you're all JavaScript engineers, right? Are you familiar with the idea of prototype inheritance, right?

[00:03:48]
Nobody deals with it anymore. But this button is basically the kind of prototype for all of these other buttons, right? So I did not store the padding in a variable like an adult. I just made a button real quick, and then dragged a bunch onto the page, did not store the label color.

[00:04:05]
But what I can do is I can change my prototype and then for all the properties that are not being overridden, they will go ahead and inherit that as well. So now, I have the world's ugliest button, I can go ahead and say, And you'll be like, that's not what I want, I want my buttons to have different labels.

[00:04:29]
It works exactly like prototype inheritance in JavaScript, which is if the instance doesn't have it defined, it looks up to the prototype. So if I went and said. Actually, let's keep that one. Right, only the one where it's not overridden actually gets the change. And that's actually true, so let's say hypothetically, let's get rid of the variable now for a minute just to make a point.

[00:05:11]
Where instead of 8, we're gonna get rid of that, and we're gonna say actually, you're gonna be 16 now. They all changed, but if this one, no go back to 8, it won't inherit the change even if this one changes, right? So whatever's not being overridden gets all the changes.

[00:05:37]
This means you can have large scale, sets of components. So we have one called Holocene that we'll use it tomorrow, that's currently still like internal OS, but it's an open source project, so one could go look at it if they wanted to. It's just not totally ready for mass consumption.

[00:05:52]
And then I made one just as a kind of example, where you have your buttons, and you might have your alerts. And you might have your checkboxes and your accurate set of icons and your inputs and labels and your radio buttons and stuff like that. So now, you gonna have all of these component pieces, yeah, let's go with the unintended pawn, that you kind of drag and use throughout your code base.

[00:06:17]
And then should you make a change to how these work, anything along those lines, then you get to the point where you can begin to kind of pull it all together. And so, the idea and concept of a component out of the box makes, I think some amount of sense like what I would say is like you can build a component based on other components, right?

[00:06:37]
So if you looked over here, I have a label and an input. Anyone wanna take a lucky guess what this label is on the radio button? Let's go, if I look at this label, it is actually referencing my label component from before, right? And so, if I change what the idea of a label looks like or anything about it, everything that uses that label, everything that uses an input field.

[00:07:03]
Even if it's like I could build a component that is a login form, that's made of two input fields, right? If I change anything about those input fields, the login form that references those components, even if it's a component itself, right? You can begin to build a level of abstraction, that is second nature to a lot of us as engineers, and everything you think about how you would use it is absolutely true, right?

[00:07:26]
And so, unlike some of the earlier things, I don't necessarily feel the need to labor that point too much, because components, they work exactly in Figma. The nuances, but like on a high level, they work mostly in Figma the way they do in your code. And the other thing that you can do is if you have a team account, you can at some point go in there and say, okay I want to go publish it as a library, right?

[00:07:54]
So now if you have multiple design teams, they all use the same set of components. You might have a Figma project that has all of these kinds of core components like we have one for our color system that's kind of shared across our marketing site, as well as the applications, right?

[00:08:11]
We have one for our cloud UI, one for the open source UI, but they all inherit from the same, set of components that are shared across all of these files. And then, can be used and then if the design team changes some part of our design language, they can push out these changes and all the designs can opt in.

[00:08:27]
We'll take a look at that a little bit later. But the fundamental concept is there, and you can go ahead and create a component at any given time. If you are using a component and this file is not super interesting, you can always hit main component, you can go to that main component.

[00:08:43]
If you change an instance, and you actually wanna push it back up to the prototype, you can push those changes to the main component. Dangerous as you might think it is, right? Hey, I'm in this really important context now, I changed five other files I wouldn't, but you do what you want.

[00:08:58]
And you also go to the main component which will then jump you back over there, so on and so forth, all right? Again, they take a lot of stuff that we saw earlier and allow you to abstract it, the rules that we said earlier about slashes and names also work for organization as well.

[00:09:18]
If they are any given page, once you have more than one, they'll begin to use the structure of your file. But if you have like icon/warning, that will be then be nested under icons, button/primary will be nested under buttons. You can also use sections for the same purpose, so if I made a section and we call it.

[00:09:44]
You can now see that it jumped under the whatever very importantly, now I have my button here, right? And so, you can use sections and pages and stuff like that to add some level of organization. And as we saw before, there's stuff the design team's working on, and then some of those ready for development or not.