Files
Mangarr/.cursor/rules/front_vue.mdc

183 lines
6.8 KiB
Plaintext

---
description:
globs: *.vue,*.js,assets/vue/app/*,assets/vue/app/**/*
alwaysApply: false
---
# Architecture Frontend Vue.js
## Introduction
En tant que développeur front-end expérimenté spécialisé en Vue.js, vous devez suivre les meilleures pratiques et standards de développement établis pour ce projet. Votre expertise en Vue.js, TypeScript, et votre maîtrise des patterns de conception modernes sont essentiels pour maintenir une base de code cohérente et maintenable.
## Stack Technique
- **Framework Principal**: Vue.js 3.x avec Composition API
- **Store Management**: Pinia 3.x
- **Routage**: Vue Router 4.x
- **Styling**:
- TailwindCSS 4.x pour les utilitaires CSS
- HeadlessUI pour les composants accessibles
- Heroicons pour l'iconographie
- **Build Tool**: Vite
- **Testing**: Vitest avec Vue Test Utils
- **Linting & Formatting**:
- ESLint avec la configuration Vue.js
- Prettier pour le formatage
## Conventions de Nommage
- **Composants**: PascalCase (ex: `MangaCard.vue`, `SearchBar.vue`)
- **Fichiers**:
- Composants: PascalCase avec extension .vue
- Utilitaires: camelCase avec extension .js/.ts
- Tests: PascalCase.spec.ts
- **Props**: camelCase dans le template, PascalCase dans le script
- **Events**: kebab-case dans le template, camelCase dans le script
- **Stores**: camelCase avec suffixe "Store" (ex: `mangaStore.js`)
- **Composables**: camelCase avec préfixe "use" (ex: `useSearch.js`)
## Structure Générale
L'application Vue.js suit une architecture hexagonale (ports & adapters) avec une séparation claire des responsabilités. Le code est organisé en domaines distincts dans le dossier `assets/vue/`.
Pour ce qui est du style, on utilise TailwindCss, Headlessui et Heroicons.
```
assets/vue/
├── app/
│ ├── shared/ # Code partagé entre les domaines
│ │ ├── components/ # Composants réutilisables
│ │ │ ├── ui/ # Composants UI génériques (boutons, inputs, etc.)
│ │ │ └── layout/ # Layouts réutilisables
│ │ ├── composables/ # Composables Vue partagés
│ │ ├── plugins/ # Plugins Vue (router, pinia, etc.)
│ │ └── utils/ # Utilitaires partagés
│ │
│ ├── domain/ # Domaines métier
│ │ ├── manga/ # Domaine Manga
│ │ │ ├── application/ # Cas d'utilisation
│ │ │ │ ├── commands/ # Commands & CommandHandlers
│ │ │ │ ├── queries/ # Queries & QueryHandlers
│ │ │ │ └── store/ # Store Pinia du domaine
│ │ │ ├── domain/ # Cœur métier
│ │ │ │ ├── entities/ # Entités
│ │ │ │ ├── value-objects/# Objets valeur
│ │ │ │ └── services/ # Services métier
│ │ │ ├── infrastructure/ # Adaptateurs
│ │ │ │ ├── api/ # Client API
│ │ │ │ └── repository/ # Implémentation repository
│ │ │ └── presentation/ # Interface utilisateur
│ │ │ ├── components/ # Composants spécifiques au domaine
│ │ │ ├── composables/ # Composables spécifiques
│ │ │ └── pages/ # Pages du domaine
│ │ │
│ │ ├── reader/ # Domaine Reader (même structure)
│ │ └── scraping/ # Domaine Scraping (même structure)
│ │
│ └── router/ # Configuration du routeur
│ └── index.js # Point d'entrée du routeur
```
## Contrat d'API
Le contrat d'API complet est disponible dans le fichier [api-docs.json](mdc:public/api-docs.json). Ce fichier contient la documentation OpenAPI de toutes les routes disponibles et leurs schémas.
## Règles d'Architecture
### 1. Règles Générales
- Chaque domaine est isolé et ne dépend que de lui-même et du domaine `shared`
- Les dépendances externes sont gérées via les adaptateurs dans l'infrastructure
- L'application est une SPA (Single Page Application) sans rechargement de page
- Utilisation de Vue Router pour la navigation côté client
- Gestion d'état avec Pinia organisée par domaine
### 2. Couche Domain
- Contient les entités et la logique métier pure
- Ne dépend d'aucune bibliothèque externe sauf Vue.js
- Les entités sont des classes JavaScript standard
- Exemple :
```javascript
export class Manga {
constructor({ id, title, description = null }) {
this.id = id;
this.title = title;
this.description = description;
}
static create(data) {
return new Manga(data);
}
}
```
### 3. Couche Application
- Gère les cas d'utilisation via les stores Pinia
- Coordonne les interactions entre l'UI et le domaine
- Transforme les données du domaine pour l'UI
- Exemple de store :
```javascript
export const useMangaStore = defineStore('manga', {
state: () => ({
mangas: [],
loading: false,
error: null
}),
actions: {
async fetchMangas() {
// Logique de chargement
}
}
});
```
### 4. Couche Infrastructure
- Gère la communication avec l'API
- Isole les dépendances externes
- Exemple d'API client :
```javascript
export class MangaApi {
static async fetchAll() {
const response = await fetch('/api/mangas');
return response.json();
}
}
```
### 5. Couche Présentation
- Composants Vue.js spécifiques au domaine
- Utilise les composants UI partagés
- Communique avec la couche application via les stores
- Exemple de composant :
```vue
<template>
<div class="manga-list">
<MangaCard v-for="manga in mangas" :key="manga.id" :manga="manga" />
</div>
</template>
```
## Bonnes Pratiques
### 1. Composants
- Utiliser la Composition API pour la logique
- Séparer les composants UI génériques des composants métier
- Favoriser les props et events pour la communication parent-enfant
- Utiliser les stores pour la communication entre composants distants
### 2. État
- Un store Pinia par domaine
- Actions asynchrones dans les stores
- Getters pour les données dérivées
- État local dans les composants quand possible
### 3. Router
- Routes organisées par domaine
- Lazy loading des composants de page
- Navigation programmatique via le router
- Guards pour la protection des routes
### 4. Style
- Utilisation de Tailwind CSS
- Classes utilitaires pour le style
- Composants Headless UI pour l'accessibilité
- Design system cohérent via les composants partagés
## Validation
Les règles d'architecture peuvent être validées par des outils comme :
- ESLint pour les règles de code
- Tests unitaires pour les composants
- Tests d'intégration pour les stores