基于类的 Javascript 注入有什么缺点吗？答案

【问题标题】：Are there any drawbacks to class-based Javascript injection?基于类的 Javascript 注入有什么缺点吗？
【发布时间】：2010-06-07 05:14:49
【问题描述】：

我看到越来越多的现象是 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 寻找该元素的附加代码。

我相信 alistpart.com 上的某些文章开创了类似的技术。

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

这有什么原因吗？我刚才描述的技术是否有一些我不知道的重大缺点？

【问题讨论】：

标签： javascript jquery html progressive-enhancement

【解决方案1】：

首先我同意你的观点，一般来说使用类方法更好。

但我不认为我会说它减少了代码与 UI 的耦合。如果您考虑一下，如果代码假定 ID“foo”与类名“foo”，那么在使用 UI 时您仍然必须知道这一点。他们之间还是有“契约”的——不管是通过身份证还是通过班级，都没有什么不同。

我认为使用类方法的一个缺点是速度——通过 ID 查找特定元素应该比通过类查找潜在的多个元素更快。不过，差异可能完全可以忽略不计。

但是，如果您的代码旨在附加多种行为，例如在您的两个下拉示例中，使用类当然更有意义。这减少了耦合，因为您的代码更加通用，并且您的 UI 更有可能在不更改代码的情况下进行自定义。

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

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

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

【讨论】：

使用类当然不会消除开发人员有意识地以松散耦合方式开发代码的必要性。实际上，在特定元素每页仅出现一次的情况下，使用 ID 可能会更好。我想我并不是在提倡这样的类，而是一种编写 Javascript 的方式，以便它可以与 patterns 和 micro-formats 一起使用，而不是每个单独的、独特的用例一种特定的模式。
UL 选择器之所以存在，是因为假设（并强制执行）菜单应该是结构化列表似乎是合理的。这符合 semantic HTML 的最佳实践——使用适当的 HTML 元素来表示结构化数据，而不是使用 Div 和 Spans 来做所有事情。
就性能/效率而言，您很可能对课程不快是正确的。有一些方法可以缓解这种情况，但它们会以干净的 HTML/JS 分离为代价。我想解决它的一种方法是为 IE6（唯一一个真正令人头疼的浏览器）创建一个单独的 JS，它直接绑定到 ID 而不是类。
re UL：当然，这没有错。我的观点是，如果 UI 尝试使用非 UL 会发生什么。因为选择器找不到它，所以什么都不会发生。如果插件仅适用于 UL，最好检查标签名称并抛出错误。

【解决方案2】：

您的方法是首选。

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

【讨论】：