基于类的JavaScript注入是否有缺点？

Question

我越来越多地看到与特定页面上的特定元素相关的JavaScript代码，而不是与 种类 元素或UI模式。

例如，假设我们在页面上有几个动画菜单：

<ul id="top-navigation">
    ...
</ul>

<!-- ... -->

<ul id="product-list">
    ...
</ul>

这两个菜单可能存在于同一页面或不同页面上，并且某些页面可能没有任何菜单。

我经常看到这样的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上的某些文章开创的。

我很惊讶这些简单的技术仍然没有得到广泛的采用，但我仍然看到“最佳实践”代码示例和JavaScript框架直接指代UI实例而不是UI模式。

有什么理由吗？我刚刚描述的我不知道的技术是否有一些很大的劣势？

Answer 1

首先，我同意您的观点，通常使用类方法更好。

但是我不认为我会说，这不是将代码与UI耦合。如果您考虑一下，如果代码假设ID“ foo”与类名称“ foo”，则在使用UI时仍然必须知道这一点。他们之间仍然有一个“合同” - 无论您是通过ID还是班级见面并没有什么不同。

我想象的是使用类方法的一个缺点是速度 - 通过ID找到特定元素应该比找到可能的多个元素逐个类别更快。不过，差异可能完全可以忽略不计。

但是，如果您的代码被设计为附加多种行为的情况，那么在您的两次驱动式示例中，使用类肯定会更有意义。由于您的代码更具概括性，因此它的耦合较少，并且您的UI更有可能通过更改代码定制。

我在两个示例中都会改变一件事...为什么选择器中的UL？如果代码知道它只有在目标是UL时才可以工作，那么，这是一回事 - 但是，在这种情况下，最好避免选择器中的UL，并让代码丢弃有意义的错误。发现目标不是UL，以免页面无需任何迹象表明为什么（例如，因为UI将ID/类都放在OL上）。

因此，换句话说，只有“ #foo”或“ .foo”而不是“ ul.foo”，等等。

我应该指出的是，如果有人认为UL以某种方式使选择器更有效，则不会，因为选择器的右至左评估。

Answer 2

您的方法是首选。

人们以不同方式做事的原因是因为他们可以而且仍然有效。