如何在 jQuery 代码中最小化/并置相似的 DOM 选择器字符串?
请提供代码风格建议:
我想防止选择器字符串在我的代码中大量分布,尤其是类似的基数。
function fn1() {
$("#formId ul.sectionClass li.statusFlag").doSomething();
$("#formId ul.sectionClass li.otherStatusFlag").doSomeOtherThing();
doSomethingToGroup("#formId ul.sectionClass");
doSomethingToOtherGroup("#formId ul.otherSectionClass");
}
function doSomethingToGroup(selector) {
$("#formId>.statusBar").html(summarize(selector));
$(selector).doMore();
}
function classesLikeIds() {
$("#formId .item1").doOneThing();
$("#formId .item2").doAnotherThing();
}
...etc.
从功能上来看,我很满意我的代码相当干燥。责任划分是健康的,等等。但是我的代码中仍然分散着选择器字符串,这些字符串难以维护并导致缺陷。
可能的解决方案:
我考虑过像选择器命名数组这样简单的事情:
AppName.Selectors = {
form: "#formId",
statusBar: "#formId .statusBar",
activeItems: "#formId ul.sectionClass li.statusFlag",
inactiveItems: "#formId ul.sectionClass li.otherStatusFlag"
}
这似乎更易于维护,并且 javascript 编译器可以提醒我更多问题。但我还是觉得它很弱。如果您这样做,但有一个使其更直观或支持子关系的对象模型,请将其作为解决方案发布。
也许我的风格是问题的一部分:
也许它很糟糕或有争议,但我尝试最大限度地减少 HTML 中的唯一 ID,甚至有时使用 ID 之类的类(在顶级元素 ID 之下)。例如:
//I'll use
$("#appName form .header")
//Rather than
$("#appNameHeader")
为什么?根据我的经验,如果一个应用程序中有 100 个 ID,就会发生不好的事情。两个简单的例子:1)混搭应用程序充满了名称冲突的危险,2)很难凭直觉了解样式更改对子元素的影响。
你是做什么的?
谢谢,
香农
Code style advice, please:
I want to prevent the rampant distribution of selector strings, especially similar bases, throughout my code.
function fn1() {
$("#formId ul.sectionClass li.statusFlag").doSomething();
$("#formId ul.sectionClass li.otherStatusFlag").doSomeOtherThing();
doSomethingToGroup("#formId ul.sectionClass");
doSomethingToOtherGroup("#formId ul.otherSectionClass");
}
function doSomethingToGroup(selector) {
$("#formId>.statusBar").html(summarize(selector));
$(selector).doMore();
}
function classesLikeIds() {
$("#formId .item1").doOneThing();
$("#formId .item2").doAnotherThing();
}
...etc.
Functionally, I'm comfortable my code is fairly DRY. Divisions of responsibility are healthy, etc. But I still have selector strings scattered throughout my code that are difficult to maintain and causing defects.
Possible solution:
I've thought about something as simple as a named array of selectors:
AppName.Selectors = {
form: "#formId",
statusBar: "#formId .statusBar",
activeItems: "#formId ul.sectionClass li.statusFlag",
inactiveItems: "#formId ul.sectionClass li.otherStatusFlag"
}
That seems more maintainable, and a javascript compiler could alert me to many more problems. I still feel like it's pretty weak, though. If you do this, but have an object model that makes it more intuitive or supports child relations, please post it as a solution.
Maybe my style is part of the problem:
Maybe it is bad or controversial, but I try to minimize unique IDs in my HTML, even sometimes using classes like IDs (beneath top-level element IDs). For example:
//I'll use
$("#appName form .header")
//Rather than
$("#appNameHeader")
Why? If an app has 100 IDs in it, bad stuff happens in my experience. Two quick examples: 1) mashing-up apps becomes fraught with name collision danger, 2) it is harder to intuit the impact of style changes on child elements.
What do you do?
Thanks,
Shannon
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我建议您存储选择器的结果以提高效率。
因此,您将重用选择器结果,从而获得更好的性能。但如果您稍后要在 DOM 中添加元素并匹配这些选择器,则这可能不起作用。
如果您采用上述方法,您可能需要更改方法/函数以期望元素数组而不是字符串。
例如,
您始终可以使用
selector
方法从缓存结果中获取选择器字符串。Elements.statusBar.selector
返回选择器#formId .statusBar
I'd suggest that you store the result of the selector in order to be more efficient.
thus you'll reuse the selector results, which results in better performance. But this may not work if you've elements that are being added in the DOM later and match these selectors.
If you go with the above approach, you might've to change your methods/functions to expect an array of elements rather than a string.
For eg.,
You can always get the selector string from the cached results using the
selector
method.Elements.statusBar.selector
returns the selector#formId .statusBar