La Q original no es muy específica sobre el contenido/propósito y debe haber una variación, dependiendo de la IMO. Definitivamente estoy en desacuerdo con la respuesta aceptada actual en un punto. Al recorrer y adjuntar nuevos ID a una tonelada de HTML que ya se ha procesado, se pueden generar cantidades masivas de cálculos de reflujo, que podrían ponerse feas dependiendo de lo que representa 'stuffContainer'.
Construir con los ID de Primera Desde servidor o inyectar tan solo bloque en el lado del cliente si es necesario hacerlo
Como regla general, evitar golpear el DOM con los cambios en repetidas ocasiones si puede evitarlo. Los ID construidos de antemano en el servidor son bastante insignificantes en cuanto al navegador que carga la página, IMO. Claro, es una tabla de hash más grande, y en consecuencia más lenta, pero si hablamos de cientos y no de decenas de miles, dudo seriamente que te vayas a dar cuenta.
Un enfoque más eficiente del lado del cliente en el caso de una lista de selección construida a partir de datos sería construir primero como una cadena, con ID y todo, y luego asignar a innerHTML de un contenedor o si como algunos de Mis colegas de js chat, tienen un extraño problema con innerHTML en todos los casos de uso posibles, aunque ahora está en la especificación, al menos compilar y anexar primero a un fragmento de documento. y luego añádalo a su contenedor.
Data-atributos o clases Más de ID de
OMI, el olor-factor no es tanto sobre el rendimiento, sino más bien la hinchazón HTML y la creación de una dependencia de identificación donde se necesita ninguna, bloqueando de este modo algo más que podría encontrar una ID personalizada en uno de sus divs de un solo elemento es útil. Los identificadores son definitivamente la forma ideal de reducir la búsqueda de elementos en JavaScript, pero en los casos de contenedores con contenido obtendrá más flexibilidad de los contenedores ID que los que identifiquen cada elemento secundario. La ganancia de rendimiento de un paso frente a dos pasos no vale la pena el costo de flexibilidad de la aplicación de identificadores genéricos a los elementos.
Como alternativa, puede usar clases con valores únicos o el atributo de datos, p. 'data-itemId = "0"'. Para conjuntos de HTML más pequeños, como una lista de selección personalizada donde los ID están conectados a algún sistema de indexación del lado del servidor para facilitar la actualización de datos, tendería a favorecer este enfoque altamente visible ya que facilita la comprensión de la arquitectura, pero agrega mucho de atributos innecesarios para rastrear escenarios en los que podrían estar involucrados cientos o miles de elementos.
o, idealmente, (en la mayoría de los casos), Delegación Evento
más idealmente, la OMI, se evita por completo atributos adicionales en los casos en que sólo se preocupan por el elemento de artículo único hijo que está haciendo Clicks y no lo es 'ID' es o el orden en que esos contenedores de elementos individuales permanecerán estáticos y usted puede asumir con seguridad que las posiciones son los ID efectivos. O bien, otro escenario en el que esto podría funcionar con un conjunto de elementos únicos no estáticos es si tiene datos de un solo elemento en una matriz de objetos que se barajan y luego se usan para construir y reemplazar HTML en géneros iniciados por el usuario que siempre vincula el orden del HTML a otras dependencias de seguimiento de datos.
El enfoque no Jquery (no probado):
var myContainer = document.getElementById('stuffContainer');
//ignore following indent goof
myContainer.addEventListener('click', function(e){
var
singleItem,
elementOriginallyClicked = singleItem = e.target,
stuffContainer = this;
//anything clicked inside myContainer will trigger a click event on myContainer
//the original element clicked is e.target
//google 'event bubbling javascript' or 'event delegation javascript' for more info
//climb parentNodes until we get to a single-item node
//unless it's already single-item that was originally clicked
while(!singleItem.className.match(/[=\s'"]single-item[\s'"]/g)){
singleItem = singleItem.parentNode;
}
//You now have a reference to the element you care about
//If you want the index:
//Get the singleItem's parent's childNodes collection and convert to array
//then use indexOf (MDN has normalizer for IE<=8) to get the index of the single-item
var childArray = Array.prototype.slice.apply(stuffContainer.childNodes,[0]),
thisIndex = childArray.indexOf(singleItem);
doSomethingWithIndex(thisIndex);
//or
//doSomethingWithDOMObject(singleItem);
});
O sencilla jQuery estilo de delegación (también, no probado):
$('#someContainer').on('click','.single-item', function(){
var $_singleItem = $(this), //jq handles the bubble to the interesting node for you
thisIndex = $_singleItem.index(); //also getting index relative to parent
doSomethingWithIndex(thisIndex);
//or
//doSomethingWithJQObject($_thisItem);
});
puede actualy dar puntos de bonificación, yopu parecer toi tienen un montón. acaba de establecer una recompensa ;-) – Pevara
Hice [una simple prueba JSPerf] (http://jsperf.com/html-dom-id-vs-no-id) y obtengo resultados muy variados (la prueba podría no ser buena sin embargo), incluso en el mismo navegador (Chrome) en diferentes ventanas. El análisis del HTML podría tomar la mayor parte del tiempo, entonces [aquí hay una versión] (http://jsperf.com/html-dom-id-vs-no-id/2) donde cada elemento tiene el mismo número de atributos, pero los mismos resultados mixtos. Creo que en cuanto a rendimiento (como construir un índice, etc.) esto realmente no hace la diferencia. –
@FelixKling interesante, gracias por armar las pruebas; en mi extremo (Chrome 20 y Firefox 14) parece que la versión sin identificación es ligeramente (muy ligeramente) más rápida. – Mahn