حالات تطبيقية في Vue.js

Contexte : Une équipe RH utilise un formulaire Vue.js pour collecter des noms de candidats. Le Problème : La valeur saisie dans le champ input ne se reflète pas correctement dans l'affichage en dessous. Contraintes : Utiliser v-model. Pas de librairie externe. Code actuel : <script setup> import { ref } from 'vue'; const name = ref(""); </script> <template> <input :value="name" /> <p>{{ name }}</p> </template> Livrable attendu : Corriger le binding pour que la saisie utilisateur mette à jour la variable réactive en temps réel.

Contexte : Vous reprenez un composant Vue.js utilisé dans un tableau de bord interne pour afficher un compteur de clics lors de démonstrations produit. Le Problème : Lorsque l'utilisateur clique sur le bouton, la valeur affichée ne change pas alors que la variable semble être modifiée dans le script. Contraintes : Vous devez conserver l'API Composition. Aucune librairie externe autorisée. Le composant doit rester simple et autonome. Code actuel : <script setup> let count = 0; function increment() { count++; } </script> <template> <div> <p>{{ count }}</p> <button @click="increment">Increment</button> </div> </template> Livrable attendu : Corriger la gestion de la réactivité afin que la valeur s'actualise correctement dans le template lors des clics.

Contexte : Une application affiche le prénom et le nom d'un utilisateur et doit générer automatiquement le nom complet. Le Problème : Le nom complet ne se met pas à jour lorsque l'un des champs change. Contraintes : Utiliser computed. Aucune librairie externe. Code actuel : <script setup> import { ref } from 'vue'; const firstName = ref("John"); const lastName = ref("Doe"); function fullName() { return firstName.value + " " + lastName.value; } </script> <template> <p>{{ fullName }}</p> </template> Livrable attendu : Transformer la logique afin que le nom complet soit réactif et mis à jour automatiquement.

Contexte : Une application doit afficher un message uniquement si l'utilisateur est connecté. Le Problème : Le message s'affiche toujours, quelle que soit la valeur de la variable. Contraintes : Utiliser correctement v-if. Aucune dépendance externe. Code actuel : <script setup> import { ref } from 'vue'; const isLogged = ref(false); </script> <template> <p v-if="isLogged">Bienvenue</p> </template> Livrable attendu : Corriger la condition afin que le rendu conditionnel fonctionne correctement avec la valeur réactive.

Contexte : Plusieurs sections de l'application doivent pouvoir être ouvertes et fermées dynamiquement. Le Problème : Aucun composant générique n'existe pour gérer cet affichage conditionnel. Contraintes : Utiliser l'API Composition. Pas de dépendance externe. Livrable attendu : Implémenter un composant Toggle acceptant du contenu via slot et permettant d'afficher ou masquer ce contenu via un bouton.

Contexte : Une application affiche une liste statique de collaborateurs. Le Problème : Les utilisateurs souhaitent filtrer les noms via un champ de recherche. Contraintes : Utiliser ref et computed pour filtrer la liste. Pas de librairie externe. Livrable attendu : Développer un composant permettant de filtrer dynamiquement une liste selon la saisie utilisateur.

Contexte : Une application doit afficher une liste d'utilisateurs provenant d'une API publique. Le Problème : Aucun mécanisme de récupération de données n'est encore implémenté. Contraintes : Utiliser fetch natif et onMounted. Pas de librairie externe. Livrable attendu : Implémenter un composant qui récupère des données au montage et les affiche dans une liste.

Contexte : L'équipe design souhaite uniformiser l'affichage des cartes produits. Le Problème : Les développeurs dupliquent le même template dans plusieurs pages. Contraintes : Créer un composant réutilisable acceptant title et description en props. Livrable attendu : Implémenter un composant Card simple et démontrer son utilisation avec différentes valeurs passées en props.

Contexte : Une équipe marketing souhaite limiter les descriptions produits à 150 caractères. Le Problème : Aucun indicateur n'informe l'utilisateur du nombre de caractères restants. Contraintes : Utiliser ref et computed. Pas de librairie externe. Livrable attendu : Créer un composant avec textarea affichant dynamiquement le nombre de caractères restants.

Contexte : Une application interne affiche une liste de tâches saisies par les collaborateurs. Le Problème : Lorsqu'une nouvelle tâche est ajoutée, l'affichage devient incohérent et certains éléments semblent dupliqués. Contraintes : Vous devez corriger uniquement la gestion du v-for et des clés. Aucune librairie externe. Code actuel : <script setup> import { ref } from 'vue'; const tasks = ref(["A", "B"]); function addTask() { tasks.value.push("Nouvelle tâche"); } </script> <template> <ul> <li v-for="(task, index) in tasks" :key="index"> {{ task }} </li> </ul> <button @click="addTask">Ajouter</button> </template> Livrable attendu : Corriger la gestion des clés pour garantir un rendu stable et prévisible.

Contexte : Une application interne permet de créer des profils utilisateurs via un formulaire multi-champs. Le Problème : Lors de la modification d'un champ, les autres propriétés de l'objet formulaire disparaissent. Contraintes : Vous devez conserver un seul objet réactif pour le formulaire. Aucune librairie externe. Code actuel : <script setup> import { reactive } from 'vue'; const form = reactive({ name: '', email: '' }); function updateField(e) { form = { [e.target.name]: e.target.value }; } </script> Livrable attendu : Corriger la gestion de l'objet réactif afin que chaque champ mette à jour uniquement sa propriété sans écraser les autres.

Contexte : Un composant doit charger des données lors de son montage pour afficher un tableau statistique. Le Problème : En cas de navigation rapide, des données obsolètes remplacent les données plus récentes. Contraintes : Gérer correctement l'asynchrone sans librairie externe. Livrable attendu : Implémenter une gestion robuste des appels asynchrones dans onMounted pour éviter les conditions de concurrence.

Contexte : Un composant enfant reçoit une liste d'éléments via props pour affichage dans un tableau. Le Problème : Lorsque la liste est modifiée dans le parent, le composant enfant ne reflète pas les changements. Contraintes : Utiliser correctement defineProps et éviter la mutation directe des props. Code actuel : <script setup> const props = defineProps({ items: Array }); props.items.push({ id: 3, name: 'New' }); </script> Livrable attendu : Corriger la gestion des props afin de respecter les bonnes pratiques et garantir la réactivité.

Contexte : Un composant enfant doit notifier son parent lorsqu'une action spécifique est déclenchée. Le Problème : L'événement personnalisé n'est pas correctement capturé par le parent. Contraintes : Utiliser defineEmits et respecter les conventions Vue 3. Livrable attendu : Implémenter correctement l'émission et la réception d'événements personnalisés entre parent et enfant.

Contexte : Plusieurs composants de l'application consomment des endpoints REST similaires avec logique de loading et gestion d'erreurs répétée. Le Problème : Le code est dupliqué dans chaque composant et devient difficile à maintenir. Contraintes : Créer un composable réutilisable sans librairie externe. Livrable attendu : Implémenter un composable useApi permettant de gérer loading, data et error de manière centralisée et réutilisable.

Contexte : L'application doit supporter un thème clair et sombre partagé entre plusieurs composants. Le Problème : Le thème est actuellement dupliqué dans plusieurs composants sans cohérence globale. Contraintes : Utiliser provide et inject sans librairie externe. Livrable attendu : Mettre en place un système global simple permettant de partager et modifier le thème dynamiquement.

Contexte : Une application affiche une longue liste d'articles sans pagination. Le Problème : Le rendu devient lent lorsque la liste dépasse 1 000 éléments. Contraintes : Implémenter une pagination côté client sans librairie externe. Livrable attendu : Développer une logique permettant d'afficher un nombre limité d'éléments par page avec navigation précédente/suivante.

Contexte : Une interface affiche dynamiquement plusieurs sections en fonction du rôle utilisateur. Le Problème : Certaines sections sont recréées inutilement à chaque changement mineur d'état. Contraintes : Optimiser l'utilisation de v-if, v-show et composants dynamiques. Livrable attendu : Refactoriser le rendu conditionnel afin de limiter les destructions et recréations inutiles de composants.

Contexte : Une interface affiche plus de 5 000 enregistrements côté client avec possibilité de filtrage dynamique. Le Problème : Le filtrage est recalculé inutilement à chaque rendu, provoquant des ralentissements. Contraintes : Utiliser computed pour optimiser les recalculs. Aucune librairie externe. Livrable attendu : Mettre en place un filtrage performant basé sur computed qui ne se recalculera que lorsque les dépendances changent.

Contexte : Vous reprenez un module Vue.js qui recharge automatiquement des données dès qu'un filtre change dans un tableau analytique interne. Le Problème : À chaque mise à jour des données récupérées, le watcher relance un nouvel appel API, créant une boucle infinie et surchargeant le backend. Contraintes : Vous devez conserver l'API Composition. Aucune librairie externe autorisée. La récupération doit rester asynchrone via fetch. Code actuel : <script setup> import { ref, watch } from 'vue'; const filter = ref('all'); const data = ref([]); watch(data, async () => { const res = await fetch(`/api/items?filter=${filter.value}`); data.value = await res.json(); }); </script> Livrable attendu : Corriger la logique du watcher afin d'éviter les appels en boucle tout en conservant un rechargement correct lors du changement du filtre.

Contexte : Une application métier comporte plusieurs modules partageant un état global complexe (utilisateur, permissions, préférences). Le Problème : L'état est dupliqué dans plusieurs composants, entraînant incohérences et maintenance difficile. Contraintes : Aucune librairie externe comme Pinia ou Vuex autorisée. Utiliser provide/inject ou un pattern maison. Livrable attendu : Concevoir un store global personnalisé robuste permettant centralisation, mutation contrôlée et réactivité optimale.

Contexte : L'application doit synchroniser l'état utilisateur entre plusieurs onglets du navigateur. Le Problème : Une modification dans un onglet n'est pas répercutée dans les autres. Contraintes : Aucune librairie externe. Utiliser les API natives du navigateur. Livrable attendu : Implémenter un mécanisme de synchronisation basé sur localStorage ou BroadcastChannel pour maintenir la cohérence entre onglets.

Contexte : Une application consomme une API coûteuse et met en cache les réponses dans un composable partagé. Le Problème : Certaines données obsolètes persistent même après modification côté serveur. Contraintes : Implémenter une stratégie d'invalidation simple sans librairie externe. Code actuel : const cache = {}; export async function fetchData(url) { if (cache[url]) { return cache[url]; } const res = await fetch(url); const data = await res.json(); cache[url] = data; return data; } Livrable attendu : Améliorer la stratégie de cache afin d'introduire une invalidation contrôlée et éviter les incohérences.

Contexte : Un composable useFetch est utilisé pour charger des données selon un paramètre dynamique dans plusieurs composants. Le Problème : Lorsque le paramètre change rapidement, des réponses obsolètes écrasent les données les plus récentes. Contraintes : Vous devez corriger la condition de concurrence sans librairie externe. Code actuel : <script> import { ref, watch } from 'vue'; export function useFetch(url) { const data = ref(null); watch(url, async (newUrl) => { const res = await fetch(newUrl); data.value = await res.json(); }); return { data }; } </script> Livrable attendu : Mettre en place un mécanisme empêchant les réponses obsolètes d'écraser l'état courant.

Contexte : Une interface doit afficher plus de 30 000 enregistrements dans un tableau scrollable. Le Problème : Le rendu complet bloque l'interface et consomme excessivement la mémoire. Contraintes : Aucune librairie externe de virtualisation autorisée. Implémentation maison requise. Livrable attendu : Concevoir un composant capable d'afficher uniquement les éléments visibles en fonction de la position du scroll tout en maintenant la cohérence visuelle.

Contexte : Une plateforme B2B doit afficher certaines sections uniquement selon le rôle et les permissions de l'utilisateur. Le Problème : Les contrôles sont dispersés dans les templates et difficiles à maintenir. Contraintes : Centraliser la logique sans librairie externe. Livrable attendu : Concevoir une architecture permettant de vérifier dynamiquement les permissions via composable ou directive personnalisée.

Contexte : L'application doit générer dynamiquement des formulaires à partir d'un schéma JSON fourni par le backend. Le Problème : Les validations et types de champs sont interprétés de manière statique, rendant le système peu flexible. Contraintes : Aucune librairie externe de formulaire autorisée. Utiliser l'API Composition et composants dynamiques. Livrable attendu : Concevoir un moteur de formulaires capable d'interpréter dynamiquement un schéma JSON, générer les champs correspondants et gérer leur validation.

Contexte : Un dashboard affiche différents widgets selon le contexte utilisateur. Le Problème : Les widgets sont recréés inutilement à chaque changement mineur d'état. Contraintes : Utiliser defineAsyncComponent et composants dynamiques si nécessaire. Livrable attendu : Refactoriser le rendu afin de limiter les destructions inutiles et améliorer la performance globale.

Contexte : Une application Vue historique mélange logique métier, appels API et rendu dans les mêmes composants volumineux. Le Problème : L'application devient difficilement maintenable et peu scalable. Contraintes : Aucune librairie externe. Utiliser composables, séparation logique et composants spécialisés. Livrable attendu : Proposer une architecture modulaire claire séparant logique métier, accès données et rendu UI tout en maintenant la compatibilité existante.

Contexte : Vous reprenez une application Vue.js affichant en temps réel des transactions via WebSocket dans un tableau analytique interne. Le Problème : À chaque navigation entre pages, une nouvelle connexion WebSocket est ouverte sans fermer l'ancienne, provoquant des fuites mémoire et des messages dupliqués. Contraintes : Vous devez utiliser l'API Composition. Aucune librairie externe autorisée. La connexion doit être proprement fermée lors du démontage du composant. Code actuel : <script setup> import { ref, onMounted } from 'vue'; const messages = ref([]); onMounted(() => { const socket = new WebSocket('wss://example.com/feed'); socket.onmessage = (event) => { messages.value.push(event.data); }; }); </script> Livrable attendu : Refactoriser la logique afin d'assurer une seule connexion active et une fermeture correcte avec onUnmounted.