Vue style guide

Refer to Vue.js component style guide on Github

Module based development

Always construct your app out of small modules which do one thing and do it well. A module is a small self-contained part of an application. The Vue.js library is specifically designed to help you create view-logic modules. Each Vue component (like any module) must be FIRST: Focused (single responsibility), Independent, Reusable, Small and Testable.

Vue Component Names

Each component name must be meaningful, short and pronounceable.

• Meaningful: not over specific, not overly abstract.
• Short: 2 or 3 words.
• Pronounceable: we want to be able talk about them.

Keep component expressions simple

Vue.js’s inline expressions are 100% Javascript. This makes them extremely powerful, but potentially also very complex. Therefore you should keep expressions simple. Instead, move it to methods or computed properties if it gets too complex or hard to read.

Keep component props primitive

While Vue.js supports passing complex JavaScript objects via these attributes, you should try to keep the component props as primitive as possible. Try to only use JavaScript primitives (strings, numbers, booleans) and functions. Avoid complex objects.

Harness your component props

In Vue.js your component props are your API. A robust and predictable API makes your components easy to use by other developers.

Assign this to component

Within the context of a Vue.js component element, this is bound to the component instance. Therefore when you need to reference it in a different context, ensure this is available as component. In other words: Do NOT code things like var self = this; anymore if you’re using ES6. You’re safe using Vue components.

Component structure

Make it easy to reason and follow a sequence of thoughts

• Having the component export a clear and grouped object, makes the code easy to read and easier for developers to have a code standard.
• Alphabetizing the properties, data, computed, watches, and methods makes them easy to find.
• Grouping makes the component easier to read (name; extends; props, data and computed; components; watch and methods; lifecycle methods, etc.)
• Use the name attribute
• Use a CSS naming Methodology, like BEM
• Use the template-script-style .vue file organization

Component event names

Vue.js provides all Vue handler functions and expressions are strictly bound to the ViewModel. Each component events should follow a good naming style that will avoid issues during the development.

• Event names should be kebab-cased.
• A unique event name should be fired for unique actions in your component that will be of interest to the outside world.
• Events should either end in verbs in the infinitive form (e.g. client-api-load) or nouns (e.g drive-upload-success).

Avoid this.$parent

Vue.js supports nested components which have access to their parent context. Accessing context outside your vue component violates the FIRST rule of component based development. Therefore you should avoid using this.$parent.

• Pass values from the parent to the child component using attribute/properties.
• Pass methods defined on the parent component to the child component using callbacks in attribute expressions.
• Emit events from child components and catch it on parent component.

Use this.$refs with caution

Vue.js supports components to have access to other components and basic HTML elements context via ref attribute. That attribute will provide an accessible way through this.$refs to a component or DOM element context. In most cases, the need to access other components context via this.$refs could be avoided. This is why you should be careful when using it to avoid wrong component APIs.

• Create a good component API.
• Always focus on the component purpose out of the box.
• Never write specific code. If you need to write specific code inside a generic component, it means its API isn’t generic enough or maybe you need a new component to manage other cases.
• Check all the props to see if something is missing. If it is, create an issue or enhance the component yourself.
• Check all the events. In most cases developers forget that Child-Parent communication (events) is needed, that’s why they only remember the Parent-Child communication (using props).
• Props down, events up! Upgrade your component when requested with a good API and isolation as goals.
• Using this.$refs on components should be used when props and events are exhausted and having it makes sense (see the example below).
• Using this.$refs to access DOM elements (instead of doing jQuery, document.getElement*, document.queryElement) is just fine, when the element can’t be manipulated with data bindings or for a directive.

Use component name as style scope

Vue.js component elements are custom elements which can very well be used as style scope root. Alternatively the component name can be used as CSS class namespace.
Use the component name as a namespace prefix based on BEM and OOCSS and use the scoped attribute on your style class. The use of scoped will tell your Vue compiler to add a signature on every class that your

Document your component API

A Vue.js component instance is created by using the component element inside your application. The instance is configured through its custom attributes. For the component to be used by other developers, these custom attributes - the component’s API - should be documented in a README.md file.

Lint your component files

Linters improve code consistency and help trace syntax errors.

Create components when needed

• Always remember to build your components for your project needs, but you should also try to think of them being able to work out of it. If they can work out of your project, such as a library, it makes them a lot more robust and consistent
• It’s always better to build your components as early as possible since it allows you to build your communications (props & events) on existing and stable components.

* Rules *

• First, try to build obvious components as early as possible such as: modal, popover, toolbar, menu, header, etc. Overall, components you know for sure you will need later on. On your current page or globally.
• Secondly, on each new development, for a whole page or a portion of it, try to think before rushing in. If you know some parts of it should be a component, build it
• Lastly, if you’re not sure, then don’t! Avoid polluting your project with “possibly useful later” components, they might just stand there forever, empty of smartness. Note it’s better to break it down as soon as you realize it should have been, to avoid the complexity of compatibility with the rest of the project