حالات تطبيقية في Web Components

Contexte : Un composant personnalisé ne s'affiche pas correctement dans le DOM. Le Problème : L'élément n'est pas reconnu par le navigateur. Contraintes : Utiliser customElements.define correctement. Code actuel : class MyCard extends HTMLElement {} // oubli d'enregistrement Livrable attendu : Corriger le code afin d'enregistrer correctement le composant personnalisé.

Contexte : Une application affiche des statuts utilisateurs (actif, inactif, en attente). Le Problème : Les badges sont codés manuellement avec duplication de style. Contraintes : Utiliser un Web Component avec Shadow DOM pour encapsuler le style. Livrable attendu : Développer un composant <status-badge> acceptant un attribut status et adaptant son style en conséquence.

Contexte : Une page e-commerce affiche plusieurs produits avec la même structure HTML. Le Problème : Le code est dupliqué pour chaque produit. Contraintes : Utiliser Custom Elements natifs. Aucun framework. Livrable attendu : Créer un composant <product-card> acceptant titre et prix via attributs et affichant une structure standardisée.

Contexte : Une application doit afficher un compteur simple pouvant être incrémenté par l'utilisateur. Le Problème : Aucun composant réutilisable n'existe pour cette fonctionnalité. Contraintes : Utiliser uniquement Custom Elements et JavaScript natif. Livrable attendu : Développer un composant <counter-widget> affichant un nombre et un bouton permettant l'incrémentation.

Contexte : Une application doit standardiser ses champs input avec un style cohérent. Le Problème : Les champs sont stylisés différemment selon les pages. Contraintes : Utiliser Shadow DOM pour encapsuler le style. Livrable attendu : Créer un composant <app-input> encapsulant un champ input avec style interne et gestion simple de valeur.

Contexte : Une application interne affiche régulièrement des messages d'information ou d'erreur dans différentes pages. Le Problème : Les blocs HTML sont copiés-collés partout, rendant la maintenance difficile. Contraintes : Utiliser uniquement les Web Components natifs (Custom Elements). Aucun framework autorisé. Livrable attendu : Créer un composant personnalisé <app-alert> capable d'afficher un message passé via attribut et réutilisable dans plusieurs pages.

Contexte : Un composant bouton personnalisé entre en conflit avec les styles globaux du site. Le Problème : Les styles CSS globaux écrasent le design du bouton. Contraintes : Utiliser Shadow DOM natif pour encapsuler les styles. Aucun framework. Code actuel : class MyButton extends HTMLElement { connectedCallback() { this.innerHTML = `<button class="btn">Click</button>`; } } customElements.define('my-button', MyButton); Livrable attendu : Refactoriser le composant pour utiliser attachShadow et encapsuler ses styles.

Contexte : Un composant doit notifier le parent lorsqu'une action interne se produit. Le Problème : Aucun mécanisme de communication n'est en place. Contraintes : Utiliser CustomEvent natif. Livrable attendu : Implémenter un événement personnalisé dispatché par le composant et capturable par le parent.

Contexte : Un composant doit afficher dynamiquement une valeur passée via attribut HTML. Le Problème : La modification de l'attribut ne met pas à jour le contenu affiché. Contraintes : Utiliser observedAttributes et attributeChangedCallback. Code actuel : class UserCard extends HTMLElement { connectedCallback() { this.innerHTML = `<p>${this.getAttribute('name')}</p>`; } } customElements.define('user-card', UserCard); Livrable attendu : Implémenter la gestion correcte des attributs afin que le composant se mette à jour dynamiquement.

Contexte : Un composant personnalisé contient du HTML complexe difficile à maintenir dans une string JavaScript. Le Problème : Le code HTML intégré dans innerHTML devient illisible. Contraintes : Utiliser la balise <template> native HTML. Livrable attendu : Refactoriser le composant pour cloner un template défini dans le document et l'injecter dans le Shadow DOM.

Contexte : Deux composants Web doivent interagir (ex: un filtre et une liste de résultats). Le Problème : Aucune stratégie de communication claire n'est définie. Contraintes : Utiliser uniquement des événements personnalisés natifs. Livrable attendu : Mettre en place une communication propre entre deux composants via CustomEvent et écoute d'événements.

Contexte : Une application doit afficher une modale réutilisable dans plusieurs pages sans dépendre d'une librairie externe. Le Problème : Les implémentations actuelles dupliquent la logique d'ouverture et de fermeture. Contraintes : Utiliser Custom Elements et Shadow DOM natif. Gérer l'état interne du composant. Livrable attendu : Créer un composant <app-modal> capable d'ouvrir et fermer dynamiquement son contenu via méthode publique (open, close) tout en encapsulant son style.

Contexte : Une page e-commerce doit générer dynamiquement plusieurs cartes produits. Le Problème : Le HTML est injecté via innerHTML rendant le code difficile à maintenir. Contraintes : Utiliser la balise <template> et Shadow DOM. Livrable attendu : Implémenter un composant <product-card> clonant un template et acceptant des attributs dynamiques.

Contexte : Une application souhaite encapsuler un champ email avec validation intégrée. Le Problème : La validation est actuellement gérée globalement et non par composant. Contraintes : Utiliser Shadow DOM et CustomEvent pour exposer l'état. Livrable attendu : Développer un composant <email-input> validant son contenu et dispatchant un événement en cas d'erreur ou succès.

Contexte : Une application souhaite créer un composant toggle réutilisable. Le Problème : L'état (on/off) n'est pas correctement synchronisé avec l'attribut HTML. Contraintes : Utiliser Custom Elements natifs avec gestion interne d'état. Livrable attendu : Développer un composant <toggle-switch> capable de gérer son état interne, refléter les changements via attribut et émettre un événement personnalisé.

Contexte : Une équipe souhaite créer un composant layout réutilisable avec header, content et footer personnalisables. Le Problème : Le composant actuel ne supporte pas correctement l'injection de contenu structuré. Contraintes : Utiliser <slot> et éventuellement named slots natifs. Livrable attendu : Concevoir un composant <app-layout> utilisant des slots nommés permettant l'injection flexible de contenu.

Contexte : Un composant doit réagir à son insertion et suppression du DOM. Le Problème : Les ressources internes (listeners, timers) ne sont pas correctement nettoyées. Contraintes : Utiliser connectedCallback et disconnectedCallback. Livrable attendu : Concevoir un composant gérant correctement son cycle de vie et nettoyant ses ressources à la destruction.

Contexte : Une application doit afficher une liste d'éléments interactifs pouvant être supprimés individuellement. Le Problème : La logique d'écoute d'événements est dupliquée et non encapsulée. Contraintes : Utiliser uniquement Web Components natifs et CustomEvent pour communication externe. Livrable attendu : Développer un composant <dynamic-list> capable d'ajouter et supprimer des éléments tout en émettant des événements personnalisés.

Contexte : Plusieurs composants Web utilisent chacun leur Shadow DOM avec styles dupliqués. Le Problème : La duplication des styles rend la maintenance complexe. Contraintes : Utiliser des constructeurs de style partagés (CSSStyleSheet si supporté) ou une stratégie centralisée. Livrable attendu : Refactoriser les composants afin de mutualiser les styles tout en conservant l'encapsulation Shadow DOM.

Contexte : Vous développez un composant <user-profile> utilisé dans plusieurs parties d'une application interne. Le Problème : Lorsque la propriété JavaScript est modifiée dynamiquement (element.name = "Alice"), le rendu ne se met pas à jour car seule la lecture initiale des attributs est implémentée. Contraintes : Utiliser uniquement Web Components natifs (Custom Elements, observedAttributes). Aucun framework. Code actuel : class UserProfile extends HTMLElement { connectedCallback() { this.render(); } render() { this.innerHTML = `<p>${this.getAttribute('name')}</p>`; } } customElements.define('user-profile', UserProfile); Livrable attendu : Implémenter une synchronisation complète entre attributs et propriétés afin que toute modification déclenche un rendu cohérent.

Contexte : Vous devez concevoir un mini design system interne basé uniquement sur Web Components natifs. Le Problème : Les composants existants communiquent mal entre eux et partagent implicitement de la logique globale, ce qui rend l'application difficile à faire évoluer. Contraintes : Utiliser exclusivement Custom Elements, Shadow DOM et CustomEvent. Aucun framework autorisé. Livrable attendu : Proposer une architecture modulaire claire permettant la communication entre composants via événements personnalisés, tout en garantissant isolation et réutilisabilité.

Contexte : Une application SPA légère doit changer de vue sans framework. Le Problème : Les vues sont statiques et ne répondent pas aux changements d'URL. Contraintes : Utiliser History API et Custom Elements uniquement. Livrable attendu : Implémenter un système minimaliste de routing permettant d'afficher dynamiquement différents composants selon l'URL.

Contexte : Une application doit supporter plusieurs thèmes (clair, sombre) avec composants encapsulés en Shadow DOM. Le Problème : Les styles globaux ne pénètrent pas dans le Shadow DOM, empêchant l'application du thème. Contraintes : Utiliser Custom Properties CSS et Shadow DOM natif. Livrable attendu : Concevoir une stratégie de theming compatible Shadow DOM permettant changement dynamique de thème sans casser l'encapsulation.

Contexte : Un composant doit réagir à des modifications dynamiques de son contenu enfant. Le Problème : Les changements internes ne déclenchent aucun rendu ou adaptation. Contraintes : Utiliser MutationObserver natif. Livrable attendu : Implémenter un composant capable d'observer ses changements internes et d'adapter dynamiquement son rendu.

Contexte : Un composant reçoit des données complexes (objet JSON) via propriété JavaScript. Le Problème : Les données ne sont pas correctement synchronisées avec les attributs HTML et le rendu. Contraintes : Implémenter un système de réflexion propriété-attribut cohérent. Livrable attendu : Concevoir une gestion robuste permettant synchronisation bidirectionnelle entre propriétés complexes et rendu interne.

Contexte : Un composant charge des données via fetch et démarre un interval interne. Le Problème : Lorsqu'il est retiré du DOM, les requêtes et timers continuent de fonctionner. Contraintes : Utiliser connectedCallback et disconnectedCallback proprement. Livrable attendu : Implémenter une gestion complète du cycle de vie incluant nettoyage des listeners, timers et opérations asynchrones.

Contexte : Une application doit créer un formulaire composé de plusieurs Web Components enfants. Le Problème : Chaque champ gère sa validation mais aucune stratégie globale ne centralise l'état du formulaire. Contraintes : Utiliser uniquement CustomEvent pour communication entre composants. Livrable attendu : Concevoir un composant parent capable d'écouter les événements de validation des enfants et d'agréger l'état global du formulaire.

Contexte : Un composant complexe met à jour son innerHTML à chaque modification d'état. Le Problème : Chaque mise à jour reconstruit entièrement le DOM interne, entraînant perte d'événements et performances dégradées. Contraintes : Utiliser Web Components natifs sans librairie de virtual DOM. Code actuel : class CounterBox extends HTMLElement { constructor() { super(); this.count = 0; } connectedCallback() { this.render(); } render() { this.innerHTML = `<button>+</button><p>${this.count}</p>`; } } customElements.define('counter-box', CounterBox); Livrable attendu : Refactoriser le composant pour éviter la reconstruction complète du DOM à chaque mise à jour et préserver les performances.

Contexte : Plusieurs composants encapsulés en Shadow DOM doivent échanger des informations. Le Problème : Les événements ne traversent pas correctement les frontières Shadow DOM ou provoquent des effets inattendus. Contraintes : Utiliser CustomEvent avec options bubbles et composed. Livrable attendu : Implémenter une communication fiable entre composants encapsulés en Shadow DOM tout en respectant l'isolation.

Contexte : Plusieurs composants Web utilisent les mêmes styles internes, dupliqués dans chaque Shadow DOM. Le Problème : La duplication des styles augmente la mémoire consommée et complique la maintenance. Contraintes : Utiliser Constructable Stylesheets si supporté par le navigateur. Livrable attendu : Refactoriser les composants afin de partager dynamiquement une feuille de style unique entre plusieurs Shadow DOM.