jQuery iterate or two-step? I have an array of values of the form:

configs = ["26W", "27W", "28W"...]


They correspond to some of the a elements in a list:

&lt;ul id="value-list"&gt;&lt;li&gt;&lt;a data-value="26W"&gt;...&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a data-value="27W"&gt;...&lt;/a&gt;&lt;/li&gt;...&lt;/ul&gt;


When the data in the list does correspond to an existing a, I need to set the parent li class to "available" and not "unavailable". If there is an a with a value not in the list, I need to set the class to "unavailable" and not "available". (Edit: I realize that having both classnames is redundant, but I don't have the option to change that right now.)

I can think of two ways to do this:

Iterate

var $allSwatchItems = $("#value-list &gt; li");
$allSwatchItems.each(function () {
  var $this = $(this);
  var $a = $this.children("a");
  if (configs.indexOf($a.attr("data-value")) === -1) {
    $this.addClass("unavailable").removeClass("available");
  } else {
    $this.addClass("available").removeClass("unavailable");
  }
});


Two-step

var $allSwatchItems = $("#value-list &gt; li");
// Set everything to unavailable at first.
$allSwatchItems.removeClass("available").addClass("unavailable");
// Build the selector for the swatch anchors.
var swatchSelector = configs.map(function (val, idx, arr) {
  return "a[data-value='" + val + "']";
}).join(", ");
// Set the matching list items to available.
var $availSwatchItems = $allSwatchItems.children(swatchSelector).parent();
$availSwatchItems.removeClass("unavailable").addClass("available");


I know there are pros and cons to both approaches, but is one significantly better than the other (and how), or is there a third approach I should consider?

Update: Here's how I finally did it:

function checkAvailable() {
    if (-1 !== $.inArray($(this).children("a").attr("data-value"), configs)) {
        return "available";
    } else {
        return "unavailable";
    };
}
$("ul#value-list &gt; li").removeClass("unavailable available").addClass(checkAvailable);
A good general performance rule of thumb is to avoid hitting the DOM (the HTML-manipulating stuff) more than necessary. Most DOM properties aren't just static properties that get set from somewhere else as things change. Invoking them tends to involve buildup and tear-down and examining of internal state, etc. Anything that actually alters HTML is 99.99% likely to cause reflow calculations.

Why have two classes? Just let the lack of an 'available' when checked for with .hasClass('available') represent 'unavailable'. That way you only hit the DOM when you add 'available' and do the attribute checks with both of those className changes setting off reflow calculations.

A note on the second approach. It looks more concise but it's doing a lot of looping and DOM access under the hood. It's important to understand what JQuery does when invoking it. In this line for instance,

$allSwatchItems.removeClass("available").addClass("unavailable");

JQ is going to have to run down the collection of DOM elements with an internal loop access the className property, do a replace operation on it, set the className property, then access the className property again match for 'unavailable' and add it on if it isn't there.

People tend to shy away from using the class attribute as a place to tie things to data but I'm of the opinion that you're always binding to something in the HTML. Why not use the most efficient thing that's easiest to share with other concerns? And no, I do not consider HTML an exclusive property of the view in MVC and similar patterns. It also represents content and document structure. Leave HTML out of your JavaScript modeling conventions. It has too much overlap with other concerns and other domains. Think of DOM API stuff as low-level and view modeling as higher-level stuff that buries the DOM stuff.

Here's how I'd do it - I'll let you sort out what's worth haggling over with your team/tools where control over HTML/CSS is concerned but by baking things into your HTML structure the right way, it can save  a lot of work.

HTML like this with unavailable as default sharing with class with data_val classes if needed (classes can have multiple properties separated by spaces):

&lt;ul id="value-list"&gt;
&lt;li class="data_val_26W"&gt;&lt;a &gt;...&lt;/a&gt;&lt;/li&gt;
&lt;li class="data_val_27W"&gt;&lt;a&gt;...&lt;/a&gt;&lt;/li&gt;...
&lt;/ul&gt;


build your available selector:

var swatchSelector = '.data_val_' + config.join(', .data_val_'),
//#value-list step to reduce brutal IE8 DOM tomfoolery
$availableSwatchItems = $('#value-list').find(swatchSelector);

$availableSwatchItems.addClass('available'); //.remove('unavailable') if you must


It's not a minor thing to not have control over your HTML and CSS. By structuring to your advantage, you can drastically reduce code and improve performance. Any tool or back-end dev who makes this impossible is like a stick in the eye for a client-side dev. That's your domain. You should have control over it. As for custom attributes, when browsers have access methods as fast as className and ID for other attributes I don't really care what people use for attributes in HTML5 but for now, it's a pointless performance-hamperer, IMO.