Vue is an easy front end framework to work with. It lets us create apps easily.
However, there are still many things that we should look out for when we write apps with them.
In this article, we’ll look at the best practices for using the recommended syntax.
Attribute Hyphenation
We can hyphenate our attributes so that it’s consistent with HTML attributes.
For instance, we can write:
<FooComponent foo-prop="prop" />
instead of:
<FooComponent fooProp="prop" />
Component Name Casing
Names for components should be PascalCase or kebab case.
Vue can translate between either case.
For instance, we can write:
<FooComponent />
or:
<foo-component />
Closing HTML Brackets in a New Line
Having closing HTML brackets in a new line makes it easier to change and read.
Therefore, we may consider putting them on a new line.
For instance, we can write:
<div
id="foo"
class="bar"
>
<!-- //... -->
</div>
instead of writing:
<div
id="foo"
class="bar">
<!-- //... -->
</div>
No Space Before Closing Bracket Tags
We shouldn’t have space before closing bracket tags.
For instance, we shouldn’t have:
<div ></div>
Instead, we write:
<div></div>
HTML End Tags
We should have end tags for non-self-closing tags.
For instance, we should write:
<div></div>
instead of:
<div>
Indentation
We should have some indentation in our HTML.
It makes the code easier to read and change.
For instance, we can write:
<div class="bar">
Hello.
</div>
Quotes
Quotes should be added to HTML attribute values.
For instance, we can write:
<img src="./photo.png">
or:
<img src='./photo.png'>
Single or double quotes are both fine.
This way, we won’t have syntax errors when we’re passing props instead of setting HTML attribute values.
Self-Closing Tags
If a component doesn’t have any content, it can either be self-closing or not.
The self-closing syntax isn’t supported in HTML spec, so we shouldn’t use it when we’re writing Vue code without a build step.
For instance, we can write:
<BarComponent></BarComponent>
which isn’t self-closing or:
<BarComponent />
which is self-closing.
Maximum Number of Attributes Per Line
We don’t want to have so many attributes in a line that people have to scroll horizontally to read everything.
Therefore, we may want to limit the attributes in one line.
For instance, we may want to have one attribute per line, so we write:
<FooComponent
foo="1"
bar="2"
baz="3"
/>
HTML Content Newline
HTML content should be in its own line in between the tags.
This way, we know where the content exactly is without looking too hard.
For instance, we can write:
<div>
multiline
content
</div>
Mustache Interpolating Spacing
We should have some space between the mustache and the expression that’s inside it.
It’s easier to read if we have one space character before and after the expression.
For instance, we can write:
<div>{{ msg }}</div>
This way, the expressions are easy to find.
No Multiple Spaces
Having a bit of space is good, but we shouldn’t have too many spaces since it’s just a waste of screen real estate.
For instance, the following is good”
<i
:class="{
'fa-angle-up': isExpanded,
'fa-angle-down': !isExpanded,
}"
/>
There’s one space after the colon, which is enough to make the keys and value easy to read.
No Spaces Around Equal Signs in Attribute
HTML5 allows space around equal signs, but it’s easier to read without the spaces and they’re grouped better without the spaces.
Therefore, we write:
<div class="foo"></div>
instead of:
<div class = "foo"></div>
No Template Variable Shadowing
We shouldn’t have variable declarations in a nested element or component that’s identical to the variable declaration in the outer element or component.
For instance, we shouldn’t have something like the following:
<div>
<div v-for="x in 5">
<div v-for="x in 10"></div>
<div slot-scope="{ x }"></div>
</div>
</div>
We have x that’s both declared in the outer v-for and the inner one.
That will just confuse Vue and ourselves.
We should name them differently and reduce nesting whenever possible.
So we should write:
<div>
<div v-for="a in 5"></div>
<div v-for="b in 10"></div>
</div>
Conclusion
There are lots of syntax errors that we should avoid in templates.
Also, the formatting of the attributes can be better by sticking to spacing and indentation conventions.
