Question

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

Answer 1

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