データモデルとWebコンポーネント

これを想像してください: Web コンポーネントについては、おそらく何度も聞いたことがあるでしょう。Web コンポーネントの魔法、Shadow DOM を介して分離する独自の機能です。無数の記事、終わりのないウェビナーがあり、Web 開発コミュニティ全体がスタイルとマークアップの分離という 1 つのことだけに集中しているように感じられます。しかし、これは氷山の一角にすぎないと言ったらどうなるでしょうか? Web コンポーネントには、Shadow DOM をはるかに超えて拡張できる、はるかに多くの機能がある?

今日は、表面を超えて、見過ごされがちな事柄、つまり Web コンポーネントがデータを処理する方法に光を当てたいと思います。なぜこのトピックはそれほど注目されていないのでしょうか?おそらくそれは、公式仕様がこの可能性を強調していないためです。しかし、一度調査を始めると、どれだけ見落とされているかに気づくでしょう。

ゆっくりと始めて少し退屈になる場合は、あらかじめお詫び申し上げます。目の前のタスクに必要です。

Web コンポーネントにデータが必要な理由

Web コンポーネントは、システムの他の部分から独立して機能できる自己完結型の要素として設計されています。この自律性により、アプリケーションのさまざまな領域への統合が簡素化され、さまざまなプロジェクト間で簡単に再利用できるようになります。この独立性の鍵となるのはカプセル化です。これにより、コンポーネントの外観だけでなく内部の動作も隠蔽されます。この動作は、コンポーネントがデータを管理および使用する方法と密接に関係しています。

たとえば、基本的な算術演算を実行するように設計された計算機コンポーネントについて考えてみましょう。このコンポーネントは、現在の結果の表示、前の結果の保存、計算の実行などの動作を管理します。これを実現するために、現在の結果、前の結果、入力値の制限などの設定などのデータが維持されます。

Web コンポーネントが使用するデータは、「ローカル状態」として説明できます。このローカル状態には、コンポーネントの動作に必要な情報が保存されます。これには、コンポーネント内の特定のタスクを実行するために必要な一時データ、中間計算結果、またはその他の値が含まれる場合があります。

まず、コンポーネントのプロパティが基本データを保存する方法の簡単な例を見てみましょう。

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>`;
  }
  …
}

この例のデータは、「ダム」データ モデルと呼ばれることがよくあります。その主な目的は、複雑なロジックを必要とせずに情報を保存することだけです。シンプルであるにもかかわらず、コンポーネントの操作に必要なデータが内部に保存され、グローバル変数の使用が回避されるため、これは一歩前進です。

データをコンポーネント内に保持することで、データが外部システムから確実に分離され、コンポーネントが独立して機能できるようになります。さらに、データのカプセル化を強調するために、プロパティ名の先頭にアンダースコアを付けます。この規則は、プロパティが内部使用のみを目的としており、外部からアクセスすべきではないことを示します。

それでは、コンポーネント内のこの「ダム」モデルを使用して他に何が達成できるでしょうか?便利な機能の 1 つはキャッシュです。コンポーネント内にデータを保存することで、不必要な再計算、冗長なネットワーク要求、またはその他のリソースを大量に消費する操作を回避できます。この例では、前の計算結果を保存することで元に戻す機能を実装できるため、パフォーマンスとユーザー エクスペリエンスが向上します。

太いモデル

「ダム」データ モデルは、すべてのケースに適用できる普遍的なソリューションですか?単純なコンポーネントを扱う場合には、確かにこれで十分です。このモデルは実装が簡単で、基本的なデータの保存と処理のタスクを適切に処理します。ただし、コンポーネントのロジックが複雑になるにつれて、「ダム」モデルを維持することがますます困難になります。コンポーネントに変更や分析などの複数のデータ操作が含まれる場合、このロジックを個別のクラスに分離して構造を簡素化することが合理的です。そのようなアプローチの 1 つは、「厚い」データ モデルを使用して、すべてのデータ関連プロセスをコンポーネント自体から分離することです。

例を考えてみましょう。 「シック」モデルは、データを保存し、それを変更するためのメソッドを提供する別のクラスによって表すことができます。このモデル内では、結果と前の値を保存できるだけでなく、計算の前に前の結果を自動的に保存するなどの補助ロジックを追加することもできます。これによりコンポーネントが大幅に簡素化され、データを直接管理する必要がなくなりました。

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>`;
  }
  …
}

シック モデルを使用することにより、コンポーネント内のデータをカプセル化するだけでなく、コンポーネント自体から動作の一部を隠すこともできます。コンポーネントは、データ構造と、データの設定、変更、取得方法の詳細の両方を認識しなくなりました。自身の動作は簡略化されています。

シック モデルの導入により、コンポーネントはコントローラーの役割を引き受けます。モデルを管理しますが、その内部の仕組みを知る必要はありません。その結果、コンポーネントはデータ構造やその処理に使用されるメソッドに依存しなくなります。知っておく必要があるのは、モデルのインターフェイス、つまりモデルが提供するメソッドのセットだけです。このアプローチにより、あるモデルを別のモデルに簡単に置き換えることができます。

さらに、シック モデルは再利用可能になり、同様のデータを扱う場合には、1 つのコンポーネントだけでなく他のコンポーネントでも使用できるようになります。

柔軟性をさらに高めるために、アダプター パターンを使用できます。このパターンにより、コンポーネントとモデルのインターフェイスが最初は異なっていたとしても、コンポーネントとモデル間の互換性が保証されます。たとえば、コンポーネントに追加のロジックを含むモデルが必要な場合、共通のインターフェイスを維持しながら、このロジックを追加するアダプターを作成できます。

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>`;
  }
  …
}

別のコンポーネントを同じモデルで動作させるには、このアダプターを適用するだけで十分です。別のモデルを使用する必要がある場合は、その作成メソッドをオーバーライドするか、別のアダプターを接続できます。これにより、コンポーネントは変更されず、その動作は接続先のモデルによって制御されます。

このように、ロジックを厚いデータ モデルに分離することで、いくつかの重要な目標が達成されます。まず、コンポーネントが軽量になり、理解しやすくなり、管理タスクだけが残ります。次に、モデルはシステム内で独立した再利用可能な要素になります。 3 番目に、アダプターのようなパターンを使用すると、柔軟性と拡張性が確保され、データ処理ロジックが変化する要件に適応できるようになります。これは、単純な場合には過剰に見えるかもしれませんが、将来的により複雑で安定したアーキテクチャを構築するための基礎を築きます。

SSOTの分解

コンポーネントとその相互作用の整理という点でさらに前進する可能性を探ってみましょう。以前、要素の自律性により、アプリケーションのさまざまな部分への統合がどのように簡素化され、他のプロジェクトでの再利用に適したものになるかについて説明しました。ただし、コンポーネントの自律性により、別の興味深い機会が開かれます。これにより、グローバルな単一の真実の情報源 (SSOT) を分解し、それを部分的に個別のコンポーネントに移行することが可能になります。これは、システム内に 1 つのグローバル SSOT を設ける代わりに、ロジックとデータの一部をカプセル化するローカル SSOT を操作できることを意味します。

そのアイデアは、グローバルな真実のソースをローカルなソースに分割することで、視覚的な側面で自律的なだけでなく、タスクの実行に必要な独自のローカル ロジックを持つコンポーネントを作成できるということです。これらのコンポーネントは単なる視覚要素ではなくなり、独自のデータと動作を管理する独立したミニシステムになります。これにより、アプリケーションの残りの部分からの独立性が大幅に高まり、安定性が向上し、システムの進化が簡素化されます。

さらに、コンポーネントについて話すときは、ボタン、テーブル、グラフなどの小さな UI 要素に限定されません。コンポーネントは、複数の異なる機能を組み合わせた設定パネル、登録またはデータ入力フォーム、さらには複数の対話型チャートを含むセクションなど、より複雑で大規模なアプリケーション要素を参照する場合があります。これらの各コンポーネントは、その特定の要素内でのみ状態とロジックを管理する独自のローカルな信頼できる情報源を持つことができます。

SSOT をローカル部分に分解すると、アプリケーションの状態の管理が簡素化されます。たとえば、すべてのフォーム要素に対してグローバルな信頼できる情報源を使用する代わりに、フォーム内に状態をカプセル化し、アプリケーションの他の部分からの独立性を確保できます。これにより、開発の複雑さが軽減されるだけでなく、システムがより柔軟になり、グローバル ロジックを変更することなくコンポーネントを交換または変更できるようになります。

このアーキテクチャ設計のアプローチは、グローバル ロジックが過負荷になり、その一部への変更がシステム全体に連鎖的な影響を与える可能性がある大規模なアプリケーションで特に役立ちます。ローカルの信頼できる情報源は、責任の孤立した領域を作成することで、そのようなリスクを最小限に抑えるのに役立ちます。これにより、メンテナンスが簡素化され、コードの可読性が向上します。

結論

Web コンポーネントが独自のデータを保存できるため、Web コンポーネントを単なるインターフェースの単純な視覚要素以上のものとして見ることができます。現在、これらは、データ、ロジック、プレゼンテーションを統合する自己完結型モジュールと考えることができます。このアプローチにより、コンポーネントはアプリケーション アーキテクチャを構築するための効果的なツールになります。これらは、複雑な動作をカプセル化し、内部状態を管理し、システムの他の要素との相互作用をより高いレベルで組織化することができます。これにより、Web コンポーネントが柔軟でスケーラブルなアプリケーションを作成するための多用途ツールに変わります。

ここで説明するアプローチをさらに発展させ、インターフェース作成に関連する私自身のタスクを大幅に簡素化するために、データ管理とコンポーネント間のデータ転送に基づいたKoiComライブラリを開発しました。

KoiCom ドキュメント
コイコム github

最終的には、このようなソリューションが、開発者がインターフェイス設計に対してより現代的なアプローチを採用し、アプリケーションのスケーラビリティを高め、保守を容易にするのに役立つことを願っています。

以上がデータモデルとWebコンポーネントの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。