クラスベースのJavaScript注入に欠点はありますか?
-
24-10-2019 - |
質問
私が見ている現象は、ますます多くのページに関連するのではなく、特定のページの特定の要素に関連付けられているJavaScriptコードです 種類 要素またはUIパターンの。
たとえば、ページにいくつかのアニメーションメニューがあったとします。
<ul id="top-navigation">
...
</ul>
<!-- ... -->
<ul id="product-list">
...
</ul>
これらの2つのメニューは、同じページまたは異なるページに存在する可能性があり、一部のページにはメニューがない場合があります。
このようなJavaScriptコードをよく見ることができます(これらの例では、jQueryを使用しています):
$(document).ready(function() {
$('ul#top-navigation').dropdownMenu();
$('ul#product-selector').dropdownMenu();
});
問題に気づきましたか?
JavaScriptはしっかりと結合されています 特定のインスタンス UIパターン自体ではなくUIパターンの。
代わりにこれを行うのはそれほど簡単ではないでしょうか(そしてクリーン)でしょうか? -
$(document).ready(function() {
$('ul.dropdown-menu').dropdownMenu();
});
次に、「ドロップダウンメニュー」クラスをリストに配置できます。
<ul id="top-navigation" class="dropdown-menu">
...
</ul>
<!-- ... -->
<ul id="product-list" class="dropdown-menu">
...
</ul>
物事を行うこの方法には、次の利点があります。
- よりシンプルなJavaScript-添付するだけです 一度 クラスに。
- 特定のページに存在しない可能性のある特定のインスタンスを探すことは避けています。
- 要素を削除する場合、その要素の添付コードを見つけるためにJavaScriptを介して狩りをする必要はありません。
これに似たテクニックは、Alistapart.comの特定の記事で開拓されたと思います。
これらの簡単なテクニックはまだ広範な採用を獲得していないことに驚いており、UIパターンではなくUIインスタンスを直接参照する「ベストプラクティス」コードサンプルとJavaScriptフレームワークがまだ見られます。
これに理由はありますか?私が知らなかったと私が説明したテクニックに大きな不利な点はありますか?
解決
まず第一に、クラスアプローチを使用する方が一般的に優れていることに同意します。
しかし、私はそれがUIへのコードのカップリングが少ないと言うまで行くとは思わない。考えてみると、コードがID "foo"とclass name "foo"を想定している場合でも、UIで作業するときはまだ知っておく必要があります。それらの間にはまだ「契約」があります - IDやクラスを通してそれを満たすかどうかは、実際には違いはありません。
クラスアプローチを使用することの1つの欠点は、速度です。クラスごとに複数の要素を見つけるよりも、IDごとに特定の要素を見つける方が速いはずです。違いはおそらく完全に無視できます。
ただし、2ドロップダウンの例のように、コードが複数の動作を添付するように設計されている場合、クラスを使用することは確かにより理にかなっています。コードはもう少し一般化されており、コードを変更してカスタマイズ可能である可能性が高いため、これはそれほど結合しません。
私があなたの両方の例で私が変更することの1つ...なぜSelectorにULを持っているのですか?ターゲットがULである場合にのみ機能する可能性があることをコードが知っている場合、それは1つですが、その場合、セレクターのULを回避し、コードが意味のあるエラーを投げる方が良いでしょう。ターゲットはULではないことがわかります。なぜ、ページに何も兆候なしに何もしないようにしないでください(例えば、UIがID/クラスをOLに置いたため)。
言い換えれば、「#foo」または「.foo」は「ul.foo」などではありません。
Selectorが右から左に評価されるため、誰かがULが何らかの形でセレクターをより効率的にしていると考えた場合は、そうではないことを指摘する必要があります。
他のヒント
あなたのアプローチが望ましいです。
人々がさまざまな方法で物事をする理由は、彼らができるので、それがまだ機能するからです。