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
- 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.
Also for the readability!
- Data must be a function
- using list (v-for) with key
- 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.
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.
- 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
- Component names in Js/JSX
- 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.
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.