インターフェイスの設(shè)計(jì)を始めると、イベント ハンドラーがボタンに直接アタッチされ、コンポーネントの対話の柔軟性が制限されるという問(wèn)題に常に遭遇します。問(wèn)題は、標(biāo)準(zhǔn)ボタンでは他の動(dòng)作が提供できないことです。私が必要としているのは、ロジックの分離と動(dòng)的なアクション管理ですが、「そのままの狀態(tài)」の標(biāo)準(zhǔn)ボタンを使用する場(chǎng)合には利用できません。この記事では、Web コンポーネントと「コマンド」パターンを使用してボタンを適応させる方法についてのソリューションを提案し、より柔軟でスケーラブルなインターフェイスの新たな可能性を開(kāi)きます。

ボタンは見(jiàn)た目以上のものです

通常、ボタンについて考えるとき、何らかのイベント、アクション、またはインターフェイスの狀態(tài)の変化をトリガーする簡(jiǎn)単な方法を提供するグラフィカル コントロール要素として認(rèn)識(shí)されます。これは非常に簡(jiǎn)単で便利な定義であり、Web アプリケーションのユーザー インターフェイス要素についての日常的な理解に適合します。

しかし、HTML と JavaScript が関係する Web 開(kāi)発のコンテキストでボタンに遭遇したとき、最初に思い浮かぶのは、Web ページ上でボタンを作成するために最も一般的に使用されるツールである標(biāo)準(zhǔn)タグです。このタグは通常次のようになります:

<button onclick="myFunction()">Click me</button>

しかし、よく考えてみると、このタグはボタンとして機(jī)能しますが、インターフェイスとのユーザー インタラクションというより広範(fàn)なコンテキストでボタンが実行できるすべての可能な側(cè)面と機(jī)能を完全に反映しているわけではありません。

ボタンの定義を詳しく調(diào)べると、ボタンがどのように見(jiàn)えるか、どのように動(dòng)作するか、またはどのようにアクションをトリガーするかについての情報(bào)がまったく提供されていないことに気づくかもしれません。この文脈では、アクションをトリガーする「簡(jiǎn)単な方法」という言葉が何を意味するのか、ボタンとアクションの間の接続がどのように確立されるのかが明確に理解されていません。ここでは、クリックされると何らかのメソッドが呼び出されるボタンの基本構(gòu)造のみを確認(rèn)します。しかし実際には、このシンプルさの中に、より幅広い可能性とアプローチが隠されています。そこで、次のような疑問(wèn)が生じます。おそらくボタンは、上の例にある?yún)gなるタグではないのでしょうか?

アクションをトリガーする簡(jiǎn)単な方法

より哲學(xué)的な観點(diǎn)からボタンの概念にアプローチし、その本質(zhì)と機(jī)能を詳しく掘り下げてみましょう。ボタンは実際には何を表しているのでしょうか?水差しの本質(zhì)を空であると考えると、ボタンの本質(zhì)はアクションを開(kāi)始する能力にあります。ボタンは単なるユーザー インターフェイス要素ではありません。これは、アプリケーションのコンテキスト內(nèi)にすでに存在する特定のプロセスをトリガーするメカニズムです。実行されるアクションはアプリケーション內(nèi)、システム全體のコンテキスト內(nèi)で発生しますが、そのアクションの開(kāi)始、つまり開(kāi)始はボタンの機(jī)能です。したがって、ボタンは一種のトリガーとして機(jī)能し、より広範(fàn)な外部システム コンテキストでアクションを起動(dòng)することがわかります。

ユーザーはボタンをクリックするとき、このクリックが特定のアクションにつながることを期待します。したがって、ボタンにはこのアクションを開(kāi)始する責(zé)任があると考えられます。言い換えれば、ボタンはユーザーとその後のアクションとの間のリンクになります。ただし、アクションを?qū)g際に実行するメソッドまたは関數(shù)は、アクションをトリガーしたボタンであることを認(rèn)識(shí)すべきではないことに注意することが重要です。アクションを開(kāi)始するものとそれを?qū)g行するもののこの區(qū)別は、より複雑なシステムにおいて柔軟性と対話の容易さを維持できるようにする重要な側(cè)面です。

ボタンがアクションを直接実行する場(chǎng)合、またはアクションを?qū)g裝するメソッドがボタン自體に依存する場(chǎng)合、かなり複雑で相互依存するシステムを扱うことになります。このようなシステムを簡(jiǎn)素化したい場(chǎng)合は、より単純な獨(dú)立した部分に分割する必要があります。そしてここで、アクションを開(kāi)始するプロセスを簡(jiǎn)素化するには、主に開(kāi)始プロセスをアクション自體から分離することが必要であると結(jié)論付けます。また、JavaScript のコンテキストでは、イニシエーターはイベントと呼ばれることが多いため、特に、アクションを?qū)g行するロジックからイニシエーターとしてのイベントを分離することについて話しています。

イベントとハンドラーの分離

イベントをハンドラーから分離することが重要なのはなぜですか?

まず第一に、イベントをハンドラーから分離すると、コードの可読性が大幅に向上し、よりモジュール化されたソリューションの作成が促進(jìn)されます。ボタンのロジックとそのハンドラーが絡(luò)み合っている場(chǎng)合、またはさらに悪いことに、ハンドラーが匿名関數(shù)である場(chǎng)合、コードの読み取りと分析が非常に困難になります。これにより、ボタンが実際に何を行うのか、どのような変更が必要なのかを理解することが困難な作業(yè)となるため、プロジェクトの保守および更新時(shí)に問(wèn)題が発生する可能性があります。対照的に、ハンドラーが、実行されるアクションを明確に反映する適切な名前の別個(gè)の関數(shù)に抽出されると、コードの構(gòu)造がより透明になります。開(kāi)発者は、ボタンがクリックされたときに何が起こるかをすぐに理解し、ロジックの殘りの部分を詳しく調(diào)べることなく、要素の動(dòng)作をより簡(jiǎn)単に変更できます。したがって、分離すると、コードの読み取りと変更の両方が簡(jiǎn)素化されます。

2 番目に、イベント ロジックとハンドラーを分離すると、アプリケーションのさまざまな部分でハンドラーを再利用できる機(jī)會(huì)が広がります。ハンドラーを獨(dú)自の関數(shù)に配置すると、1 つのボタンだけでなく、同様の動(dòng)作を持つ他の多くのボタンに適用できます。たとえば、同じアクションを?qū)g行する複數(shù)のボタンで同じハンドラーを使用できるため、コードの重複が減り、効率が向上します。さらに、ハンドラーはボタン経由だけでなく、プログラムによる呼び出しやインターフェイスの他の部分によって開(kāi)始されるアクションなどの他の手段を通じてもトリガーできます。これにより、アプリケーションの機(jī)能が大幅に拡張され、柔軟性と拡張性が向上します。

第三に、イベントとハンドラーを分離することで、ボタン自體の柔軟性が高まります。ボタンの動(dòng)作がボタン自體ではなく別のハンドラーを介して決定されるようになった場(chǎng)合、狀況に応じてアクションを変更したり再割り當(dāng)てしたりすることが簡(jiǎn)単になります。これは、ユーザーのアクションやアプリケーションの狀態(tài)の変化に応じて要素の動(dòng)作が変化する可能性がある、動(dòng)的インターフェイスを備えたプロジェクトでは特に重要です。このアプローチにより、コード構(gòu)造全體を中斷することなく、進(jìn)化する要件にインターフェースを簡(jiǎn)単に適応させることができます。

第 4 に、イベントとハンドラーの分離は、特に大規(guī)模なプロジェクトにおいて、テストを容易にするために非常に重要です。イベント ハンドラーが別個(gè)の関數(shù)に抽出されると、インターフェイスから獨(dú)立してテストできるため、テストがはるかに簡(jiǎn)単になります。インターフェースの他の部分との相互作用を気にせずに、ハンドラーを分離し、さまざまなパラメーターを使用してハンドラーがどのように動(dòng)作するかをテストできます。これによりテストが容易になり、エラーの可能性を最小限に抑えながらアプリケーションの信頼性と安定性が向上します。

ボタン イベントとハンドラーを分離することは、よりクリーンで、より柔軟で、保守しやすいコード アーキテクチャに向けた重要なステップです。これは、インターフェイス要素間の相互作用がより複雑で相互依存する複雑なプロジェクトでは特に重要です。このアプローチは、システムの安定性を向上させ、アプリケーションの拡張と変更を容易にし、これらの変更中に発生するエラーのリスクを軽減します。

ボタンのイベントをそのハンドラーから分離する例は、初心者向けガイドに記載されています。

<button onclick="myFunction()">Click me</button>

ボタンがインタラクションのコンテキストだけでなく、イベント內(nèi)でユーザーの意図も明示的に伝えることができれば、アーキテクチャが大幅に簡(jiǎn)素化されるでしょう。ハンドラーは、ロジックをイベントに割り當(dāng)てるのではなく、タスクの実行に集中できます。

これは、ボタンを単なるイベントイニシエーターとしての従來(lái)の理解から脫卻する必要性を強(qiáng)調(diào)しています。代わりに、ボタンがユーザーの意図とアプリケーション ロジックの間のブリッジとして機(jī)能する、より高度なモデルを採(cǎi)用することを提案しています。

コマンドパターンの使用

イベント処理のためのより高度なモデルを作成するには、コマンド パターンを利用できます。これにより、イベントをより高い抽象レベルでアプリケーション ロジックにリンクできます。これは、通常のイベントを saveDocument や deleteItem などのコマンドに変換するレイヤーを?qū)毪工毪长趣菍g現(xiàn)できます。このアプローチを使用すると、イベントは、何かが発生したことを示す単なる信號(hào)ではなく、記事の前半で説明したように、イベントの本來(lái)の姿、つまりアクションの開(kāi)始者に変換されます。

しかし、これで疑問(wèn)が生じます。なぜ JavaScript イベントの開(kāi)発者は最初からコマンド パターンを?qū)g裝しなかったのでしょうか?なぜイベントは現(xiàn)在のように設(shè)計(jì)されたのでしょうか?そもそもなぜイベントが必要だったのでしょうか?

HTML と、DOM や JavaScript などの関連テクノロジが最初に開(kāi)発されたとき、その主な目標(biāo)は、ユーザーが Web ページと対話できるようにするハイパーテキスト ドキュメントの単純な構(gòu)造を作成することでした。當(dāng)時(shí)、ユーザーの対話は大幅に制限されており、イベント処理モデルはコマンド パターンなどの複雑なメカニズムに対応するように設(shè)計(jì)されていませんでした。初期の Web は、複雑なクライアント側(cè)ロジックに高度なツールを提供するためではなく、コンテンツの作成と管理を簡(jiǎn)素化するために開(kāi)発されたことを理解することが重要です。

HTML と Web が作成されていた 1990 年代、彼らは最小限のユーザー操作でハイパーテキスト ドキュメントを表示する簡(jiǎn)単な方法を提供することに重點(diǎn)を置いていました。主な目標(biāo)は、ブラウザ內(nèi)で複雑なロジックを?qū)g行するのではなく、サーバーにデータを送信することでした。ボタンとフォームは主にデータを送信するために使用され、クライアント側(cè)のプロセスを開(kāi)始するために使用されませんでした。すべての計(jì)算とデータ処理はサーバー上で処理され、ボタンはバックエンドへのデータ送信をトリガーするインターフェイス要素として機(jī)能しました。

コマンド パターンには、インターフェイスと処理ロジックを明確に分離する、実行される正確なアクションを指定するメカニズムを含む、より洗練された構(gòu)造が必要です。これらのアイデアは、Web アプリケーションにおける動(dòng)的なインターフェイスとより優(yōu)れた対話性の必要性が高まるにつれて、後になって初めて意味を持つようになりました。イベントを通じてクライアント側(cè)ロジックをトリガーするなど、動(dòng)的で複雑な対話には、コマンド パターンの採(cǎi)用などの新しいアプローチが必要でした。

コマンド パターンは今すぐボタンに適用できますか?はい、できます。標(biāo)準(zhǔn)の HTML ボタンはコマンド パターンを直接サポートしていませんが、カスタム イベントなどの最新のテクノロジーを使用すると、同様のメカニズムを作成できます。たとえば、詳細(xì)プロパティを使用してイベントで追加データを渡す方法についてはすでに検討しました。

ただし、インターフェース內(nèi)のボタンごとに個(gè)別の実裝を作成する必要があるため、このアプローチはまだ理想的ではありません。これにより、さらに複雑さが増し、そのようなシステムの拡張がより困難になります。

Webコンポーネント

Web コンポーネントを活用してボタンを最新化し、コマンド パターンに合わせるのは、プロジェクト內(nèi)のインタラクションのアーキテクチャと柔軟性の両方を大幅に強(qiáng)化できる有望なアプローチです。 Web コンポーネントは、アプリケーションのさまざまな部分にシームレスに統(tǒng)合できる再利用可能なインターフェイス要素を作成するための強(qiáng)力なツールを提供します。

ボタンごとに個(gè)別のハンドラーを作成する代わりに、コマンドを渡す機(jī)能を追加したボタンとして機(jī)能する統(tǒng)合コンポーネントを作成できます。このアプローチにより、コードの構(gòu)造が改善されるだけでなく、コードの可読性と保守性も向上します。

そのようなコンポーネントの基本的な例を次に示します:

<button onclick="myFunction()">Click me</button>

ボタンコンポーネントとコントローラー

ボタン コンポーネントがコマンド識(shí)別子と場(chǎng)合によっては追加パラメータを送信すると、より高度なアーキテクチャの基盤(pán)が確立されます。この設(shè)定では、ボタンを含み、そのイベントをサブスクライブするコンポーネントは、基本的に、イベントを介して渡されたコマンドを処理するコントローラーとして機(jī)能します。

MVC (Model-View-Controller) などのアーキテクチャ パターンでは、コントローラーはデータを表すモデルとユーザー インターフェイスを構(gòu)成するビューの間の仲介者として機(jī)能します。ボタンのクリックなどのユーザー入力を受け取り、その結(jié)果生じるデータまたは狀態(tài)の変更を管理し、インターフェースに反映します。

コンポーネント內(nèi)でコントローラーを使用すると、いくつかの重要な利點(diǎn)が得られます。まず、コマンドを?qū)g行するためのロジックをカプセル化し、メイン アプリケーション コードを不必要な複雑さから解放します。実裝の詳細(xì)はコントローラー自體の中に隠されたままになります。第 2 に、このアプローチによりモジュール性が強(qiáng)化され、さまざまなコマンドとパラメータを渡すだけでボタンを再利用できるようになります。また、コマンド処理ロジックの変更には、システムの他の部分に影響を與えることなく、コントローラー內(nèi)でのみ変更が必要となるため、アプリケーション內(nèi)の結(jié)合も軽減されます。最後に、コントローラーは大幅な柔軟性を提供します。 「保存」や「削除」などの単純なコマンドと、より複雑なアクションの両方を処理できますが、ボタン コンポーネントはシンプルなままで、その主な役割だけに焦點(diǎn)を當(dāng)てています。

このアーキテクチャにより、懸念事項(xiàng)の明確な分離が容易になります。ボタン コンポーネントはコマンドとその関連データを含むカスタム イベントを発行し、コントローラーとして機(jī)能する親コンポーネントはこのイベントをリッスンします。コントローラーはコマンドを処理し、必要に応じてデータ モデルと対話し、それに応じてユーザー インターフェイスを更新します。このアプローチにより、ボタン コンポーネントを再利用可能に保ち、ボタン コンポーネントがトリガーするロジックから獨(dú)立した狀態(tài)に保ちながら、拡張と保守が容易な、よりクリーンでスケーラブルなアーキテクチャが実現(xiàn)します。

結(jié)論

結(jié)論として、ボタンがアクションをトリガーするだけでなく、イベントを通じて必要なデータを含むコマンドを送信するアプローチは、「コマンド」パターンを適用する優(yōu)れた例です。この方法では、コマンド実行のロジックをインターフェイス要素から分離することでインターフェイスの対話構(gòu)成が大幅に改善され、アプリケーションの柔軟性と拡張性が強(qiáng)化されます。

しかし、このようなアプローチは実際にはまだ比較的一般的ではありません。多くの開(kāi)発者は、Web コンポーネントの強(qiáng)力な機(jī)能を活用して汎用的で柔軟なソリューションを作成する代わりに、イベント ハンドラーに直接関連付けられた標(biāo)準(zhǔn)ボタンに依存し続けています。これはおそらく習(xí)慣と、このアプローチの利點(diǎn)に対する認(rèn)識(shí)の欠如が原因で、アクションの単純なトリガーとしてボタンをより従來(lái)的に使用することにつながっていると考えられます。

この狀況を変えることを決意して、私はKoiComライブラリを開(kāi)発しました。このライブラリでは、多くのコンポーネントがすでに適応および強(qiáng)化されています。特に、このライブラリのボタンは「コマンド」パターンに従い、必要なデータとコマンドをイベント経由で送信します。このアプローチにより、モジュール性、柔軟性、保守性が大幅に向上し、冗長(zhǎng)なロジックが排除され、コマンドの管理方法が簡(jiǎn)素化されます。

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

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

以上が次世代ボタン: Web コンポーネントを介したコマンド パターンの実裝の詳細(xì)內(nèi)容です。詳細(xì)については、PHP 中國(guó)語(yǔ) Web サイトの他の関連記事を參照してください。