基于类的 Javascript 注入有什么缺点吗？
我越来越多地看到的现象是 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 模式。
这有什么原因吗？我刚才描述的技术是否有一些我不知道的重大缺点？
A phenomena I'm seeing more and more of is Javascript code that is tied to a particular element on a particular page, rather than being tied to kinds of elements or UI patterns.
For example, say we had a couple of animated menus on a page:
<ul id="top-navigation">
...
</ul>
<!-- ... -->
<ul id="product-list">
...
</ul>
These two menus might exist on the same page or on different pages, and some pages mightn't have any menus.
I'll often see Javascript code like this (for these examples, I'm using jQuery):
$(document).ready(function() {
$('ul#top-navigation').dropdownMenu();
$('ul#product-selector').dropdownMenu();
});
Notice the problem?
The Javascript is tightly coupled to particular instances of a UI pattern rather than the UI pattern itself.
Now wouldn't it be so much simpler (and cleaner) to do this instead? -
$(document).ready(function() {
$('ul.dropdown-menu').dropdownMenu();
});
Then we can put the 'dropdown-menu' class on our lists like so:
<ul id="top-navigation" class="dropdown-menu">
...
</ul>
<!-- ... -->
<ul id="product-list" class="dropdown-menu">
...
</ul>
This way of doing things would have the following benefits:
- Simpler Javascript - we only need to attach once to the class.
- We avoid looking for specific instances that mightn't exist on a given page.
- If we remove an element, we don't need to hunt through the Javascript to find the attach code for that element.
I believe techniques similar to this were pioneered by certain articles on alistapart.com.
I'm amazed these simple techniques still haven't gained widespread adoption, and I still see 'best-practice' code-samples and Javascript frameworks referring directly to UI instances rather than UI patterns.
Is there any reason for this? Is there some big disadvantage to the technique I just described that I'm unaware of?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，我同意你的观点，一般来说，使用类方法更好。
但我不认为我会说它减少了代码与 UI 的耦合。如果您考虑一下，如果代码假定 ID“foo”与类名“foo”，那么在使用 UI 时您仍然必须知道这一点。他们之间仍然有一个“契约”——无论你是通过ID还是通过班级来认识它，并没有太大的不同。
我认为使用类方法的一个缺点是速度——通过 ID 查找特定元素应该比通过类查找潜在的多个元素更快。但差异可能完全可以忽略不计。
但是，在您的代码设计为附加多个行为的情况下（如您的两个下拉列表示例中所示），使用类当然更有意义。这是较少的耦合，因为您的代码更加通用，并且您的 UI 更有可能在不更改代码的情况下进行自定义。
我要在你的两个例子中改变一件事......为什么选择器中有 UL？如果代码知道它只有在目标是 UL 时才可能工作，那么，这是一回事 - 但在这种情况下，最好避免选择器中的 UL，并让代码在以下情况下抛出有意义的错误：发现目标不是 UL，以免页面在没有任何指示的情况下什么都不做（例如，因为 UI 将 ID/类放在 OL 上）。
因此，换句话说，只是“#foo”或“.foo”而不是“ul.foo”等。
我应该指出，如果有人认为 UL 以某种方式使选择器更高效，则事实并非如此，因为选择器是从右到左评估。
First of all I agree with you that using the class approach is better, in general.
But I don't think I'd go so far as to say it's less coupling of the code to the UI. If you think about it, if the code assumes ID "foo" vs. class name "foo", you still have to know that when working with the UI. There's still a 'contract' between them -- whether you meet it through ID or class is not really different.
One disadvantage to using the class approach I'd imagine is speed -- it should be faster to find a particular element by ID than find potentially multiple elements by class. The difference is probably completely negligible though.
But, in the case where your code is designed to attach multiple behaviors, as in your two-dropdown example, using class certainly makes more sense. That is less coupling since your code is a bit more generalized, and your UI more likely to be customizable w/o changing the code.
One thing I'd change in both of your examples... why have the UL in the selector? If the code knows it can only possibly work if the target is a UL, well, that's one thing -- but in that case, it'd be better to avoid the UL in the selector and let the code throw a meaningful error if the target is found not to be a UL, lest the page just do nothing without any indication as to why (e.g. because the UI put the ID/class on a OL).
So in other words, just "#foo" or ".foo" not "ul.foo", etc.
I should point out that in case someone thinks the UL somehow makes the selector more efficient, it doesn't, since selectors are evaluated from right to left.
您的方法是首选。
人们以不同方式做事的原因是因为他们可以并且仍然有效。
Your approach is preferred.
The reason people do things in different ways is because they can and it still works.