home / skills / serkodev / vue-skills / vue-best-practices

vue-best-practices skill

/skills/vue-best-practices

This skill helps you apply Vue.js best practices across projects, guiding composition API usage, SFC structure, and data flow for maintainable apps.

npx playbooks add skill serkodev/vue-skills --skill vue-best-practices

Review the files below or copy the command above to add this skill to your agents.

Files (5)
SKILL.md
2.6 KB
---
name: vue-best-practices
description: A collection of best practices and tips for developing applications using Vue.js. This skill MUST be apply when developing, refactoring or reviewing Vue.js or Nuxt projects.
license: MIT
metadata:
    author: SerKo <https://github.com/serkodev>
    version: "0.1"
compatibility: Requires Vue 3 (or above) or Nuxt 3 (or above) project
---

# Vue.js Best Practices

## Tasks Checklist

- [ ] Followed the core principles
- [ ] Followed the defaults unless there is a good reason not to
- [ ] Followed the reactivity best practices
- [ ] Followed the component best practices
  - [ ] Followed the Vue SFC best practices
  - [ ] Kept components focused
    - [ ] Split large components into smaller ones when needed
    - [ ] Moved state/side effects into composables if applicable
  - [ ] Followed data flow best practices

---

## Core Principles
- **Keep state predictable:** one source of truth, derive everything else.
- **Make data flow explicit:** Props down, Events up for most cases.
- **Favor small, focused components:** easier to test, reuse, and maintain.
- **Avoid unnecessary re-renders:** use computed properties and watchers wisely.
- **Readability counts:** write clear, self-documenting code.

## Defaults (unless the user says otherwise)

- Prefer the **Composition API** over the Options API.

## Reactivity

IMPORTANT: You MUST follow the `references/reactivity-guide.md` for reactive state management when creating, updating a component or a composable.

## Components

IMPORTANT: You MUST follow the `references/sfc-guide.md` for best practices when working with Vue SFCs.

- Prefer Vue Single-File Components (SFC) using **`<script setup lang="ts">`** (TypeScript) by default.
- In Vue SFCs, keep sections in this order: `<script>` → `<template>` → `<style>`.

### Keep components focused

Split a component when it has **more than one clear responsibility** (e.g. data orchestration + UI, or multiple independent UI sections).

- Prefer **smaller components + composables** over one “mega component”
- Move **UI sections** into child components (props in, events out).
- Move **state/side effects** into composables (`useXxx()`).

NOTE: This rule also applies to the entry component (e.g. App.vue) in a Vue / Nuxt project by default.

### Data Flow

IMPORTANT: You MUST follow the `references/data-flow-guide.md` for passing and receiving data between components using:
- Props
- Emits
- `v-model`
- provide/inject

For sharing data across the app, please follow the `references/state-management-guide.md` and consider using a Store for state management solution.

Overview

This skill provides a compact, opinionated set of best practices for developing, refactoring, and reviewing Vue.js and Nuxt projects. It emphasizes predictable state, explicit data flow, focused components, and the Composition API with TypeScript-ready Single-File Components. Use it to guide architecture decisions, code reviews, and incremental refactors.

How this skill works

The skill inspects code and design choices against core principles: single source of truth for state, props-down/events-up data flow, and component responsibility boundaries. It enforces defaults such as Composition API and <script setup lang="ts"> SFCs, recommends splitting large components, and moves shared logic into composables or a store. It also ensures reactivity and data-flow patterns follow established guides for safe updates and predictable behavior.

When to use it

  • Starting a new Vue or Nuxt project to set consistent conventions
  • Refactoring large components into smaller, testable parts
  • Performing code reviews focused on state, reactivity, and data flow
  • Implementing cross-component state or shared logic with composables or a store
  • Migrating Options API codebase toward Composition API and TypeScript

Best practices

  • Keep one source of truth for state; derive values instead of duplicating them
  • Prefer Composition API and <script setup lang="ts"> SFCs by default unless constrained
  • Keep components small and single-responsibility; split UI and orchestration
  • Move shared logic and side effects into composables (useXxx) and use a store for app-wide state
  • Make data flow explicit: props down, emits/events up, use v-model for two-way bindings, provide/inject sparingly
  • Use computed properties and watchers appropriately to avoid unnecessary re-renders

Example use cases

  • Split a dashboard component into data-fetching composable + presentational child components
  • Refactor form logic into a useForm composable and keep inputs as focused child components
  • Review a PR to ensure props/emits are used instead of global mutable state
  • Migrate a small app from Options API to Composition API with TypeScript SFCs
  • Introduce a centralized store for authenticated user state and derive read-only views with getters

FAQ

Should I always use the Composition API?

Prefer Composition API by default for new code and refactors; keep Options API only when migration cost outweighs benefits.

When should I split a component?

Split when a component has more than one responsibility, mixes orchestration with presentation, or grows hard to test and reason about.

How do I share state across unrelated components?

Use a store for app-wide state and composables for reusable logic. Use provide/inject only for tightly related component hierarchies.