Modèles de données et composants Web

Imaginez ceci : vous avez probablement entendu parler des composants Web à plusieurs reprises : leur magie, leur capacité unique à s'isoler via Shadow DOM. Il existe d'innombrables articles, des webinaires sans fin, et on a l'impression que l'ensemble de la communauté du développement Web se concentre uniquement sur une seule chose : isoler les styles et le balisage. Et si je vous disais que ce n’est que la pointe de l’iceberg ? Que les composants Web ont bien plus de fonctionnalités, s'étendant bien au-delà du Shadow DOM ?

Aujourd'hui, je souhaite vous emmener au-delà de la surface et mettre en lumière quelque chose qui passe souvent inaperçu : la manière dont les composants Web gèrent les données. Pourquoi ce sujet reçoit-il si peu d’attention ? C’est peut-être parce que la spécification officielle ne met pas en évidence ce potentiel. Mais une fois que vous commencerez à explorer, vous réaliserez à quel point tout est négligé.

Je m'excuse d'avance si je commence lentement et que je deviens un peu fastidieux. C'est nécessaire pour la tâche à accomplir.

Pourquoi les composants Web ont-ils besoin de données ?

Les composants Web sont conçus pour être des éléments autonomes pouvant fonctionner indépendamment des autres parties du système. Cette autonomie simplifie leur intégration dans différents domaines d'une application et permet une réutilisation facile dans différents projets. La clé de cette indépendance est l'encapsulation, qui masque non seulement l'apparence du composant mais également son comportement interne. Ce comportement, à son tour, est étroitement lié à la manière dont le composant gère et utilise les données.

Par exemple, considérons un composant de calculatrice conçu pour effectuer des opérations arithmétiques de base. Ce composant gère des comportements tels que l'affichage du résultat actuel, le stockage du résultat précédent et l'exécution de calculs. Pour y parvenir, il conserve des données telles que le résultat actuel, le résultat précédent et des paramètres tels que les restrictions sur les valeurs d'entrée.

Les données utilisées par les composants Web peuvent être décrites comme un « état local ». Cet état local stocke les informations essentielles au fonctionnement du composant. Il peut inclure des données temporaires, des résultats de calcul intermédiaires ou d'autres valeurs nécessaires pour effectuer des tâches spécifiques au sein du composant.

Pour commencer, regardons un exemple simple de la façon dont les propriétés d'un composant peuvent stocker des données de base :

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

Les données de cet exemple sont souvent qualifiées de modèle de données « stupide ». Son objectif principal est simplement de stocker des informations sans impliquer aucune logique complexe. Malgré sa simplicité, il s'agit d'un pas en avant car les données nécessaires au fonctionnement du composant sont stockées en interne, évitant ainsi l'utilisation de variables globales.

En conservant les données à l'intérieur du composant, nous garantissons qu'elles sont isolées du système externe, ce qui signifie que le composant peut fonctionner de manière indépendante. De plus, pour souligner l'encapsulation des données, nous préfixons le nom de la propriété avec un trait de soulignement. Cette convention signale que la propriété est destinée à un usage interne uniquement et ne doit pas être accessible en externe.

Alors, que peut-on réaliser d'autre avec ce modèle "stupide" à l'intérieur d'un composant ? Une fonctionnalité utile est la mise en cache. En stockant les données dans le composant, nous pouvons éviter les recalculs inutiles, les requêtes réseau redondantes ou d'autres opérations gourmandes en ressources. Dans notre exemple, la sauvegarde du résultat du calcul précédent permet la mise en place d'une fonction d'annulation, ce qui améliore les performances et l'expérience utilisateur.

Modèle épais

Le modèle de données « stupide » est-il une solution universelle pour tous les cas ? Lorsqu’on travaille avec des composants simples, cela peut en effet suffire. Ce modèle est facile à mettre en œuvre et gère bien les tâches de base de stockage et de traitement des données. Cependant, à mesure que la logique des composants devient plus complexe, il devient de plus en plus difficile de maintenir le modèle « stupide ». Lorsqu'un composant implique plusieurs opérations de données, notamment la modification et l'analyse, il est logique de simplifier la structure en séparant cette logique en classes distinctes. L'une de ces approches consiste à utiliser un modèle de données « épais » pour isoler tous les processus liés aux données du composant lui-même.

Prenons un exemple. Un modèle « épais » peut être représenté par une classe distincte qui stocke les données et fournit des méthodes pour les modifier. Dans ce modèle, nous pouvons non seulement stocker le résultat et la valeur précédente, mais nous pouvons également ajouter une logique auxiliaire, comme la sauvegarde automatique du résultat précédent avant tout calcul. Cela simplifie grandement le composant, le libérant de la gestion directe des données.

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

En utilisant le modèle épais, nous encapsulons non seulement les données dans le composant, mais nous masquons également une partie du comportement du composant lui-même. Le composant ignore désormais à la fois la structure des données et les détails de la façon dont les données sont définies, modifiées et récupérées. Son propre comportement est simplifié.

Avec l'introduction du modèle épais, le composant assume le rôle de contrôleur. Il gère le modèle mais n’a pas besoin d’en connaître les rouages. De ce fait, le composant ne dépend plus de la structure des données ni des méthodes utilisées pour les traiter. Tout ce qu’il a besoin de connaître, c’est l’interface du modèle, c’est-à-dire l’ensemble des méthodes qu’il fournit. Cette approche permet de remplacer facilement un modèle par un autre.

De plus, le modèle épais devient réutilisable : il peut désormais être utilisé non seulement dans un composant mais aussi dans d'autres, à condition qu'ils fonctionnent avec des données similaires.

Pour encore plus de flexibilité, le modèle Adaptateur peut être utilisé. Ce modèle garantit la compatibilité entre le composant et le modèle, même si leurs interfaces diffèrent initialement. Par exemple, si un composant nécessite un modèle avec une logique supplémentaire, nous pouvons créer un adaptateur pour ajouter cette logique tout en conservant l'interface commune.

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

Maintenant, pour qu'un autre composant fonctionne avec le même modèle, il suffit d'appliquer cet adaptateur. Si nous devons utiliser un modèle différent, nous pouvons soit remplacer sa méthode de création, soit connecter un autre adaptateur. Cela garantit que le composant reste inchangé, tandis que son comportement est contrôlé par le modèle auquel il est connecté.

Ainsi, séparer la logique en un modèle de données épais permet d'atteindre plusieurs objectifs importants. Premièrement, cela rend le composant plus léger et plus facile à comprendre, le laissant uniquement avec des tâches de gestion. Deuxièmement, le modèle devient un élément indépendant et réutilisable au sein du système. Troisièmement, l'utilisation de modèles tels que l'adaptateur garantit la flexibilité et l'évolutivité, permettant à la logique de gestion des données de s'adapter aux exigences changeantes. Bien que cela puisse sembler excessif dans des cas plus simples, cela jette les bases de la construction d'architectures plus complexes et plus stables à l'avenir.

Décomposition du SSOT

Explorons la possibilité d'aller encore plus loin en termes d'organisation des composants et de leur interaction. Précédemment, nous avons expliqué comment l'autonomie des éléments simplifie leur intégration dans différentes parties d'une application et les rend aptes à être réutilisés dans d'autres projets. Cependant, l’autonomie des composants ouvre une autre opportunité intéressante : elle permet de décomposer la source unique de vérité (SSOT) globale et de la déplacer partiellement en composants individuels. Cela signifie qu'au lieu d'avoir un SSOT global dans le système, nous pouvons travailler avec des SSOT locaux qui encapsulent une partie de la logique et des données.

L'idée est que diviser la source globale de vérité en sources locales nous permet de créer des composants qui sont non seulement autonomes dans leurs aspects visuels, mais qui ont également leur propre logique locale nécessaire pour accomplir leurs tâches. Ces composants cessent d'être de simples éléments visuels et deviennent des mini-systèmes indépendants qui gèrent leurs propres données et comportements. Cela augmente considérablement leur indépendance par rapport au reste de l'application, ce qui améliore la stabilité et simplifie l'évolution du système.

De plus, lorsque nous parlons de composants, nous ne nous limitons pas aux petits éléments de l'interface utilisateur comme les boutons, les tableaux ou les graphiques. Un composant peut faire référence à des éléments d'application plus complexes et plus volumineux, comme un panneau de paramètres qui combine plusieurs fonctions différentes, un formulaire d'inscription ou de saisie de données, ou encore une section avec plusieurs graphiques interactifs. Chacun de ces composants peut avoir sa propre source de vérité locale, qui gère l'état et la logique uniquement au sein de cet élément spécifique.

La décomposition du SSOT en parties locales simplifie la gestion de l’état d’une application. Par exemple, au lieu d’utiliser une source globale de vérité pour tous les éléments du formulaire, nous pouvons encapsuler l’état dans le formulaire, garantissant ainsi son indépendance par rapport aux autres parties de l’application. Cela réduit non seulement la complexité du développement, mais rend également le système plus flexible, permettant de remplacer ou de modifier des composants sans nécessiter de modifications de la logique globale.

Cette approche de la conception architecturale est particulièrement utile dans les applications à grande échelle où la logique globale peut être surchargée et où les modifications apportées à une partie de celle-ci peuvent avoir des effets en cascade sur l'ensemble du système. Les sources locales de vérité contribuent à minimiser ces risques en créant des zones de responsabilité isolées, ce qui simplifie la maintenance et améliore la lisibilité du code.

Conclusion

La capacité des composants Web à stocker leurs propres données nous permet de les voir comme plus que de simples éléments visuels de l'interface. Désormais, ils peuvent être considérés comme des modules autonomes intégrant des données, une logique et une présentation. Cette approche fait des composants un outil efficace pour créer une architecture d’application. Ils peuvent encapsuler des comportements complexes, gérer leur état interne et organiser des interactions avec d’autres éléments du système à un niveau supérieur. Cela transforme les composants Web en un outil polyvalent pour créer des applications flexibles et évolutives.

Pour développer davantage l'approche décrite ici et simplifier considérablement mes propres tâches liées à la création d'interfaces, j'ai développé la bibliothèque KoiCom, qui est basée sur la gestion des données et le transfert de données entre composants.

Documentation KoiCom
KoiCom github

En fin de compte, j'espère que de telles solutions aideront les développeurs à adopter une approche plus moderne de la conception d'interfaces, rendant les applications plus évolutives et plus faciles à maintenir.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!