はじめに
現在、ますます多くのJavaScriptフレームワークが登場していますが、これは現在流行しているjQueryとは少し異なります。 MVCを実装しようとするもの、高度に結合されたアーキテクチャを提供するもの、非同期を目的とするものなどがあります。 各開発者は、自分に最も近いものと、タスクを最も効果的に解決するものを選択します。 したがって、フレームワークの長所または短所については説明しませんが、製品で何が生じたのか、どの概念が開発され、どの問題が解決されたのかを説明します。
おそらく、タスクから始めましょう。 SaaS、大量のデータを処理する情報分析システムを構築しました。 ユーザーは1回の要求でかなりの量の情報を受け取ることができますが、同時に特定の情報ブロックを調整してさらに詳細なレベルに移動することもできます。 マルチページアプリケーションの古典的なスキームを構築した場合、データベースからのデータ取得の悲しい速度、大量の送信トラフィックが得られますが、最も重要なことは、要求への応答を待機するために可能な限り短い時間を必要とする市場のニーズを満たしていないことです。 したがって、データがオンデマンドでロードされ、特定の時間にユーザーが必要とする部分のみがロードされる場合、1ページのアプリケーションを構築するためのモデルを選択しました。 彼らは1つの石で3羽の鳥を殺しました。
シングルページアプローチの問題
このようなアプリケーションでは、コードを整理するための特別なアプローチが必要です。 複数ページのアプリケーションの世界に馴染みのあるいくつかの標準ソリューションは、単一ページのアプローチで横に出ます。 しばらくして、ユーザーが意図した目的でプログラムを使用して、合計10,000個のタグをドキュメントに読み込んだとします。 jQueryアプローチ（ドキュメント全体から必要なアプローチを選択する）は、作業の速度を大幅に低下させる可能性があります。 もちろん、セレクターの可視性を減らすことはできますが、これは常に可能であるとは限らず、追加の骨の折れる最適化が必要です。
改訂が必要な別のアプローチは、モジュール自体を構築するためのモデルでした。 HTMLに関してはMVCから逃げようとしましたが、それは非常に疑わしい効率性でかなりの量の作業を必要としたためです。 モジュールは疎結合である必要があり、相互に直接通信する手段はありません。 データを保存する場所 これにHTMLを使用しないのはなぜですか。 DOMは、実際には既成のモデルであるデータ構造を操作するためのスマートで便利なツールを提供します。
これらすべてを縫い合わせる「糸」を見つけることは残っていました。 私に起こった唯一のオプションは、イベントモデルを使用することでした。 これがStateController v2の由来です。
イベントモデルはどのように機能しますか？
これは、ハンドラーとイベントジェネレーターの2つの主要コンポーネントで構築されています。 イベント自体は非人格で名前を付けることができます。 非人格的なイベントの例は、関数またはメソッドの呼び出しです
foo(1)
何らかのアクションを実行するか結果を取得する必要があるため、この関数を呼び出します。 正式にはイベントに「アクションを実行する」または「結果を取得する」という名前を付けることができますが、どこにも明示的には表示されません。 ハンドラーは、呼び出される関数またはメソッドです。
名前付きイベントの例は
click
です。 すべてが明確で、親しみやすく、親しみやすい。 ジェネレーターは特定のイベントを発生させ、それにいくつかのハンドラーが応答します。
アプリケーションの構造イベントモデル
JSの古典的なMVCから逃れたいという願望と、弱いモジュール間通信の要件が相まって、次のような結論に至りました。
ベストデータウェアハウス-DOM構造
JSとHTMLの間で不必要なデータ同期を行わないために、DOM構造を使用して直接変更を行います。 それでもJSオブジェクトの形式のデータが必要な場合は、一時構造でメソッドを呼び出すときにデータを収集し、それらを破棄します。 最初は、くしゃみごとに情報を収集する必要があるため、これはいくぶん非論理的なように見えますが、共有データの一貫性を維持するにはさらにコストがかかります。 特に、この場所にある特定の瞬間に他のDOMブランチが表示されないという保証がない単一ページアプリケーションでは、モジュールの1つがユーザーの要求でロードしました。
モジュール間の最適なコミュニケーション-イベント
特定のイベントを生成するためのモジュールの指導は、ハンドラーを相互にリンクするよりもはるかに簡単です。そのため、1つのモジュールでデータを変更する場合、関連モジュールで必要なすべてのアクションを自動的に実行します。 一種のポリモーフィズム、単一のコミュニケーションAPI。
ハンドラーキャリアとしてのノード
実行されたアクションの「責任」をDOMツリーの最終ノードにシフトすることにより、別の抽象化-スクリプトを取得します。 特定のノードで特定の場合に何をすべきかを知る人はいません。 したがって、DOM文書の構造には作業の論理が含まれています。 ここに、イベントおよび選択的フレームワークモデルのアプローチの最も基本的な違いがあります。
選択的アプローチで作業する開発者のロジックは、およそ次のとおりです。必要なノードを選択し、特定のアクションセットを実行します。 イベントアプローチのロジック：システムの状態が変化したため、誰かが特定のアクションセットを実行する必要があります。
あなたはそう言っています。 次の問題を解決しましょう。 フォームには3つの要素があります。登録住所
(ra)
、居住住所
(la)
、チェックボックス「居住住所が登録住所と一致する」
(ch)
です。 デフォルトでは、チェックボックスはマークされた状態で、居住地は非表示になっています。 ユーザーがチェックを外すと、居住地のフィールドが表示されます。 チェックボックスをオフにすると、入力フォームは非表示になるだけでなく、ユーザー入力も消去されます。 複雑なことは何もありません。
選択的手法を使用した抽象実装は、次のようになります。
- 2を行う
click
ハンドラーをch
- 状態がチェックされている場合は3、それ以外の場合は5
- ラを表示
- 出口
- ラを隠す
- クリアラ
- 出口
イベントメソッドを使用した抽象実装は次のようになります。
- 2を実行する
ch
click
イベントハンドラーをハングさせる - 状態が
checked
場合は3、それ以外の場合は5 -
equal_data
イベントをequal_data
ます - 出口
-
not_equal_data
イベントをnot_equal_data
ます - 出口
-
la
のequal_data
ハンドラーをハングアップします。 - ノードを非表示
- クリアフォーム
- 出口
- 2を実行する
la
not_equal_data
ハンドラーをハングアップします - ノードを表示
- 出口
一見すると、2番目の実装は少し複雑に見えます。 しかし、変更に対するコードの「耐性」を見てみましょう。 たとえば、コンテキストヘルプを表示するために追加のアクションを追加する必要がある場合、各アプローチの最初のコードブロックはどうなりますか。チェックボックスがアクティブか非アクティブかによってテキストが異なります。 ハンドラーに移動して、選択モデルで必要なアクションを追加し、イベントモデルでは何もしません。 100回の編集があっても、イベントアプローチの実装の最初のブロックは変更されません。これは、抽象的で実行スクリプトが含まれていますが、特定のアクションが含まれていないためです。 実際には、これはいくつかの利点で表現されます。
イベントアプローチからのポジティブな瞬間
編集時、作業の基本的なロジックが壊れず、ハンドラーのみが追加され、その逆も同様であるため、ハンドラーはスクリプトの変更に依存しないため、テスト時間が短縮されます。
動作中のKISS原則。 このスクリプトは、最終的な実装コードよりも読みやすくなっています。 ハンドラが特定のアクションを実行するように「ダム」にされている場合、ハンドラを間違えることははるかに困難です。 また、コードの移植性は非常に印象的であり、ハンドラーライブラリはプロジェクト間を、時にはスクリプトとともにさまよう。
負の瞬間
エントリーのしきい値。 特定のディレクティブの読み取りは、イベントのパス全体とスクリプト実行の結果を追跡するよりもはるかに簡単です。 準備ができていない開発者にとって、イベントモデルのコードは魔法のようなもので、どこからともなく何かが消えてどこかに消えてしまいます。
選択的な方法で簡単に解決できるタスクがありますが、イベントアプローチで同様に出てくるという事実はありません。
次の記事では、実際の実装に近づきます。
パート2
ご清聴ありがとうございました！