You're not requiring a library. You're just applying and naming classes in a specific way to make it easier to maintain. That's it. Nothing more, nothing less. Okay, so BIM, as you can imagine, is an acronym. It stands for block element modifier. Or if we were writing HTML, let's say we have a block for maybe something like a breadcrumb section. Okay, well, your main block or your main component name would be breadcrumb. And then presumably, and by the way, this might be an unordered list.

Okay, well, your main block or your main component name would be breadcrumb. And then presumably, and by the way, this might be an unordered list. But anyways, then you might have specific items that need styling within it. So, for example, we might give that a class of breadcrumb-item. Notice the convention I'm using here. I've referenced the name block name, followed by two underscores, and then the element or the child name. Now, that takes care of the block and the element aspect. But what about the modifier? What exactly does that mean?

Just follow something and keep it consistent. As an example, a lot of people use lowercase letters for their block name. For me, I kind of like that idea of thinking of this as almost like a class. So, I would make that uppercase, but you don't have to. Whatever you want to do, whatever your team wants to decide. And the same thing for states. So, in this case, I'm using breadcrumb with pipes. Maybe you want to say has pipes. Or maybe you want to always precede states with the keyword is. Any of these are options.

Now, on the other hand, if we have something like this, okay, well, actually, this becomes much more clear. I can see that this class is a direct child of this block or this component here. And they will be contained within the same file. I can specifically see that, okay, this is overriding the default state of a breadcrumb. And that, too, will be contained within the same file. And then further, if I have special utility things, so for example, utility-margin-small or something like this, once again, it's that much more explicit that this is unique to this. So the class I'm applying here is not connected to the breadcrumb component itself.

to this. So the class I'm applying here is not connected to the Breadcrumb component itself. We're just overriding one specific thing. And this would be contained likely within a utilities partial. Notice how explicit this is. Okay, so we know how the HTML would look. But how would we write it out? Okay, well, I like to compose everything in their own files. So in this case, if I have a Breadcrumb component, then I would say something like this, import, go into a components directory, and get me Breadcrumb.

So in this case, if I have a breadcrumb component, then I would say something like this, import, go into a components directory, and get me breadcrumb. Okay, I'm going to create that, components, breadcrumb.scss, or again, I like to use .sass. Okay, what do we need here? I'm just going to grab this and bring it over for our example here. Okay, so first, we need our top level block name, and that will be breadcrumb. Now, maybe in this particular case, we're not really styling this, but maybe like a background color of gray, something like that. Next, what about the child here, a breadcrumb item? Okay, let's style that.

Next, what about the child here, a breadcrumb item? Okay, let's style that. Maybe this has something like after, we will have a content equal to a \, and then maybe padding of 5 pixels on the left or right, something like that. Finally, we have our modifier, and this is a different state for the breadcrumb. So I could say, well, a couple options here. I could write this out explicitly. So I could say a breadcrumb with pipes should have different styling accordingly. Or alternatively, we can put this inline. So I could do something like this, and with pipes, then do your necessary styling.

Or alternatively, we can put this inline. So I could do something like this, and with pipes, then do your necessary styling. I'm just going to set background red since I don't have anything specific in mind. But yeah, you get the basic idea. And then, oh yeah, by the way, let's make sure we double escape that. Okay, so from our entry point, whenever you use something like Sass, rather than just trying to compile a bunch of files at once, instead, it's a good practice, have a main entry point file. In this case, app.sass, where we import everything we need, and we compile that down. Next, I am using Laravel, so we have this out of the box.

In this case, app.sas, where we import everything we need, and we compile that down. Next, I am using Laravel, so we have this out of the box. But we are using the traditional SASS syntax. All right, so let's try this out. I will run gulp to compile this down. And now, if we take a look at the output here, there you go. So I have nested styling here, but you get the basic idea. We have our block. We have our modifier, the different state. And then we have our element itself.

So instead, what if we extract a mixin? And this is something I learned from Scott Kellum. So if we go back here, why don't we begin by importing maybe a mixins file? Something like that. And I will go ahead and create that. Now, what we want to do is facilitate the process of quickly adding elements and modifiers to a block or a root component. So let's try this out. I'm going to say we will call this mixin or this little function e, e for element. We'll accept the name of the element here.

I'm going to say we will call this mixin or this little function e, e for element. We'll accept the name of the element here. And then when we call it, we will reference @root, like we learned about. And then, yeah, we're basically reproducing what we had right here, where we use that same & symbol syntax. OK, so now, so we'll do &__ and then the name. And then within here, we will spit out the content. It's OK if you're not overly familiar with Sass. This is the sort of stuff you can just create at once and never worry about it again, or even copy it from a gist, throw it into a mixins file, and then you're good to go for

This is the sort of stuff you can just create at once and never worry about it again, or even copy it from a gist, throw it into a mixins file, and then you're good to go for your project, even if you don't fully understand how everything works. Anyways, we now have this. So if we were to use it, well, let's get rid of all of this stuff here. And in fact, we'll come back to the modifier in a minute. OK, so we will call this mixin. We're calling this one item, I believe. And let's just say color red to have some styling to go along with it. OK, so we compiled it down.

has red color. And then you could do something similar for your modifier as well. So yeah, that stuff just comes down completely to you. But the underlying code will still be basically the same. OK, so that's been your review of the BEM syntax. This is not a law. You don't have to use it. It's just a convention. Some people like to use it. Some people prefer some other things.