Nuxt

Introduction

This is a guide to maintain a consistent and industry stand code in Nuxt.

Naming conventions

Components

• Components names should be short, describes what it's intended use is and is in PascalCase

Bad Examples

fileUpload.vue
file_upload.vue
FileUploadComponent.vue
file-upload.vue

Correct Example

FileUpload.vue

Variables

• Variable names must be short, descriptive and in snake_case. Bad Examples

let selectedVariables
let sItem 
let item1
let SelectedItem

Correct Example

let selected_item

• For boolean variables names should be in passive voice verb question forms

Bad Examples

let loading = false;
let pageLoading = false;
let loaded = false;
let loadingFlag = false;
let loading_flag = false;

Good Example

let is_loading = false;

Use kebab-case for events

When it comes to emitting custom events, it’s always best to use kebab-case. This is because in the parent component, that’s the same syntax we use to listen to that event. So for consistency across our components, and to make your code more readable, stick to using kebab-case in both places.

Example

PopupWindoe.vue

this.$emit("close-window");

ParentComponet.vue

<template>
<popup-window @close-window='handleEvent()' />
</template>

Declare props with camelCase and use kebab-case in templates

This best practice simply just follows the conventions for each language. In JavaScript, camelCase is the standard and in HTML, it’s kebab-case Therefore, we use them accordingly. Luckily for us, VueJS converts between kebab-case and camelCase for us so we don’t have to worry about anything besides actually declaring them. In JavaScript, camelCase is the standard and in HTML, it’s kebab-case Therefore, we use them accordingly.

<template>
  <PopupWindow title-text="hello world" />
</template>
<script>
export default {
  props: {
    titleText: String,
  },
}
</script>

Components folder

• All page related exclusive components should be in the page's component folder
• Any component that can be reused should be in the Vue folder's component directory.

Prefer using Composition API

• Vue 3 and Nuxt 3 major development moving forward will be using Composition API, so it is recommended to prefer using Composition over Options API

Always key use inside v-for

Using the key attribute with the v-for directive helps your application be constant and predictable whenever you want to manipulate the data. This is necessary so that Vue can track your component state as well as have a constant reference to your different elements. An example where keys are extremely useful is when using animations or Vue transitions. Without keys, Vue will just try to make the DOM has efficient as possible. This may mean elements in the v-for may appear out of order or their behavior will be less predictable. If we have a unique key reference to each element, then we can better predict how exactly our Vue application will handle DOM manipulation.

Bad Example

<template>
  <div v-for="product in products">{{ product }}</div>
</template>

*Good Example

<template>
  <div v-for="product in products" :key="product.id">{{ product }}</div>
</template>

Don’t use v-if with v-for elements

It’s super tempting to want to use v-if with v-for in order to filter elements of an array. The problem with this is that VueJS prioritizes the v-for directive over the v-if directive. So under the hood, it loops through every element and THEN checks the v-if conditional. This means that even if we only want to render a few elements from a list, we’ll have to loop through the entire array. This is no good.

A smarter solution would be to iterate over a computed property. The above example would look something like this. This means that even if we only want to render a few elements from a list, we’ll have to loop through the entire array.

Bad Example

<div
   v-for='product in store.products'
   v-if='product.price < 500'
>

Good Example

<template>
  <div v-for="product in store.products">{{ product }}</div>
</template>
<script setup>
const cheap_products = computed(() => {
  store.products.filter(product => product.price < 500);
};
</script>

Validate your props with good definitions

It basically saves future you from current you. When designing a large scale project, it’s easy to forget exactly the exact format, type, and other conventions you used for a prop. And if you’re in a larger dev team, your coworkers aren’t mind-readers so make it clear to them how to use your components! So save everyone the hassle of having to painstakingly trace your component to determine a prop’s formatting and please just write prop validations.

Bad Example

const props = defineProps(['status'])

Good Example

const props = defineProps({
    status: {
        type: String,
        required: true,
        validator: function (value) {
            return (
                ['syncing', 'synced', 'version-conflict', 'error'].indexOf(value) !==
                -1
            )
        },
    }
})