防弹 Web 组件 API

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 de 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.

type InputType = typeof inputTypes[number];

Now we can update our custom elements property with some validation logic. We can do this by converting our existing property to a standard JavaScript class getter and setter.

// private property for storing the `type` property value
private _type: InputType = 'text';

/** A string specifying the type of control to render. */
@property()
set type(value: InputType) {
  // Confirming the value is in our approved list of values. If not, it will use a fallback value of "text"
  this._type = inputTypes.includes(value) ? value : 'text';
}

get type(): InputType {
  return this._type;
}

Here's our final output:

Conclusion

With this new validation in place, our input component is far more resilient than before and also allows for more complex validation if necessary. This method may also be overkill for some of your attributes, especially those that are for styling. For those scenarios, be sure to check out this article.

以上是防弹 Web 组件 API的详细内容。更多信息请关注PHP中文网其他相关文章！