VueJS Best Practice Recommendations¶

Do not mutate props¶

In VueJS2.x, components can accept a range of props as a type of argument that can change how the component works. Examples of this could be an identification number, some raw data from an API response and so on.

VueJS relies heavily on an event driven system to handle the mutation of data passed through by props. This also ties in with how the v-model directive works and is covered by the one way data flow

If you want to make it possible to use v-model to bind data on your own components see here

Avoid using references (v-ref)¶

This bypasses the props and event architecture setup in Vue and is discouraged - it should only be used in edge cases

Avoid accessing $parent and $root¶

Parent components are accessible through $parent.

The root Vue node is also accessible using $root.

Using the $parent functionality tightly couples components together and makes debugging more difficult. Accessing the $root is also discouraged for the same reason and you should be using VueX if you want to have global state or a single source of truth.

Do not repeat yourself (DRY)¶

Like with other languages, do not repeat logic or components repeatedly, if you find that you are having to copy code frequently then you need to consider creating a new level of abstraction.

For example, if you find that you are repeatedly performing the same API requests manually in different components then you should move the API request logic to its own class so that it can be reused and tested.

Re-usable components are simple to create and can be visual components or even form inputs.

Avoid using watchers¶

Watchers are a special move that you should avoid where possible. It is almost always possible to achieve the same goals using computed properties.

If you find that you need to use watchers frequently it suggests you may need to re-evaluate how you have laid out your components.

Use libraries - avoid not invented here syndrome ¶

Quite often you may find what you are trying to create has been done by another developer already and has been open sourced. There are many libraries that bring useful re-usable components that can cut down on development time considerably.

For example:

Vuetify - Material design based components
AG Grid - Highly customisable grid rendering with Vue and TS support
Awesome Vue - Curated list of Vue libraries and components

Keep it strict¶

Strictly typing using Typescript where possible will help your IDE to understand your code better and makes it much easier for other developers to come on board to a project.

TS classes are very easy to create and give you good static analysis, they should always be used over standard JS classes where possible.

Organise your modules sensibly¶

There are many, many ways to organise code and the methodology used depends on the scale of a project. For small projects you can get away with scattering your components in the root of your js or src directory but should your project get larger then you will need to pay off this technical debt.

Also be sure to name your components sensibly, a name should not grow too large if you organise your code correctly.

Do not use relative imports¶

It is very tempting to use relative import paths

E.g:

import myclass from "./class"
import otherclass from "../someclass";

This may make refactoring more difficult if you decide you need to restructure your frontend application code.

So instead, your imports should become:

import myclass from "js/ns/class";
import otherclass from "js/someclass";

Note

If you are using PHPStorm or Webstorm, you can set the root directory by marking it as a src directory. This will help the IDE resolve the absolute paths and also make it more intelligent when autocompleting paths. You can also force absolute paths by turning off relative paths in the Codestyle of Javascript imports.

Warning

At the moment there is a bug in PHPStorm where the src directory will not persist. You will need to keep setting the path on each IDE start up.

Avoid global registration of components¶

Global components are available practically any where, this is useful for top level components such as page objects or may be forms but is far less useful for lower level components such as form inputs.

Where possible, you should register as you need them at the component level - not the global level.