javascript - 基于类的 Javascript 注入(inject)有什么缺点吗？

Question

我看到越来越多的现象是 Javascript 代码绑定(bind)到特定页面上的特定元素，而不是绑定(bind)到 种类 元素或 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 还是通过类(class)来认识它都没有什么不同。

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

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

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

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

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