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
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
The root Vue node is also accessible using
$parent functionality tightly couples components together and makes debugging more difficult.
$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¶
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.
- 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
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
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";
If you are using PHPStorm or Webstorm, you can set the root directory by marking it as a
This will help the IDE resolve the absolute paths and also make it more intelligent when autocompleting paths.
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.