この記事では、2 つの単純なビジネス要件を実装することで、AngularJS と従来の JavaScript コントロール DOM 実装の違いを調査し、一般的な Web フロントエンド開発における MVW などのフレームワークのプログラミングの考え方を理解しようとします。
この要件は非常に一般的です。たとえば、2 レベルのメニューでは、最初のレベルのメニュー項目がクリックされたときに、対応するサブメニュー項目が表示または非表示になる必要があります。
jQuery 実装:
$('li.parent_item').click(function(){
$(this).children('ul.child').toggle();
})
ディレクティブ
2.式
とng-hide は両方ともフレームワークに付属するディレクティブです。前者は HTML 要素 (. li) クリックすると、Expression (expression) Hide_child = !hide_child が実行されます。まず、割り当てられた式の結果 (ブール値) (CSS によって実装) に基づいて HTML 要素を表示するかどうかを制御する ng-hide ディレクティブを見てみましょう。つまり、変数 hide_child が true の場合、ul は非表示になり、それ以外の場合はその逆の結果になります。 ここでの Hide_child は、実際には $scope
の変数です。ただし、その値を変更するには、コントローラー コントローラー内でメソッドをラップすることもできます。ただし、現在のステートメントは比較的単純で、In に直接記述することができます。命令の割り当て。上記の簡単なコード分析を通じて、AngularJS の 2 つの明らかな特徴がわかります。
1. DOM の操作は命令と式によって密閉されており、単純なコードのみで余分な JavaScript コードを節約できます2. 命令と式の適用は HTML 内でのみ直接ネストされます。これは、jQuery が推奨する目立たない JavaScript コード スタイルとは若干異なります
最初に別の要件を見てから、上記の結論を詳しく説明しましょう。
従来の HTML Form 要素は、今日のモバイル デバイスでの操作にはあまり適していません。たとえば、ラジオ ボタンのコンポーネントを制御するには、タッチ スクリーン上で正確な位置を指定する必要がありますが、指の位置は非常に大まかです。対応するLabelコントロールを追加する方法が一般的ですが、テキスト自体の画面比率が理想的ではなく、明確な情報伝達効果がありません。そのため、比較的面積の大きい div タグや li タグは間接的に操作することが一般的です。
jQuery 実装:
// javascript
$('li.selection').click(function(){
$(this).children('input[type="radio"]').click();
})
AngularJS の機能:
このソリューションでは、追加の JavaScript コードを使用せず、さらにいくつかの命令を使用しました。比較と参照のために、2 つのディレクティブ ng-click と ng-model の式のみに注目します。
まず、input 要素の ng-model ディレクティブを見てみましょう。ここでの割り当ては、テンプレートの入力を $scope.model オブジェクトの option 属性に関連付けて、in を取得することを意味します。 - データの詳細な理解。バインディングについては、データ バインディングを参照してください。この指定された関連付けにより、テンプレート コントロールをデータ モデルに直接バインドできるようになり、このバインディングは双方向です。これは、ユーザーがコントロールの値を変更すると (ラジオ入力を確認する)、Model オブジェクトの値が変更されると、同時に対応する Model オブジェクトが再割り当てされ (model.option)、テンプレートも反映変更に対応します。これは実際には上記の jQuery 実装では実現されません。
したがって、AngularJS のデータ バインディングを通じて、li 要素をクリックして間接的に入力をトリガーするプロセスは次のようになります:
1. li タグをクリックして、model.option に値を割り当てます。
2. Model オブジェクトを変更し、対応する入力コントロールを見つけます (value の値は、model.option の値です)。
3. 入力コントロール
の selected 属性をアクティブ化します。
上記の 2 つのケースを通じて、Web フロントエンドの動作について新たな理解を得ることができました。
まず、技術的な実装に関しては、新しい命令、式、データ バインディング、その他の概念を導入することで、ユーザー間の対話に限定された JavaScript コードだけでなく、まったく新しい方法で DOM を操作できるようになります。そしてHTMLコンポーネントが実現します。この考え方の変化は非常に大きいです。
今世紀初頭に動的 Web プログラミングが台頭して以来、サーバーサイド プログラミング テクノロジは向上してきました。 CGI/PHP/ASPの始まりから、言語とプラットフォームは.NET対Javaを生み出し、開発効率とソフトウェアプロセスはMVCフレームワーク/ORM/AOPなどを促進し、パフォーマンスとビッグデータはNodeJS/NoSQL/をもたらしました。 Hadoop など、ブラウザ フロントエンドの技術要件はそれほど急進的ではないようです。一方では、B/S モデルのビジネス ニーズのほとんどはサーバーとデータベースを通じて満たされますが、他方では、ブラウザ自体にはプラットフォームごとに違いがあり、スクリプト言語とレンダリングの標準と互換性がありません。テクノロジーには限界があり、コンピューティング能力に限界があり、安全性も考慮されています。
この場合、ブラウザ側の要件は、ほとんどの場合、ページのレンダリングと単純なユーザー操作のみを考慮する必要があります。したがって、HTML/DOM と JavaScript/CSS によって、フロントエンドの主要な作業が実現されます。したがって、以前はフロントエンド ワーカーは存在せず、Web デザイナーだけが必要でした。徐々にフロントエンドの要件が増え、jQuery は DOM を操作するための JavaScript カプセル化ライブラリとして最も広く使用されるようになりました。現段階では、jQuery/JavaScript の主なタスクは、まだユーザーのブラウザ端末のプレゼンテーションと対話のためのツールとしてだけです。
jQuery の起源を理解すると、Unobtrusive JavaScript など、以前に追求したルールの一部が、DOM と JavaScript コード ロジックを分離するために実装の手段と方法に限定されていたことがわかります。よりメンテナンスしやすい方法を優先しました。 JavaScript のフロントエンドの需要が高まった後、多くの MVC/MVP フロントエンド フレームワークが登場したほか、AngularJS のいわゆる
MVW (Model-View-Whatever)や、フリーサイズのフレームワークも登場しました。 JavaScript と DOM に対するすべてのアプローチが変更されました。当初は、インターフェイスの表示とユーザーの対話を直接操作することを考えていましたが、現在では、クライアント側のデータ バインディング、豊富な命令、依存関係の挿入が私たちを待っています。