如何在 jQuery 代码中最小化/并置相似的 DOM 选择器字符串?

发布于 2024-10-16 22:44:38 字数 1403 浏览 1 评论 0原文

请提供代码风格建议:

我想防止选择器字符串在我的代码中大量分布,尤其是类似的基数。

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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

牵你的手,一向走下去 2024-10-23 22:44:38

我建议您存储选择器的结果以提高效率。

Elements = {
  form: $("#formId"),
  statusBar: Elements.form.find(".statusBar"),
  sectionClass: Elements.form.find("ul.sectionClass"),
  activeItems: Elements.sectionClass.find("li.statusFlag"),
  inactiveItems: Elements.sectionClass.find("li.otherStatusFlag")
};

因此,您将重用选择器结果,从而获得更好的性能。但如果您稍后要在 DOM 中添加元素并匹配这些选择器,则这可能不起作用。

如果您采用上述方法,您可能需要更改方法/函数以期望元素数组而不是字符串。

例如,

function doSomethingToGroup(elems) {
  Elements.statusBar.html(summarize(elems.selector));
  elems.doMore();
}

您始终可以使用 selector 方法从缓存结果中获取选择器字符串。
Elements.statusBar.selector 返回选择器#formId .statusBar

I'd suggest that you store the result of the selector in order to be more efficient.

Elements = {
  form: $("#formId"),
  statusBar: Elements.form.find(".statusBar"),
  sectionClass: Elements.form.find("ul.sectionClass"),
  activeItems: Elements.sectionClass.find("li.statusFlag"),
  inactiveItems: Elements.sectionClass.find("li.otherStatusFlag")
};

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.,

function doSomethingToGroup(elems) {
  Elements.statusBar.html(summarize(elems.selector));
  elems.doMore();
}

You can always get the selector string from the cached results using the selector method.
Elements.statusBar.selector returns the selector #formId .statusBar

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文