Composants : props, emits, slots, v-model

Le composant est une fonction avec un contrat

Un composant Vue = un fichier .vue (template + script + style scopé) qui expose une interface :

<script setup lang="ts">
const props = defineProps<{ lesson: Lesson; done?: boolean }>()   // ↓ entrées typées
const emit = defineEmits<{ toggle: [done: boolean] }>()           // ↑ événements typés
</script>

<template>
  <button :class="{ done: props.done }" @click="emit('toggle', !props.done)">
    {{ lesson.title }}
    <slot name="badge" />                                          <!-- contenu injecté -->
  </button>
</template>

Les trois canaux, et leur sens unique :

1. props : les données descendent du parent — jamais mutées par l'enfant (le one-way data flow : la donnée a UN propriétaire) ;
2. emits : les événements remontent — l'enfant signale, le parent décide. C'est le pattern qu'on a appliqué dans les composants de cette plateforme : QuizQuestion émet checked, Flashcard émet graded — les molécules ne savent pas ce que le parent fera ;
3. slots : le parent injecte du contenu DANS l'enfant — l'inversion de contrôle du markup (le composant fournit la structure, le parent le contenu).

v-model : le sucre bidirectionnel (qui reste unidirectionnel)

v-model sur un composant = :modelValue + @update:modelValue — le flux reste descendant + événement, juste raccourci. Un input contrôlé s'écrit ainsi, et un composant de formulaire expose son propre v-model en émettant update:modelValue.

Les règles de conception qui tiennent à l'échelle

• props minimales : un composant qui reçoit 15 props fait trop de choses — découper ;
• l'enfant ignore son contexte : il émet des intentions, ne connaît ni le store ni l'API (testable en isolation — nos tests de QuizQuestion montent le composant seul) ;
• atomic design (utilisé sur cette plateforme même) : atoms (bouton, badge) → molecules (carte de leçon) → organisms (le sommaire) — la taille du contrat croît avec l'étage, l'accès aux stores/API est réservé aux étages hauts.