When it comes to naming our components, things can get messy. That's why the view team provides us with a style guide to help us name our components in the best possible way while following some patterns. This also makes it easy for other developers to understand the application structure just by taking a look at the component files. The rules are divided into sections based on their importance.
Most of the rules use single file components in the examples, which is something we haven't covered yet. Don't worry though, the rules are the same for all types of components. Let's see what we have in the top priority rules. Component names should always be multi-worded, except for root app components and built-in components provided by Vue, such as transition or component.
This prevents conflicts with existing and future HTML elements, since all HTML elements are single word, like button element, table, text area, etc. So, instead of naming a component toDo, we should name it something like toDo-item. This is a rule we don't follow in the plan picker example, because we have named our component Plan, which is a single word. Let's rename it to Plan Item because we are registering the component locally inside of Plan Picker.
The property name is also the name of the component. We can name it either Plan Item, like this, or with a dash. If you want to use the second option, notice that you should wrap it in quotes to support the hyphen. Cool.
Once we've renamed the component, we can also rename the variable to make the name clear. Let's update the HTML as well to use the new component tag. And everything still works. Next, we have the base component names.
Base components are the ones that apply app-specific styling and conventions. For example, a base component could be a button or an input. that is used globally in our application. These component names should start with a prefix like base, app, or v.
Here, we see why the multi-word rule is so important, since the button and input elements are reserved HTML tags. So, we always have to use a prefix. We don't have any base components so far, but Keep it in mind and come back when you have some. Next, we have the single instance components.
These components will only have a single instance active, and they should always begin with the. For example, a website might only have one sidebar on any given page, so we can name the component the sidebar. The next rule is my favorite. and it's about having tightly coupled component names.
This means that if a component only makes sense in the context of its parent component, that relationship should be clear in its name. Since editors typically organize files alphabetically, this also keeps these related files next to each other. In the example here, we have some bad component names. We have a to-do list.
a To Do item, and a To Do button. To make these components follow the rule, we need to make their relationship clear in their names. View. This might look a little verbose at first glance, but It makes perfect sense if you think about it.
The To Do List Item button will never be used outside of the To Do List Item component. I bet you didn't know that when you saw the bad example. But now, this relationship is straightforward. Does this remind you of something?
This is exactly the case in our Plan Picker. The Plan Item component only makes sense inside of the Plan Picker. So, we need to make that clear. Thus, instead of calling it Plan Item, we will call it Plan Picker Item, and problem solved.
Now, we should also update the template ID to reflect the new component name, and update the CSS selector. Cool. Lastly, let's update the component tag in the template, and we'll check it out in the browser. The next rule is about the order of words and component names.
The component names should start with the most general words and end with descriptive modifying words. In this bad example, we have a list of components that are related to the search. We have, for instance, clear search button, run search button, etc. Here, the most general word is search.
because it doesn't describe the component itself, but the general functionality where it's used. This means that all these names should begin with search. Here, we also have two components that are related to the settings. Terms Checkbox and Launch on Startup Checkbox.
When we name these components properly, they will both begin with settings. and then the second most generic word, which is the checkbox. So these components will eventually be named Settings Checkbox Terms and Settings Checkbox Launch on Startup. And now they're grouped together in the file system.
The last rule on component names is about using full words. This rule is quite simple. and it recommends that we use full words instead of abbreviations or shorthands. So, instead of naming a component SD Settings, we should name it Student Dashboard Settings to make them easily understandable for us and our colleagues.
These are the rules, my friends. Some of them might feel unnatural in the beginning, but they're here to make our lives easier, so I encourage you to embrace them. They are not laws, so you could bypass a few of them, though do that only if you have a good reason, and if you really know what you are doing. When it comes to naming our components, things can get messy.
That's why the view team provides us with a style guide to help us name our components in the best possible way while following some patterns. This also makes it easy for other developers to understand the application structure just by taking a look at the component files. The rules are divided into sections based on their importance. Most of the rules use single file components in the examples, which is something we haven't covered yet.
Don't worry though, the rules are the same for all types of components. Let's see what we have in the top priority rules. Component names should always be multi-worded, except for root app components and built-in components provided by Vue, such as transition or component. This prevents conflicts with existing and future HTML elements, since all HTML elements are single word, like button element, table, text area, etc.
So, instead of naming a component toDo, we should name it something like toDo-item. This is a rule we don't follow in the plan picker example, because we have named our component Plan, which is a single word. Let's rename it to Plan Item because we are registering the component locally inside of Plan Picker. The property name is also the name of the component.
We can name it either Plan Item, like this, or with a dash. If you want to use the second option, notice that you should wrap it in quotes to support the hyphen. Cool. Once we've renamed the component, we can also rename the variable to make the name clear.
Let's update the HTML as well to use the new component tag. And everything still works. Next, we have the base component names. Base components are the ones that apply app-specific styling and conventions.
For example, a base component could be a button or an input. that is used globally in our application. These component names should start with a prefix like base, app, or v. Here, we see why the multi-word rule is so important, since the button and input elements are reserved HTML tags.
So, we always have to use a prefix. We don't have any base components so far, but Keep it in mind and come back when you have some. Next, we have the single instance components. These components will only have a single instance active, and they should always begin with the.
For example, a website might only have one sidebar on any given page, so we can name the component the sidebar. The next rule is my favorite. and it's about having tightly coupled component names. This means that if a component only makes sense in the context of its parent component, that relationship should be clear in its name.
Since editors typically organize files alphabetically, this also keeps these related files next to each other. In the example here, we have some bad component names. We have a to-do list. a To Do item, and a To Do button.
To make these components follow the rule, we need to make their relationship clear in their names. View. This might look a little verbose at first glance, but It makes perfect sense if you think about it. The To Do List Item button will never be used outside of the To Do List Item component.
I bet you didn't know that when you saw the bad example. But now, this relationship is straightforward. Does this remind you of something? This is exactly the case in our Plan Picker.
The Plan Item component only makes sense inside of the Plan Picker. So, we need to make that clear. Thus, instead of calling it Plan Item, we will call it Plan Picker Item, and problem solved. Now, we should also update the template ID to reflect the new component name, and update the CSS selector.
Cool. Lastly, let's update the component tag in the template, and we'll check it out in the browser. The next rule is about the order of words and component names. The component names should start with the most general words and end with descriptive modifying words.
In this bad example, we have a list of components that are related to the search. We have, for instance, clear search button, run search button, etc. Here, the most general word is search. because it doesn't describe the component itself, but the general functionality where it's used.
This means that all these names should begin with search. Here, we also have two components that are related to the settings. Terms Checkbox and Launch on Startup Checkbox. When we name these components properly, they will both begin with settings.
and then the second most generic word, which is the checkbox. So these components will eventually be named Settings Checkbox Terms and Settings Checkbox Launch on Startup. And now they're grouped together in the file system. The last rule on component names is about using full words.
This rule is quite simple. and it recommends that we use full words instead of abbreviations or shorthands. So, instead of naming a component SD Settings, we should name it Student Dashboard Settings to make them easily understandable for us and our colleagues. These are the rules, my friends.
Some of them might feel unnatural in the beginning, but they're here to make our lives easier, so I encourage you to embrace them. They are not laws, so you could bypass a few of them, though do that only if you have a good reason, and if you really know what you are doing.