Component Naming Conventions

[00:00:00]
>> Let's kick it off to talk about components which really are the life and blood of most front end applications these days. This is why frameworks have become so popular. It's because when we have applications that are large, we need ways to break it down into smaller pieces so that they're easier to maintain.

[00:00:15]
But of course the question is at scale, what are some call it best practices and ideas that might help you better manage your components. Let's start with the very basics which is when it comes to naming your components, here are some conventions that I recommend. So there's a great Drake meme where you can see at the very top, he's like, What I don't wanna do which is in this case it's actual programming.

[00:00:39]
Whereas debating how to name a variable for 30 minutes is something that we often have probably encountered as far as bike shedding and those sort of things. So as far as best practice goes, generally speaking, avoid using single word components when it comes to naming your components. So whether it's header, button is the most egregious version of this.

[00:01:04]
And the reason why for this is quite simple. It's because we want to try and avoid conflicts with basically standard HTML5 spec. While you might say that although sometimes we're using Pascal case very consistently, like it's just better to avoid these sort of things in order to provide that sort of alignment with the HTML5 spec.

[00:01:24]
Which vue actually tries to do a lot as well because we want to allow you to leverage what you already know. And then build on top of that rather than having you to learn something totally different. So an example of this would be like filter which is the functionality in vue two, uses that pipe symbol.

[00:01:42]
And so one of the reasons it is been deprecated from vue 3 while it's some people did support sort of they like using it is because the JavaScript is actually thinking about implementing their own single pipe operator in order to do something. There's a whole spec on that.

[00:01:57]
But basically, this means now that if you were to keep the single pipe operator as like standard view syntax, now there will always be that question of is this the vue single pipe operator or is this the JavaScript single pipe basically operator. And so in this regard, this is one of the reasons why like whenever we pretending everything like v dash for the directives and like the sort of the events as well, so that it's very clear what's coming from vue and what's not.

[00:02:25]
And so just like this, even if you're using Pascal case for your components, please just avoid single word components as much as humanly possible. And so instead we recommend basically prefixing it with some sort of like indicator whether it's an app. And especially the most common one that's used especially when you're doing things like inputs and like you're trying to read like you're simply wrapping an existing HTML element.

[00:02:49]
Then calling it base is a really common way of basically naming your components in a way that makes it very clear that, hey, this is a base button, right? It's like it's basically the button element, but this is like this is coming from the vue side. This is coming from developers who have defined it differently than what is being provided by the browser natively.

[00:03:09]
And so you can see examples of this include AppButton, AppModal, BaseDropdown, BaseInput. These are ways to sort of take care of those scenarios where you might want to typically just use one word, add that base to it. It'll make your life a lot easier when you're scaling your application long term.

[00:03:27]
In any instance where you have single instance components where basically you can only have one on the page at any given time. It's actually one of the sort of advice I can provide you is to prefix it with The instead. So in this case, you can see like example of this include TheShoppingCart, TheSidebar, TheNavbar.

[00:03:46]
The reason for this is just because while it's not gonna do anything at compile time, there is something about that developer ergonomic when like if you're rendering something that sort of has that small little bit of a red flag. That's like, I'm running a V4 loop on the shopping cart.

[00:04:01]
Like that's a little weird. And so when people see multiple instances, that can be basically a red flag for either one. They shouldn't be existing on the same page. Or two, if you're like, no, no, no, we actually can have multiple shopping carts. This also is a great way of indicating maybe it's time to refactor to something more generic rather than or even renaming it entirely.

[00:04:23]
So a nice way of communicating there should only be one without sort of clogging up your bill tools. And so in addition to this when it comes to naming components, we strongly recommend trying to name the tightly coupled and related components together in a way that strings it over time.

[00:04:44]
So there are a lot of benefits to this as far as not only being able to easily spot that relationship, but when it comes to the file tree and sort of like reading it out, you can see that they're nested right next to each other. And then you always get that like consistency as far as what to expect.

[00:04:59]
So in our example here, you can see that we have a ToDoList component and then we have a ToDoListItem component and then if you wanna go even further, we could have TodoListItemName. Now some of you may be thinking, well, that names kind of long. But again, one with autocomplete these days long names shouldn't be like we're not actually typing more as far as like autocompletion and those things.

[00:05:19]
But more importantly, the reason this is important is because this allows you to designate to other developers that this item should really be used in this context, right? And so if you see a ToDoList show up in a shopping cart, that's gonna be weird just based on that naming structure alone.

[00:05:37]
Whereas if you did something generic like list item, you're more prone to see people just sort of reusing components in places where it probably wasn't meant to be. And then what you might end up getting to is that with an architecture that scales and developers working on different pieces at different times, people will start cramming functionality that might not be related to even to do this item.

[00:05:55]
But because we call that list item and someone's like, yeah, that's kind of what I needed. And then they use that, you're gonna end up with just basically conflicts over time. And so the better thing to do is just to like what I had to do too, you get used to the long name.

[00:06:08]
And then as a benefit too, you'll see that if you find that to do this item for example is starting to be like some functionality is so generic that to do list item, shopping cart item. And those things are starting to be so related that you're like they really should be refactored, then that is a great time to maybe create a base list item component that then extends into to do list item and shopping cart item.

[00:06:31]
And that way you can still scope your functionality in a way that again doesn't clog up build tools, but it makes it very declarative to developers going forward. They are like yeah, all this stuff we take the base list component and then we extend on to do functionality and again, it should only be used in the to do list context and versus the same thing with shopping cart, right?

[00:06:51]
Base list item extended with shopping cart functionality. And then you get that shareability but without like the complication of being like which list item are you referring to? So this one I highly recommend trying out for especially as applications grow in scale. Okay, Naming Component Methods. This is something that there's some debate about but in general, when it comes to defining like the callback function, right?

[00:07:20]
When the user clicks on something, what am I gonna call that function? It's tempting to say things like the event on click, okay? Well at click equals on click, right? And then I'll call my method on click. But generally speaking, this is we're basically prescribing how like in the name, we're prescribing how it works, when in reality what we want to do is use a descriptive name that provides context.

[00:07:42]
So on input doesn't tell us anything besides the fact that it's gonna trigger on input, except that's already told to us because we already have that V on input happening. So it's a redundancy and doesn't provide additional context. Whereas if we use something like update username for example, that tells us instantly what we're attaching it to.

[00:08:01]
More importantly, overall you can't assume that the event will be like that method will be called in that place. Because now if you called on input equals on input, in the event or some other event that's going to trigger the same thing. Now you're gonna be stuck in that position where well technically it's not on input anymore.

[00:08:17]
Now it's on click. So what are we gonna do? And so to skip the headache entirely, it's better to just use those descriptive name that not only provide context but it basically just a little bit of documentation to developers who are gonna come to the code base and have a better understanding of what's happening.

[00:08:33]
And so yep, those are the key things I want you to take away from the slide. And then this is more of a generic JavaScript thing but again worth mentioning because over time when it comes to scaling your methods, for example, when as we have multiple arguments inside of our methods, so in this case update user, right?

[00:08:55]
We have userList index value is online. All of these are different things that matter to our method. But this is a lot for developers especially who if you weren't the one who wrote it or frankly even if you wrote it cuz I don't know about you, I've forgotten multiple times what order things come in.

[00:09:10]
It's hard to use that because if you're trying to use this method in other places, now you have to be like was it userList, item, value? I actually got it right this time, usually I get it wrong. But rather than doing it this way, it's recommended instead to do it with the destruction method.

[00:09:27]
So as you can see on the top, we just have it listed out where it's a fixed order. And then by simply creating an object around it, this allows users to actually define what they're looking for and not have to remember that like if I don't need user list I have to define all here and then going forward.

[00:09:44]
So just a quick JavaScript tip for just creating methods that are easier to use and basically have a more accessible API for new developers who aren't used to using certain signatures. So yeah, so we can see here that it's broken down into our four elements which then basically allows us to say recommend using the destructuring arguments over multiple arguments