The Vue.js documentation now has an official style guide in beta! The style guide is an excellent resource for avoiding errors, improving readability, consistency, and avoiding risky edge-case features when you don’t need them.
The purpose of this style guide isn’t necessarily enforcement of a specific style of writing JavaScript and is more focused on particular patterns (and avoiding anti-patterns) which will improve your Vue code. In summary, the guide’s goals are outlined as follows in the style guide introduction (emphasis added):
This is the official style guide for Vue-specific code. If you use Vue in a project, it’s a great reference to avoid errors, bikeshedding, and anti-patterns. However, we don’t believe that any style guide is ideal for all teams or projects, so mindful deviations are encouraged based on past experience, the surrounding tech stack, and personal values.
For the most part, we also avoid suggestions about JavaScript or HTML in general. We don’t mind whether you use semicolons or trailing commas. We don’t mind whether your HTML uses single-quotes or double-quotes for attribute values. Some exceptions will exist, however, where we’ve found that a particular pattern is helpful in the context of Vue.
The style guide rules are broken out into priorities from highest to lowest:
- Priority A: Essential
- Priority B: Strongly Recommended
- Priority C: Recommended
- Priority D: Use with Caution
Highlights
The following are some of the essential rules which stuck out that I am not following 100%, but feel could improve my Vue applications.
Multi-Word Component Names (Essential)
Using multi-word component names is an essential rule because existing and future HTML elements are all single-word. Further, my single word components tend to be overly generic and harder to read in code.
Bad
Vue.component('todo', { // ...})Good
Vue.component('todo-item', { // ...})Keyed v-for (Essential)
I wasn’t even aware of the :key prop until reading the style guide. Using key with v-for “is always required on components, to maintain internal component state down the subtree.” The guide also recommends using it with elements “to maintain predictable behavior such as object constancy in animations.”
Bad
<ul> <li v-for="todo in todos"> {{ todo.text }} </li></ul>Good
<ul> <li v-for="todo in todos" :key="todo.id" > {{ todo.text }} </li></ul>Read the official documentation for this rule.
Private Property Names (Essential)
For plugins and mixins, it’s an essential style rule to namespace your methods.
Bad
var myGreatMixin = { // ... methods: { $update: function () { // ... } }}Good
var myGreatMixin = { // ... methods: { $_myGreatMixin_update: function () { // ... } }}Read the official documentation for this rule.
Future Additions
The Vue style guide also mentions future additions on enforcement of styles through ESLint:
Soon, we’ll also provide tips for enforcement. Sometimes you’ll simply have to be disciplined, but wherever possible, we’ll try to show you how to use ESLint and other automated processes to make enforcement simpler.
I use the Airbnb style with ESLint (with some overrides), but I am also looking forward to additional updates to help enforce style where appropriate with ESLint.
Learn More
The Vue style guide will make the most sense to you after developing a couple of small applications. The style guide is a field manual for those with a working knowledge of Vue. I would suggest getting familiar with Vue by going through the guide.
Check out the Vue Style Guide.
