Interner Ereignisrückruf der Webkomponentenkomponente und Problempunktanalyse

Vorne geschrieben

Ich habe mich in letzter Zeit mit Webkomponenten (WC) beschäftigt und erste Ergebnisse erzielt. Heute möchte ich mir WC aber noch einmal genauer ansehen.

Was genau ist WC?

Einfach ausgedrückt kapselt Web Component Komponenten in Form von HTML-Tags und bei ihrer Verwendung ist kein zusätzlicher JS-Code erforderlich.

Komponenten sind die Entwicklungsrichtung des Front-Ends. Wenn man das umgebende Technologie-Ökosystem außer Acht lässt, sind React und Vue beides Komponenten-Frameworks. WC kann daher als Erweiterung des ursprünglichen Etiketts angesehen werden. Letztendlich ist es immer noch ein Etikett!

Ähnlich wie das Tag <video></video> verfügt es über mehr Stile und Funktionsattribute als native Tags.

Da Google den Chrome-Browser kontrolliert, fördert es die nativen Komponenten des Browsers, insbesondere die Web Components API.

Im Vergleich zu Frameworks von Drittanbietern sind native Komponenten einfach, direkt und intuitiv, müssen keine externen Module laden und verfügen über eine geringe Codemenge. Alles scheint perfekt und es scheint, dass es als Ersatz für React, Vue und dergleichen verwendet werden kann.

Aktuelle Mängel

Bei der Verwendung mit anderen Web-Frameworks treten einige kleinere Probleme auf, die zu Problemen bei der Entwicklung führen können.

1. Rückruf von komponenteninternen Ereignissen

Beispielsweise wird das Ereignis der Schaltfläche „OK“ in einer Popup-Komponente ( <my-dialog></my-dialog> ) ausgelöst?

Klasse myDialog erweitert HTMLElement {
  // ...
  verbundenerCallback() {
    const shadowRoot = this.attachShadow({ mode: 'open' });
    shadowRoot.innerHTML = `
      <div Klasse="Dialog">
        <div Klasse="Dialoginhalt">
          <div Klasse="Dialog-Body">
            Popup-Inhalt</div>
 
          <button id="okBtn">OK</button>
        </div>
      </div>
    `;
     shadowRoot.querySelector('#okBtn').addEventListener('klicken', () => {
      // Ereignisse innerhalb der Komponente definieren this.dispatchEvent(new CustomEvent('okBtnFn'));
    });
  }
} 
customElements.define('mein-Dialog', meinDialog);

Die aktuelle Lösung besteht darin, innerhalb des benutzerdefinierten Elements new CustomEvent() zu verwenden und mit addEventListener extern zuzuhören. Diese Art des Schreibens ist sehr hässlich, als wären wir in die Ära des Schreibens von Anwendungen mit nativem JS zurückgekehrt.

<mein-Dialog></mein-Dialog> 
<Skript>
  Standard exportieren {
    erstellt() {
      document.addEventListener('okBtnFn', function(){
        // Klicken Sie auf die Popup-Schaltfläche, um das Rückrufereignis auszulösen});
    }
  }
</Skript>

2. Abdeckung des Komponentenstils

Für Entwickler ist es unvermeidlich, dass sie die internen Stile von Komponenten anpassen müssen. Unabhängig davon, ob Sie antd , vant oder andere Komponentenbibliotheken verwenden, erschwert Ihnen der CSS-Anti-Pollution-Mechanismus von WC die Änderung interner Stile. Dies erfordert, dass Sie einen gewissen Preis zahlen, um den internen Stil in Verkleidung zu ändern

3. Relatives Pfadproblem interner Ressourcen in Komponenten

Derzeit kann keine Komponente, die direkt auf Custom Element v1, Template und HTML Import basiert, vollständig ressourcenunabhängig sein. Sie kann keine intern gekapselten Ressourcendateien verwenden, ohne die Umgebung des Benutzers zu kennen und ohne dem Benutzer zusätzliche Einschränkungen aufzuerlegen. Wenn Sie beispielsweise eine benutzerdefinierte Symbolkomponente haben:

Klasse MyIcon erweitert HTMLElement {
    static erhalte beobachteteAttribute() { return ['Name','Größe','Farbe'] }
    Konstruktor() {
        super();
        const shadowRoot = this.attachShadow({ mode: 'open' });
        shadowRoot.innerHTML = `
            <svg Klasse="Symbol" id="Symbol" aria-hidden="true" viewBox="0 0 1024 1024">
                <use id="verwenden"></verwenden>
            </svg>        
    } 
    attributeChangedCallback (Name, alterWert, neuerWert) {
        wenn( Name == 'Name' && diese.shadowRoot){
            // Wenn im Stammverzeichnis des verwendeten Projekts keine icon.svg-Datei vorhanden ist, dann gg
            this.use.setAttributeNS('http://www.w3.org/1999/xlink', 'xlink:href', `./icon.svg#icon-${newValue}`);
        }
    }
}
customElements.define('mein-Symbol', MeinSymbol);

Wenn sich im Stammverzeichnis des von Ihnen verwendeten Projekts keine Datei icon.svg befindet, dann gg. Wenn Sie hier einen CDN-Pfad verwenden, treten domänenübergreifende Probleme auf.

4. Problem beim Erfassen des Werts von Formularkomponenten

Der Wert des Tags <input>, <textarea> oder <select> im Shadow DOM wird nicht automatisch im Formular zugeordnet.

Beispielcode:

// Webkomponente
Klasse InputAge erweitert HTMLElement {
  Konstruktor() {
    super();
  }  
// Komponente verbinden
  verbundenerCallback() {
    const shadow = this.attachShadow({ Modus: 'geschlossen' });
    shadow.innerHTML = `<input type="number" placeholder="age" min="18" max="120" />`;
  }
}
// Komponente registrieren
customElements.define( 'Eingabealter', Eingabealter );

Nach dem Einsatz der WC-Komponente

<Formular-ID="meinFormular">
  <input type="text" name="Ihr Name" placeholder="name" />
  <input-age name="Ihr Alter"></input-age>
 
  <button>Senden</button>
</form>
 
<Skript>
 const form = document.getElementById('myform');
 
  form.addEventListener('senden', e => {
    
    e.preventDefault();
    console.log('Übermittelte Daten:');
 
    const data = neues FormData(Formular);
    für (let nv von data.entries()) {
      Konsole.log(` ${ nv[0] }: ${ nv[1] }`);
    }
 
  });
</Skript>

value von input-age kann beim Absenden nicht abgerufen werden. Natürlich wird es Lösungen geben, aber sie werden kompliziert sein.

5. Sonstiges

Darüber hinaus ist auch die fehlende Datenbindung und Zustandsverwaltung ein Mangel von WC, auf den hier nicht näher eingegangen wird.

Schreiben Sie auf die Rückseite

WC bezieht sich auf die Erweiterung der DOM-Funktionen von HTML, um HTML wiederverwendbarer zu machen.

WC kann als nativer Tag verwendet und in jedem Front-End-Framework oder ohne Framework ausgeführt werden.

In Kombination mit dem aktuellen Mainstream-Technologie-Stack besteht das Hauptproblem von WC darin, dass bei komplexen Komponenten die Datenkommunikation und Ereignisübermittlung bestimmte Nutzungskosten verursachen.

Kompatibilitätsprobleme, wie z. B. die :part Methode, die interne Stile überschreiben kann

Oben finden Sie den detaillierten Inhalt des internen Ereignisrückrufs und der Problempunktanalyse von Web Componentd-Komponenten. Weitere Informationen zum Ereignisrückruf und zu Problempunkten von Web Componentd finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!