web-dev-qa-db-ja.com

Javascript、HTML、CSS間の緊密な結合：より近代的なアプローチ？

要素の検索、データの保存、イベントのリッスンのために、特定のセレクターにバインドされたJavaScriptを確認することは非常に一般的です。スタイリングに使用されるこれらの同じセレクターを確認することも一般的です。

jQuery（およびそのセレクターエンジンSizzle）は、CSSタイプの構文で要素を参照することにより、これをサポートおよび促進します。そのため、この手法は、プロジェクトを構築する際に「学習を解除」（またはリファクタリング）することが特に困難です。

これはHTMLとJavascriptの開発の歴史の結果であり、ブラウザはこの種の結合を効率的に消費/解析/レンダリングするように構築されていることを理解するようになりました。しかし、ウェブサイトがますます複雑になるにつれて、この現実は、これらの個別のレイヤーの整理と維持に困難をもたらす可能性があります。

私の質問は、現代のウェブサイトではこれを回避できるのか、また回避すべきなのか？

フロントエンド開発に不慣れで、「正しい方法」で学習したい場合、そのような依存関係を最初から切り離して回避することを学ぶ価値はありますか？これは、より分離された構造を促進するライブラリを支持してjQueryを回避することを意味しますか？

javascripthtmlcssjquery
29
Stuart Kershaw

それを避ける方法はありません。それらは互いに相互作用するため、結合されます。 JavaScriptが何らかのDOM操作を行うことを意図している場合、DOMを参照する方法が必要です。

これにはさまざまな規則があります。

レベル2 DOM APIは、getElementById、getElementByTagName、およびgetElementsByNameメソッドを提供します。今日まで、これらはあらゆる種類のDOMトラバーサルの主力となっています。他のすべてのより洗練されたjQueryセレクターは、最終的にこれらの組み合わせ、および/または各DOMノードのまっすぐなトラバースを解決します（これがgetByClassNameを行う方法でした）。

他にショートカットはありません。 JavaScriptは何をどこで行うかを知る必要があります。通常、要素にスクリプトにのみ関連するIDまたはクラスが含まれている場合、多くの人はjs-または他の明らかなフラグをプレフィックスとして付けます。

もう1つの新しい規則は、データ属性の選択です。

<ul data-myapp-sortable="true">

jQuery('[data-myapp-sortable]').makeSortable();

データ属性は通常、スクリプト作成の目的で使用され、それを使用して選択することには意味があります。欠点は、これがgetElementById（）を使用するよりも遅いことです。

別のアプローチは、ビューモデルを作成するangularJSで使用されるものです。この規則では、あらゆる種類のスクリプト機能が、ng-disabledng-hrefなどの特別に指定された属性によって指定されます。 JavaScriptにセレクターを追加しません。 HTML文書は、スクリプトの内容と方法に関する主な権限となり、JavaScriptが抽象的に動作します。これは良い方法ですが、以前の方法よりも学習曲線が明らかに高くなっています。また、パフォーマンスも考慮する必要があります。

ただし、インタラクティブなHTMLとJavaScriptを記述できるとは考えないでください。また、どういうわけか、両方の部分が他方について知らないようにしてください。依存関係への参照を制限する方法についての詳細です。

35
mastaBlasta

取得する対話性を放棄してもかまわない場合は、JavaScriptを完全に回避できます。 ASP.NET MVCのようなフレームワークは、HTML、CSS、およびSUBMITボタンのみを含むページを提供するのに非常に適しています。

OK。多分それは少し極端です。

Webアプリケーションの分離は、多くのレベルですでに発生しています。 RESTアプリケーションでは、URLに関連付けられた「Webリソース」に関してアプリケーションを定義できます。ビューモデルを使用すると、ドメインモデルから切り離されたUIにデータを表示できますが、サービスレイヤーを使用すると、あるUIを別のUIと交換できます。

歴史的に、双方向性とカップリングの間には常にトレードオフがありました。 Webページの対話性が高ければ高いほど、Webページとアプリケーションとの結び付きが強くなります。ただし、Webページの対話ロジックはWebページ自体に限定されます。サーバーとのカップリングは、POSTまたはAJAXのいずれかを介して行われます。そのため、データの方法に注意を払う以外に、JavaScriptレベルでのカップリングに過度に注意する必要があるかどうかはわかりません。パケットはブラウザとサーバーの間で渡されます。

最も「モダンな」アプローチ（つまり、今週の味）はおそらく SPAアプリケーション です。

9
Robert Harvey

Martin Fowlerは、これに対する1つのアプローチを Segregated DOM として説明しています。この場合、DOM JavaScriptをページロジックJavaScriptから分離します。

Application Logic <----> DOM Manipulation <----> DOM / HTML
5
Rory Hunter

いいえ、クラス、要素、およびIDセレクターをクライアント側で使用することは避けてはいけません。 CSSセレクターは非常に成熟しており、確立されたドメイン言語であり、共通の設計を持つことで遠くまで行けるため、構文が使用されます。プログラムとデザインの間でページの共通の論理モデルを共有するのが簡単になり、これは非常に良いことです。

この構文を誤用してひどく保守不可能なアプリケーションを作成することは可能ですが、言語やツールセットに関係なく可能です。

2
DougM

誰かが、DOMへの間接層とキャッシュ層のためのjQueryパスマネージャインターフェースを構築する必要があります。

pathMgr.register(name,selector [,isDynamic=false]);
pathMgr.get(name [,refresh]);

そして、

String.prototype.reg([isDynamic=false]);
String.prototype.get(name [,refresh]);

そう、

// at init....
var pathMgr=new PathMgr();
'sidebar-links #sidebar a'.reg();// new registery of selector '#sidebar a' under name 'sidebar-links'
// more, more


// in code
'sidebar-links'.get().css(etc...);
//or
'sidebar-links'.addStyleRule({});
0
Mark