API de composants Web à l'épreuve des balles

Les composants Web/éléments personnalisés offrent des fonctionnalités intéressantes qui peuvent rendre votre UX plus efficace et évolutif, mais il existe certains « pièges » qui peuvent empêcher les équipes d'avoir une bonne expérience avec vos composants.

Le problème

L'un des avantages des éléments/composants Web personnalisés peut parfois être un défi pour eux : ils peuvent être utilisés n'importe où. Vous ne savez jamais s'ils sont utilisés dans un framework, dans un environnement de type sécurisé, rendus sur le serveur avec un langage comme PHP, créés par programme à l'aide de la fonction createElement de JavaScript, ou même en HTML simple.

Le défi est qu'il n'existe aucun moyen cohérent de garantir que les API de vos composants Web sont correctement implémentées. Pour cette raison, l'un des éléments de la liste de contrôle des relations publiques de notre bibliothèque de composants est :

✅ Les attributs et les propriétés fonctionnent lorsqu'ils sont définis, non définis et mal définis.

Par exemple, dans notre bibliothèque, nous avons un composant "input" qui, comme un composant élément, a un attribut type avec certaines valeurs spécifiées. Il n'a pas toutes les mêmes options car nous avons des composants spécifiques pour certaines des autres commandes comme les radios et les cases à cocher.

/** A string specifying the type of control to render. */
@property()
type:
  | 'color'
  | 'date'
  | 'email'
  | 'number'
  | 'password'
  | 'search'
  | 'tel'
  | 'text' = 'text';

REMARQUE : Les exemples de code utilisent Lit, mais les principes discutés ici peuvent être appliqués à d'autres bibliothèques et frameworks.

Lorsque nous testons cet attribut, nous obtenons des résultats incohérents.

• Ensemble
  • tout fonctionne comme prévu.

<my-input type="color"></my-input>
<my-input type="date"></my-input>
<my-input type="email"></my-input>
<my-input type="number"></my-input>
<my-input type="password"></my-input>
<my-input type="search"></my-input>
<my-input type="tel"></my-input>
<my-input type="text"></my-input>

• Désactivé
  • le composant fonctionne correctement lorsque l'attribut n'est pas défini en raison de la valeur par défaut
  • le composant s'affiche correctement lorsque la propriété n'est pas définie car l'élément HTML interne est résilient, mais la logique personnalisée et la validation dans le composant s'interrompent

// When the attribute is not set
<my-input></my-input>

// When the property is `undefined` (example using JSX)
<my-input type={undefined}></my-input>

• Mal réglé
  • définir la valeur de l'attribut type sur « déchets » rend une entrée de texte, mais brise également notre logique et notre validation personnalisées.
  • le définir sur une valeur qui est un type d'entrée HTML valide, mais pas celui que nous avons spécifié pour le composant, rend les contrôles non destinés à notre composant, ce qui brise non seulement notre logique et notre validation personnalisées, mais également nos styles/conceptions. .

<!-- not a real type -->
<my-input type="rubbish"></my-input>

<!-- we don't want users using this type -->
<my-input type="range"></my-input>

Vous pouvez tester cet exemple ici :

Comment pouvons-nous y remédier ?

J'ai remarqué que l'élément HTML natif semble réussir le test « défini, non défini et mal défini », alors voyons si nous pouvons en tirer des leçons.

Lorsque je définis mal l'attribut de l'entrée native et que j'enregistre les valeurs des propriétés, je peux voir pourquoi cela fonctionne.

<!-- set the value to a non-standard type -->
<input type="rubbish" />
<input>



<p>If an invalid value is assigned to the attribute or property, it falls back to a default value. We should be able to do the same and still maintain strong typing.</p>

<p>Let's start by creating a list of valid values and a type for our property.<br>
</p>

<pre class="brush:php;toolbar:false">const inputTypes = [
  'color',
  'date',
  'email',
  'number',
  'password',
  'search',
  'tel',
  'text',
] as const;

Nous pouvons utiliser le tableau pour créer un type d'union pour la validation TypeScript.

/** A string specifying the type of control to render. */
@property()
type:
  | 'color'
  | 'date'
  | 'email'
  | 'number'
  | 'password'
  | 'search'
  | 'tel'
  | 'text' = 'text';

Nous pouvons maintenant mettre à jour notre propriété d'éléments personnalisés avec une logique de validation. Nous pouvons le faire en convertissant notre propriété existante en un getter et un setter de classe JavaScript standard.

<my-input type="color"></my-input>
<my-input type="date"></my-input>
<my-input type="email"></my-input>
<my-input type="number"></my-input>
<my-input type="password"></my-input>
<my-input type="search"></my-input>
<my-input type="tel"></my-input>
<my-input type="text"></my-input>

Voici notre résultat final :

Conclusion

Avec cette nouvelle validation en place, notre composant d'entrée est beaucoup plus résilient qu'avant et permet également une validation plus complexe si nécessaire. Cette méthode peut également être excessive pour certains de vos attributs, en particulier ceux destinés au style. Pour ces scénarios, assurez-vous de consulter cet article.

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!