Datenmodelle und Webkomponenten

Stellen Sie sich Folgendes vor: Sie haben wahrscheinlich schon mehrmals von Webkomponenten gehört – ihrer Magie, ihrer einzigartigen Fähigkeit, sich durch Shadow DOM zu isolieren. Es gibt unzählige Artikel, endlose Webinare und es fühlt sich an, als ob sich die gesamte Webentwickler-Community nur auf eine Sache konzentriert: Stile und Markup zu isolieren. Aber was wäre, wenn ich Ihnen sagen würde, dass dies nur die Spitze des Eisbergs ist? Dass Webkomponenten über weitaus mehr Funktionen verfügen, die weit über das Shadow DOM hinausgehen?

Heute möchte ich Sie über die Oberfläche hinausführen und ein Licht auf etwas werfen, das oft unbemerkt bleibt: wie Webkomponenten mit Daten umgehen. Warum findet dieses Thema so wenig Beachtung? Vielleicht liegt es daran, dass die offizielle Spezifikation dieses Potenzial nicht hervorhebt. Aber sobald Sie mit der Erkundung beginnen, werden Sie feststellen, wie viel übersehen wird.

Ich entschuldige mich im Voraus, wenn ich langsam anfange und etwas langweilig werde. Es ist für die jeweilige Aufgabe notwendig.

Warum benötigen Webkomponenten Daten?

Webkomponenten sind als eigenständige Elemente konzipiert, die unabhängig von anderen Teilen des Systems funktionieren können. Diese Autonomie vereinfacht ihre Integration in verschiedene Bereiche einer Anwendung und ermöglicht eine einfache Wiederverwendung über verschiedene Projekte hinweg. Der Schlüssel zu dieser Unabhängigkeit ist die Kapselung, die nicht nur das Erscheinungsbild der Komponente, sondern auch ihr internes Verhalten verbirgt. Dieses Verhalten wiederum hängt eng damit zusammen, wie die Komponente Daten verwaltet und nutzt.

Stellen Sie sich zum Beispiel eine Taschenrechnerkomponente vor, die für die Ausführung grundlegender arithmetischer Operationen entwickelt wurde. Diese Komponente verwaltet Verhalten wie das Anzeigen des aktuellen Ergebnisses, das Speichern des vorherigen Ergebnisses und das Durchführen von Berechnungen. Um dies zu erreichen, werden Daten wie das aktuelle Ergebnis, das vorherige Ergebnis und Einstellungen wie Einschränkungen für Eingabewerte verwaltet.

Die von Webkomponenten verwendeten Daten können als „lokaler Zustand“ beschrieben werden. Dieser lokale Zustand speichert wesentliche Informationen für den Betrieb der Komponente. Es kann temporäre Daten, Zwischenberechnungsergebnisse oder andere Werte umfassen, die zur Ausführung bestimmter Aufgaben innerhalb der Komponente erforderlich sind.

Schauen wir uns zunächst ein einfaches Beispiel an, wie Komponenteneigenschaften grundlegende Daten speichern können:

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

Die Daten in diesem Beispiel werden oft als „dummes“ Datenmodell bezeichnet. Sein Hauptzweck besteht einfach darin, Informationen ohne komplexe Logik zu speichern. Trotz seiner Einfachheit ist dies ein Fortschritt, da die für den Betrieb der Komponente erforderlichen Daten intern gespeichert werden und die Verwendung globaler Variablen vermieden wird.

Indem wir die Daten innerhalb der Komponente halten, stellen wir sicher, dass sie vom externen System isoliert sind, was bedeutet, dass die Komponente unabhängig funktionieren kann. Um die Kapselung der Daten hervorzuheben, stellen wir dem Eigenschaftsnamen außerdem einen Unterstrich voran. Diese Konvention signalisiert, dass die Immobilie nur für den internen Gebrauch bestimmt ist und nicht von außen darauf zugegriffen werden sollte.

Was kann man mit diesem „dummen“ Modell innerhalb einer Komponente noch erreichen? Eine nützliche Funktion ist das Caching. Durch die Speicherung von Daten innerhalb der Komponente können wir unnötige Neuberechnungen, redundante Netzwerkanfragen oder andere ressourcenintensive Vorgänge vermeiden. In unserem Beispiel ermöglicht das Speichern des vorherigen Berechnungsergebnisses die Implementierung einer Rückgängig-Funktion, was die Leistung und das Benutzererlebnis verbessert.

Dickes Modell

Ist das „dumme“ Datenmodell eine universelle Lösung für alle Fälle? Bei der Arbeit mit einfachen Komponenten kann es durchaus ausreichen. Dieses Modell ist einfach zu implementieren und bewältigt grundlegende Datenspeicher- und -verarbeitungsaufgaben gut. Da jedoch die Logik der Komponenten komplexer wird, wird die Aufrechterhaltung des „dummen“ Modells immer schwieriger. Wenn eine Komponente mehrere Datenoperationen umfasst, einschließlich Änderung und Analyse, ist es sinnvoll, die Struktur zu vereinfachen, indem diese Logik in verschiedene Klassen unterteilt wird. Ein solcher Ansatz besteht darin, ein „dickes“ Datenmodell zu verwenden, um alle datenbezogenen Prozesse von der Komponente selbst zu isolieren.

Betrachten wir ein Beispiel. Ein „dickes“ Modell kann durch eine separate Klasse dargestellt werden, die die Daten speichert und Methoden zu deren Änderung bereitstellt. Innerhalb dieses Modells können wir nicht nur das Ergebnis und den vorherigen Wert speichern, sondern auch Hilfslogik hinzufügen, z. B. das automatische Speichern des vorherigen Ergebnisses vor allen Berechnungen. Dies vereinfacht die Komponente erheblich und befreit sie von der direkten Verwaltung der Daten.

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

Durch die Verwendung des dicken Modells kapseln wir nicht nur die Daten innerhalb der Komponente, sondern verbergen auch einige Verhaltensweisen vor der Komponente selbst. Die Komponente kennt nun weder die Datenstruktur noch die Details, wie Daten festgelegt, geändert und abgerufen werden. Das eigene Verhalten wird vereinfacht.

Mit der Einführung des dicken Modells übernimmt die Komponente die Rolle eines Controllers. Es verwaltet das Modell, muss aber dessen Innenleben nicht kennen. Dadurch ist die Komponente nicht mehr von der Datenstruktur oder den zu ihrer Verarbeitung verwendeten Methoden abhängig. Alles, was es wissen muss, ist die Schnittstelle des Modells – die Menge der Methoden, die es bereitstellt. Dieser Ansatz ermöglicht den einfachen Austausch eines Modells durch ein anderes.

Darüber hinaus wird das dicke Modell wiederverwendbar: Es kann nun nicht nur in einer Komponente, sondern auch in anderen verwendet werden, sofern diese mit ähnlichen Daten arbeiten.

Für noch mehr Flexibilität kann das Adaptermuster verwendet werden. Dieses Muster stellt die Kompatibilität zwischen der Komponente und dem Modell sicher, auch wenn sich deren Schnittstellen zunächst unterscheiden. Wenn eine Komponente beispielsweise ein Modell mit zusätzlicher Logik erfordert, können wir einen Adapter erstellen, um diese Logik hinzuzufügen und gleichzeitig die gemeinsame Schnittstelle beizubehalten.

class SimpleCalculator extends HTMLElement {

  constructor() {
    super();
    this._data = {
      result: 0,
      previous_result: 0
    };
    …
  }
  undo(){
    this._data.result = this.data.previous_result;
  }
  add(value) {
    this._data.previous_result = this.data.result;
    this._data.result += value;
  }
  …
  displayResult() {
    this.innerHTML = `<p>The result is: ${this._data.result}</p>`;
  }
  …
}

Damit nun eine andere Komponente mit demselben Modell funktioniert, reicht es aus, diesen Adapter zu verwenden. Wenn wir ein anderes Modell verwenden müssen, können wir entweder dessen Erstellungsmethode überschreiben oder einen anderen Adapter anschließen. Dadurch wird sichergestellt, dass die Komponente unverändert bleibt, während ihr Verhalten durch das Modell gesteuert wird, mit dem sie verbunden ist.

Somit werden durch die Aufteilung der Logik in ein dickes Datenmodell mehrere wichtige Ziele erreicht. Erstens wird die Komponente leichter und verständlicher, sodass nur noch Verwaltungsaufgaben anfallen. Zweitens wird das Modell zu einem unabhängigen und wiederverwendbaren Element innerhalb des Systems. Drittens gewährleistet die Verwendung von Mustern wie dem Adapter Flexibilität und Skalierbarkeit, sodass sich die Datenverarbeitungslogik an sich ändernde Anforderungen anpassen kann. Während dies in einfacheren Fällen übertrieben erscheinen mag, legt es den Grundstein für den Aufbau komplexerer und stabilerer Architekturen in der Zukunft.

Zersetzung von SSOT

Lassen Sie uns die Möglichkeit erkunden, in Bezug auf die Organisation von Komponenten und deren Interaktion noch weiter zu gehen. Zuvor haben wir diskutiert, wie die Autonomie von Elementen ihre Integration in verschiedene Teile einer Anwendung vereinfacht und sie für die Wiederverwendung in anderen Projekten geeignet macht. Die Autonomie der Komponenten eröffnet jedoch eine weitere interessante Chance: Sie ermöglicht die Zerlegung und teilweise Verschiebung der globalen Single Source of Truth (SSOT) in einzelne Komponenten. Das bedeutet, dass wir statt eines globalen SSOT im System mit lokalen SSOTs arbeiten können, die einen Teil der Logik und Daten kapseln.

Die Idee ist, dass wir durch die Aufteilung der globalen Wahrheitsquelle in lokale Komponenten erstellen können, die nicht nur in ihren visuellen Aspekten autonom sind, sondern auch über ihre eigene lokale Logik verfügen, die zur Erfüllung ihrer Aufgaben erforderlich ist. Diese Komponenten sind nicht mehr nur visuelle Elemente, sondern werden zu unabhängigen Minisystemen, die ihre eigenen Daten und ihr eigenes Verhalten verwalten. Dadurch wird ihre Unabhängigkeit vom Rest der Anwendung deutlich erhöht, was wiederum die Stabilität verbessert und die Weiterentwicklung des Systems vereinfacht.

Außerdem sind wir, wenn wir über Komponenten sprechen, nicht auf kleine UI-Elemente wie Schaltflächen, Tabellen oder Diagramme beschränkt. Eine Komponente kann sich auf komplexere und größere Anwendungselemente beziehen, beispielsweise auf ein Einstellungsfeld, das mehrere verschiedene Funktionen kombiniert, ein Registrierungs- oder Dateneingabeformular oder sogar einen Abschnitt mit mehreren interaktiven Diagrammen. Jede dieser Komponenten kann über eine eigene lokale Wahrheitsquelle verfügen, die den Zustand und die Logik nur innerhalb dieses spezifischen Elements verwaltet.

Die Zerlegung von SSOT in lokale Teile vereinfacht die Verwaltung des Status einer Anwendung. Anstatt beispielsweise eine globale Quelle der Wahrheit für alle Formularelemente zu verwenden, können wir den Zustand innerhalb des Formulars kapseln und so seine Unabhängigkeit von anderen Teilen der Anwendung sicherstellen. Dies reduziert nicht nur die Komplexität der Entwicklung, sondern macht das System auch flexibler, da Komponenten ausgetauscht oder geändert werden können, ohne dass Änderungen an der globalen Logik erforderlich sind.

Dieser Ansatz für das Architekturdesign ist besonders nützlich bei großen Anwendungen, bei denen die globale Logik überlastet werden kann und Änderungen an einem Teil davon kaskadierende Auswirkungen auf das gesamte System haben können. Lokale Quellen der Wahrheit tragen dazu bei, solche Risiken zu minimieren, indem sie isolierte Verantwortungsbereiche schaffen, was die Wartung vereinfacht und die Lesbarkeit des Codes verbessert.

Abschluss

Die Fähigkeit von Webkomponenten, ihre eigenen Daten zu speichern, ermöglicht es uns, sie als mehr als nur einfache visuelle Elemente der Benutzeroberfläche zu betrachten. Jetzt können sie als eigenständige Module betrachtet werden, die Daten, Logik und Präsentation integrieren. Dieser Ansatz macht Komponenten zu einem effektiven Werkzeug zum Aufbau einer Anwendungsarchitektur. Sie können komplexes Verhalten kapseln, ihren internen Zustand verwalten und Interaktionen mit anderen Elementen des Systems auf einer höheren Ebene organisieren. Dadurch werden Webkomponenten zu einem vielseitigen Werkzeug zum Erstellen flexibler und skalierbarer Anwendungen.

Um den hier beschriebenen Ansatz weiterzuentwickeln und meine eigenen Aufgaben rund um die Schnittstellenerstellung deutlich zu vereinfachen, habe ich die KoiCom-Bibliothek entwickelt, die auf Datenmanagement und Datentransfer zwischen Komponenten basiert.

KoiCom-Dokumentation
KoiCom Github

Letztendlich hoffe ich, dass solche Lösungen Entwicklern dabei helfen werden, einen moderneren Ansatz für das Schnittstellendesign zu verfolgen, wodurch Anwendungen skalierbarer und einfacher zu warten sind.

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