how to write clean code in vuejs?

Cleaning the Vue

It has been about a month since joining a new IT company and have been enjoying the era a lot. When developing a service, developers often times disregard the importance of clean codes and following the proper conventions because of tight due times, lack of resources, and etc. However, clean code and following the conventions are important for several reasons.

1.Efficient in a team work for both readability and debugging

2. Using the frameworks/libraries in a intention of the creator to maximize of its pros

Therefore, I wanted to explore more on how to write clean codes in Vuejs and actually wanted to share some of the official style guides from the website with my thoughts.

Without further a due, lets dive into it

Must Dos

  • Combination Names

Because HTML elements are composed of single words, we need to combine names in order to avoid conflicts of other built-in HTML tags.

CombinationNames

Also for the readability!

  • Data must be a function

Data itself can be an object, and the application works flawlessly fine until you find something weird with javascript. With the object, when one instance changes its data, it is applied through all the instances created from the same component. Therefore, all the instances share the same data object. Therefore, having a function scope in the instance is resolving the issues.

  • using list (v-for) with key

when Vue renders v-for(list) in the dom, it uses a “in-place patch” strategy. This strategy basically mans that whenever there is a change in the v-for, instead of re-constructing the elements, it just detects the place of the element with unique id and changes corresponding data. In doing so, it saves the cost of rendering. Therefore, it is helpful to use v-for with key for Vue framework and also it is following the objects immutabilities of javascript.

  • never mix up v-if and v-for

When using v-for and v-if, Vue always prioritizes v-for over v-if and this will cause some performance issues.

bad example

Why is that a bad example? Because, vue when seeing a v-for and a v-if, will do v-for first and v-if. Above picture will work perfectly fine until the service takes several minutes(exaggerating) to load a data array. So instead, we should try to use computed to see if there exists any changes in the array, and if there is change, that should be the only instance to go through the v-if.

computed with already filtered array
  • Component Style Scope

A style should be scoped to its component. Styles in a top-level app component and in layout components may be global, but other components should always be scoped. This will make overriding internal styles easier, with human-readable class names that don’t have too high specificity, but are still very unlikely to result in a conflict.

  • Private property naming

Vue uses the _ prefix to define its own private properties, so using the same prefix will risk overwriting an instance property. Instead, use $_ to demonstrate that this is customized plugin or mixins with your plugin name. Ultimately, using $_yourPluginName would avoid conflicts.

Recommended for readabilities

readabilities come integral when writing applications because by the names, we can easily infer what the variables or components may fit in to the service. So Vue recommends several naming conventions to follow and let me go over them briefly.

  • Component File

Each component should be in its own file rather than having multiple components within a file

  • Single File Component Naming

Should be PascalCase or kebab-case. Pascal Case sometimes may cause issues on case-insensitive file systems, and therefore, kebab-cases can be useful

  • Base Component/Single Component/ tightly coupled Component name

Base component should start with prefix such as Base, App, and etc. Single component should start with The prefix to denote it is the only one. Those tightly coupled components should have parent component as a prefix.

  • Component Names Ordering

Component names should start with the highest-level words and end with descriptive modifiying words

  • Self Closing Component

Never in DOM templates but possibly in single-file components, string templates, and JSX if the component does not contain any contents.

  • Component names in Template

PascalCase is also used in javascript so can auto complete and it is more visually distinct. Unfortunately, due to HTML’s case insensitivity, DOM templates must still use kebab-case.(for the reason above)

  • Component names in Js/JSX

Should be PascalCase because in Javascript, it is the convention for classes and prototype constructors. Anything with the distinct instances should be PascalCase.

  • prop names

prop names should always use camelCase during declaration, but kebab-case in templates and JSX.

  • directives usages

elements with multiple attributes should span multiple lines, with one attribute per line.

Wrap up

As a junior developer striving to become a better junior developer(may be one day, a senior developer….), I think the important thing about building a service is not about using how many frameworks and different languages with various combinations of architectures that you can come up with, instead, the focus should be on how to build one “great” service that needed some thoughts and efforts. Of course, we disregard all the above points and build a service without any problems. However, as mentioned, I believe building a service requires a huge team work and different perspectives of various people are much appreciated. Preparing for the increased teamwork efficiency, these styles guides should, actually must, be taken care of and in that way, I think we can all build a close to a great (better) service.

Hello, I am a software engineer in Tokyo. Any technical discussions are welcome so please contact me at jgam@alumni.nd.edu