Kugelsichere Webkomponenten-APIs

Webkomponenten/benutzerdefinierte Elemente bieten einige großartige Funktionen, die Ihre UX effizienter und skalierbarer machen können, aber es gibt einige „Fallstricke“, die Teams daran hindern können, eine gute Erfahrung mit Ihren Komponenten zu machen.

Das Problem

Eines der großartigen Dinge an benutzerdefinierten Elementen/Webkomponenten kann manchmal eine Herausforderung für sie sein – sie können überall verwendet werden. Man weiß nie, ob sie in einem Framework verwendet werden, in einer typsicheren Umgebung, auf dem Server mit einer Sprache wie PHP gerendert, programmgesteuert mit der creatElement-Funktion von JavaScript erstellt oder sogar in einfachem alten HTML.

Die Herausforderung besteht darin, dass es keine einheitliche Möglichkeit gibt, sicherzustellen, dass Ihre Webkomponenten-APIs korrekt implementiert werden. Aus diesem Grund lautet einer der Punkte in der PR-Checkliste unserer Komponentenbibliothek:

✅ Attribute und Eigenschaften funktionieren, wenn sie festgelegt, deaktiviert und schlecht festgelegt sind.

Zum Beispiel haben wir in unserer Bibliothek eine „Eingabe“-Komponente, die wie ein natives Element, verfügt über ein Typattribut mit einigen angegebenen Werten. Es stehen nicht alle Optionen zur Verfügung, da wir für einige der anderen Steuerelemente wie Radios und Kontrollkästchen spezielle Komponenten haben.

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

HINWEIS: Die Codebeispiele verwenden Lit, aber die hier besprochenen Prinzipien können auf andere Bibliotheken und Frameworks angewendet werden.

Wenn wir dieses Attribut testen, erhalten wir inkonsistente Ergebnisse.

• Eingestellt
  • Alles funktioniert wie erwartet.

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

• Unscharf
  • Die Komponente funktioniert einwandfrei, wenn das Attribut aufgrund des Standardwerts nicht festgelegt ist
  • Die Komponente wird korrekt gerendert, wenn die Eigenschaft nicht definiert ist, da das interne HTML-Element stabil ist, die benutzerdefinierte Logik und Validierung in der Komponente jedoch nicht funktioniert

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

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

• Schlecht eingestellt
  • Wenn Sie den Typattributwert auf „Müll“ setzen, wird eine Texteingabe gerendert, aber auch unsere benutzerdefinierte Logik und Validierung wird unterbrochen.
  • Wenn Sie es auf einen Wert setzen, der ein gültiger HTML-Eingabetyp ist, aber nicht einer, den wir für die Komponente angegeben haben, werden Steuerelemente gerendert, die nicht für unsere Komponente bestimmt sind, was nicht nur unsere benutzerdefinierte Logik und Validierung, sondern auch unsere Stile/Designs beeinträchtigt .

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

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

Sie können dieses Beispiel hier testen:

Wie beheben wir das Problem?

Mir ist aufgefallen, dass das native HTML-Element den Test „festgelegt, nicht gesetzt und schlecht gesetzt“ zu bestehen scheint. Mal sehen, ob wir daraus lernen können.

Wenn ich das Attribut der nativen Eingabe falsch einstelle und die Eigenschaftswerte protokolliere, kann ich sehen, warum es funktioniert.

<!-- 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;

Wir können das Array verwenden, um einen Union-Typ für die TypeScript-Validierung zu erstellen.

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.

Das obige ist der detaillierte Inhalt vonKugelsichere Webkomponenten-APIs. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!