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 eine native 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.

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

Jetzt können wir unsere Eigenschaft für benutzerdefinierte Elemente mit einer Validierungslogik aktualisieren. Wir können dies tun, indem wir unsere vorhandene Eigenschaft in einen Standard-JavaScript-Klassen-Getter und -Setter konvertieren.

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

Hier ist unsere endgültige Ausgabe:

Abschluss

Mit dieser neuen Validierung ist unsere Eingabekomponente weitaus robuster als zuvor und ermöglicht bei Bedarf auch eine komplexere Validierung. Diese Methode ist möglicherweise auch für einige Ihrer Attribute übertrieben, insbesondere für diejenigen, die dem Styling dienen. Schauen Sie sich für solche Szenarien unbedingt diesen Artikel an.

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