When it comes to naming and defining our components, sometimes things can get a little bit messy. That's why the Vue Core team has provided us with a nice style guide to give us some patterns to follow when creating our components. It simply helps keep things predictable and consistent, and it means that other developers can easily understand our application just by looking at the component file names and can easily navigate through the component definitions. We're not going to look at every single one of the rules in this style guide, but we are definitely going to take a look at the highest priority ones for components and then hit a few of the highlights in a couple other categories.
So here we have four different priorities recommended. The first one is the most essential. These are defined in order to keep you from having errors in your app. All the others are just recommended with various levels of recommendation here.
to keep things consistent. Okay, great. So let's look at the essential rules. The first one is one we already discussed earlier on.
That is, all of our component names should be multi-worded. This is going to prevent conflicts with existing and future HTML elements, since all HTML elements are a single word. So make sure you're always using two words to name your components. When you're working with a build tool like Vite, as we're doing, you should probably also prefer PascalCase.
If you're using indom templates, which we haven't done and really isn't the best way to work with you, you would have to do the dash case instead. Another nice rule here is to use your detailed prop definition syntax. We saw earlier on that you can use an array to define your prompts. What would be better though is at least providing the type of each of your props, and even better is providing all the other options here as well, such as Require, Default, and maybe even a Custom Validator.
I will admit, I don't always provide a Custom Validator. In fact, I tend to do it less than I omit it. But for some instances, it's really handy. Okay, as far as components are concerned, that's really all that's inside of the Essential category.
Let's briefly take a look at some of the rules inside of strongly recommended here. Scrolling down just a bit in this document, the second rule we come to is single file component file name casing. What we should be doing when we name our single file components, those dot view files, is using Pascal case like this. That is the first letter capitalized and then the first letter capitalized of any subsequent word.
So this is Pascal case. This is good. or doing a dashed case where dashes separate your words. And of course, be consistent with whichever version you choose for your project.
Don't mix and match these in the same project. Choose one and stick with it. So not having any differentiation between words like this would be bad, and not doing Pascal case where the M is lowercase at the beginning here would also be bad. It's not a breaking thing, it just breaks the style guide.
Another really good idea is to prefix all of your base components with the word base, app, or v. Your base components are the most foundational components of your app. They're the components put together to make up all the other components of your app. Things like buttons, things like an image component, things like a form input component, and so on.
So here is the example of it being bad. There's just no consistency here, no prefix at all. Instead what is good is providing some kind of consistent prefix. There are quite a few other component rules here as well.
I encourage you to go and read them for yourself in the docs. When it comes to naming and defining our components, sometimes things can get a little bit messy. That's why the Vue Core team has provided us with a nice style guide to give us some patterns to follow when creating our components. It simply helps keep things predictable and consistent, and it means that other developers can easily understand our application just by looking at the component file names and can easily navigate through the component definitions.
We're not going to look at every single one of the rules in this style guide, but we are definitely going to take a look at the highest priority ones for components and then hit a few of the highlights in a couple other categories. So here we have four different priorities recommended. The first one is the most essential. These are defined in order to keep you from having errors in your app.
All the others are just recommended with various levels of recommendation here. to keep things consistent. Okay, great. So let's look at the essential rules.
The first one is one we already discussed earlier on. That is, all of our component names should be multi-worded. This is going to prevent conflicts with existing and future HTML elements, since all HTML elements are a single word. So make sure you're always using two words to name your components.
When you're working with a build tool like Vite, as we're doing, you should probably also prefer PascalCase. If you're using indom templates, which we haven't done and really isn't the best way to work with you, you would have to do the dash case instead. Another nice rule here is to use your detailed prop definition syntax. We saw earlier on that you can use an array to define your prompts.
What would be better though is at least providing the type of each of your props, and even better is providing all the other options here as well, such as Require, Default, and maybe even a Custom Validator. I will admit, I don't always provide a Custom Validator. In fact, I tend to do it less than I omit it. But for some instances, it's really handy.
Okay, as far as components are concerned, that's really all that's inside of the Essential category. Let's briefly take a look at some of the rules inside of strongly recommended here. Scrolling down just a bit in this document, the second rule we come to is single file component file name casing. What we should be doing when we name our single file components, those dot view files, is using Pascal case like this.
That is the first letter capitalized and then the first letter capitalized of any subsequent word. So this is Pascal case. This is good. or doing a dashed case where dashes separate your words.
And of course, be consistent with whichever version you choose for your project. Don't mix and match these in the same project. Choose one and stick with it. So not having any differentiation between words like this would be bad, and not doing Pascal case where the M is lowercase at the beginning here would also be bad.
It's not a breaking thing, it just breaks the style guide. Another really good idea is to prefix all of your base components with the word base, app, or v. Your base components are the most foundational components of your app. They're the components put together to make up all the other components of your app.
Things like buttons, things like an image component, things like a form input component, and so on. So here is the example of it being bad. There's just no consistency here, no prefix at all. Instead what is good is providing some kind of consistent prefix.
There are quite a few other component rules here as well. I encourage you to go and read them for yourself in the docs.