2

我越来越多地看到的一种现象是 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 模式。

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

4

2 回答 2

1

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

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

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

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

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

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

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

于 2010-06-07T05:44:44.217 回答
1

您的方法是首选。

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

于 2010-06-07T05:45:10.117 回答