حالات تطبيقية في Svelte

Contexte : Une équipe RH utilise un formulaire Svelte pour collecter des informations utilisateur. Le Problème : La valeur saisie dans le champ input ne met pas à jour la variable affichée dans le composant. Contraintes : Utiliser la directive bind:value sans librairie externe. Code actuel : <script> let name = ''; </script> <input value={name} /> <p>{name}</p> Livrable attendu : Corriger le binding afin que la variable soit automatiquement synchronisée avec la saisie utilisateur.

Contexte : Vous reprenez un petit module Svelte utilisé dans un dashboard interne pour afficher un compteur d'actions réalisées par un utilisateur. Le Problème : Lorsque l'utilisateur clique sur le bouton, la valeur affichée ne se met pas à jour correctement dans l'interface. Contraintes : Vous devez conserver un composant simple sans librairie externe. La solution doit respecter le modèle de réactivité natif de Svelte. Code actuel : <script> let count = 0; function increment() { count = count + 1; count = count + 1; } </script> <button on:click={increment}>Increment</button> <p>{count}</p> Livrable attendu : Corriger la logique afin que le compteur incrémente correctement et reflète la valeur attendue après chaque clic.

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 la syntaxe {#if}. Aucune dépendance externe. Code actuel : <script> let isLogged = false; </script> <p>Bienvenue</p> Livrable attendu : Ajouter une condition de rendu appropriée afin que le message ne s'affiche que lorsque isLogged est true.

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'une des variables change. Contraintes : Utiliser les déclarations réactives avec le symbole $:. Aucune librairie externe. Code actuel : <script> let firstName = 'John'; let lastName = 'Doe'; let fullName = firstName + ' ' + lastName; </script> <p>{fullName}</p> Livrable attendu : Transformer la variable fullName en déclaration réactive afin qu'elle se mette à jour automatiquement.

Contexte : L'équipe design souhaite uniformiser l'affichage des cartes produits dans l'application. Le Problème : Le même markup est dupliqué dans plusieurs fichiers. 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 : Plusieurs sections d'une application doivent pouvoir être affichées ou masquées dynamiquement. Le Problème : Aucun composant générique ne permet actuellement de gérer cet affichage conditionnel. Contraintes : Utiliser la syntaxe conditionnelle native de Svelte. Pas de dépendance externe. Livrable attendu : Implémenter un composant Toggle avec un bouton permettant d'afficher ou masquer du contenu via une variable booléenne.

Contexte : Une application affiche une liste statique de collaborateurs. Le Problème : Les utilisateurs souhaitent filtrer les noms via un champ de recherche dynamique. Contraintes : Utiliser la réactivité native de Svelte. Pas de librairie externe. Livrable attendu : Développer un composant permettant de filtrer dynamiquement une liste selon la valeur saisie par l'utilisateur.

Contexte : Une application doit afficher une liste d'utilisateurs provenant d'une API interne. Le Problème : Aucun mécanisme de récupération de données n'est encore implémenté. Contraintes : Utiliser onMount natif de Svelte. 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 : 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 la réactivité native de Svelte. Pas de librairie externe. Livrable attendu : Créer un composant avec textarea affichant dynamiquement le nombre de caractères utilisés et restants.

Contexte : Une application interne affiche une liste de tâches récupérées depuis une variable locale. Le Problème : Lors de l'ajout ou suppression d'éléments, l'affichage devient incohérent et certains éléments semblent se mélanger. Contraintes : Vous devez corriger uniquement la gestion de la boucle each. Aucune librairie externe. Code actuel : <script> let tasks = ['A', 'B']; function addTask() { tasks = [...tasks, 'Nouvelle tâche']; } </script> {#each tasks as task} <p>{task}</p> {/each} <button on:click={addTask}>Ajouter</button> Livrable attendu : Ajouter une clé stable dans la boucle each afin d'assurer un rendu prévisible.

Contexte : Un composant enfant doit modifier une valeur passée depuis un composant parent. Le Problème : Les modifications effectuées dans l'enfant ne sont pas répercutées dans le parent. Contraintes : Utiliser correctement bind:prop entre parent et enfant. Aucune librairie externe. Code actuel : <!-- Parent.svelte --> <script> let value = ''; </script> <Child value={value} /> <!-- Child.svelte --> <script> export let value; function update() { value = 'Updated'; } </script> <button on:click={update}>Update</button> Livrable attendu : Mettre en place un binding bidirectionnel correct entre les deux composants.

Contexte : Une interface Svelte charge des données selon un paramètre dynamique sélectionné par l'utilisateur. Le Problème : Lors de changements rapides du paramètre, des réponses obsolètes écrasent les données plus récentes. Contraintes : Aucune librairie externe. Utiliser uniquement fetch et la réactivité native. Code actuel : <script> import { onMount } from 'svelte'; let id; let data; $: if (id) { fetch(`/api/item/${id}`) .then(res => res.json()) .then(result => data = result); } </script> Livrable attendu : Mettre en place un mécanisme empêchant les réponses obsolètes d'écraser l'état courant.

Contexte : Un composant Svelte affiche une donnée mise à jour toutes les secondes via setInterval. Le Problème : Lors de la navigation, l'interval continue de s'exécuter en arrière-plan. Contraintes : Utiliser onMount et onDestroy. Aucune librairie externe. Code actuel : <script> import { onMount } from 'svelte'; let count = 0; onMount(() => { setInterval(() => { count += 1; }, 1000); }); </script> <p>{count}</p> Livrable attendu : Nettoyer correctement l'interval afin d'éviter toute fuite mémoire lors du démontage du composant.

Contexte : Une équipe souhaite générer dynamiquement des champs de formulaire à partir d'une configuration JSON fournie par le backend. Le Problème : Les champs sont actuellement codés en dur dans le template. Contraintes : Utiliser la syntaxe {#each} et composants dynamiques. Aucune librairie externe. Livrable attendu : Implémenter un composant capable de générer dynamiquement des champs selon une configuration passée en props.

Contexte : Plusieurs parties de l'application doivent pouvoir ouvrir une modale de confirmation centralisée. Le Problème : La logique d'ouverture et fermeture est dupliquée et difficile à maintenir. Contraintes : Utiliser un store natif Svelte pour gérer l'état global. Pas de librairie externe. Livrable attendu : Concevoir un composant Modal réutilisable contrôlé par un store partagé permettant ouverture et fermeture depuis différents composants.

Contexte : L'application doit supporter un thème clair et sombre partagé entre plusieurs composants. Le Problème : Le thème est actuellement géré localement, provoquant des incohérences visuelles. Contraintes : Utiliser un store writable et éventuellement un store dérivé natif. Pas de librairie externe. Livrable attendu : Mettre en place un système global de gestion de thème permettant de basculer dynamiquement entre deux modes.

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

Contexte : Une application calcule des statistiques complexes à partir d'une grande liste de données. Le Problème : Le calcul est exécuté à chaque petite modification d'état, ralentissant l'interface. Contraintes : Utiliser un store dérivé natif pour optimiser les recalculs. Livrable attendu : Refactoriser la logique afin que le calcul ne soit exécuté que lorsque les données pertinentes changent réellement.

Contexte : Une application affiche plus de 5 000 enregistrements côté client avec possibilité de filtrage dynamique. Le Problème : Le filtrage est recalculé à chaque modification mineure non liée au champ de recherche, provoquant des ralentissements. Contraintes : Utiliser les déclarations réactives ($:) pour limiter les recalculs. Aucune librairie externe. Livrable attendu : Implémenter une logique de filtrage optimisée qui ne se déclenche que lorsque les dépendances pertinentes changent.

Contexte : Vous reprenez une application Svelte utilisant un store personnalisé pour partager l'état utilisateur entre plusieurs composants. Le Problème : Lorsqu'une mise à jour est effectuée, certains composants ne se mettent pas à jour correctement ou affichent des valeurs obsolètes. Contraintes : Vous devez conserver un store writable natif de Svelte. Aucune librairie externe autorisée. Code actuel : // store.js import { writable } from 'svelte/store'; export const user = writable({ name: 'John', role: 'admin' }); // Component.svelte <script> import { user } from './store.js'; function updateName() { user.name = 'Alice'; } </script> <button on:click={updateName}>Update</button> <p>{$user.name}</p> Livrable attendu : Corriger la mise à jour du store afin de respecter le mécanisme réactif natif de Svelte.

Contexte : L'équipe souhaite générer dynamiquement des formulaires complexes à partir d'un schéma JSON fourni par le backend. Le Problème : Les champs et validations sont actuellement codés en dur, rendant le système peu flexible. Contraintes : Aucune librairie externe de formulaire autorisée. Utiliser composants dynamiques et stores natifs. Livrable attendu : Concevoir un moteur capable d'interpréter dynamiquement un schéma JSON, générer les champs correspondants et gérer validation et état global de manière réactive.

Contexte : Une application SaaS en Svelte doit gérer une authentification basée sur JWT avec protection conditionnelle de certaines vues. Le Problème : La gestion actuelle du token est locale et expose des incohérences entre composants. Contraintes : Aucun framework externe d'authentification. Utiliser des stores natifs et éventuellement des stores dérivés. Livrable attendu : Concevoir une architecture sécurisée gérant login, logout, stockage du token, état utilisateur dérivé et protection conditionnelle de sections de l'interface.

Contexte : Un store personnalisé charge dynamiquement des données selon un identifiant sélectionné dans l'interface. Le Problème : Lorsque l'identifiant change rapidement, les réponses réseau arrivent dans le désordre et écrasent l'état courant. Contraintes : Aucun outil externe. Utiliser uniquement les stores natifs et la gestion asynchrone JavaScript. Code actuel : import { writable } from 'svelte/store'; export const data = writable(null); export async function load(id) { const res = await fetch(`/api/item/${id}`); const result = await res.json(); data.set(result); } Livrable attendu : Implémenter un mécanisme empêchant les réponses obsolètes d'écraser les données les plus récentes.

Contexte : Une application modulaire en Svelte utilise des abonnements manuels à plusieurs stores dans différents composants. Le Problème : Lors de la navigation entre vues, certains abonnements ne sont pas correctement nettoyés, provoquant des fuites mémoire. Contraintes : Utiliser uniquement les mécanismes natifs d'abonnement et de nettoyage. Code actuel : import { user } from './store'; let unsubscribe; onMount(() => { unsubscribe = user.subscribe(value => { console.log(value); }); }); Livrable attendu : Garantir la désinscription correcte lors du démontage du composant afin d'éviter toute fuite mémoire.

Contexte : Une application consomme une API coûteuse et met en cache les réponses dans un store 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 de données.

Contexte : Une application doit afficher une très grande liste de données issues d'un moteur de recherche interne. Le Problème : Le rendu complet bloque l'interface et consomme trop de mémoire. Contraintes : Aucune librairie externe de virtualisation autorisée. Implémentation native requise. Livrable attendu : Concevoir un composant capable d'afficher uniquement les éléments visibles selon la position du scroll tout en conservant la hauteur totale simulée.

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

Contexte : Une plateforme interne permet de filtrer dynamiquement plus de 20 000 enregistrements. Le Problème : Le filtrage est recalculé à chaque changement d'état non pertinent, provoquant des ralentissements importants. Contraintes : Utiliser des stores dérivés natifs pour optimiser les recalculs. Aucune librairie externe. Livrable attendu : Refactoriser la logique afin que le calcul ne soit exécuté que lorsque les dépendances strictement nécessaires changent réellement.

Contexte : Une application Svelte historique mélange logique métier, appels API et rendu UI dans les mêmes composants volumineux. Le Problème : Le code devient difficilement maintenable et limite l'évolution du produit. Contraintes : Aucune librairie externe. Utiliser séparation par modules et stores. Livrable attendu : Proposer une architecture modulaire claire séparant logique métier, gestion d'état et composants UI tout en maintenant la compatibilité existante.

Contexte : Une application analytique en Svelte affiche des événements temps réel dans plusieurs widgets simultanément. Le Problème : Chaque composant ouvre sa propre connexion WebSocket, provoquant une surcharge serveur et des données dupliquées. Contraintes : Vous devez utiliser uniquement les stores natifs Svelte. Aucune librairie externe autorisée. La connexion doit être mutualisée et correctement nettoyée. Code actuel : // Feed.svelte <script> import { onMount } from 'svelte'; let messages = []; onMount(() => { const socket = new WebSocket('wss://example.com/feed'); socket.onmessage = (event) => { messages = [...messages, event.data]; }; }); </script> Livrable attendu : Concevoir une architecture basée sur un store partagé garantissant une seule connexion active et une diffusion réactive vers tous les composants.