¿Hay algún inconveniente en la inyección de JavaScript basada en clase?

Question

Un fenómeno que estoy viendo cada vez más es el código JavaScript que está vinculado a un elemento en particular en una página en particular, en lugar de estar vinculado a tipo de elementos o patrones de ui.

Por ejemplo, digamos que teníamos un par de menús animados en una página:

<ul id="top-navigation">
    ...
</ul>

<!-- ... -->

<ul id="product-list">
    ...
</ul>

Estos dos menús pueden existir en la misma página o en diferentes páginas, y algunas páginas pueden no tener menús.

A menudo veré un código JavaScript como este (para estos ejemplos, estoy usando jQuery):

$(document).ready(function() {
    $('ul#top-navigation').dropdownMenu();
    $('ul#product-selector').dropdownMenu();
});

¿Notes el problema?

El JavaScript está muy acoplado a instancias particulares de un patrón UI en lugar del patrón de UI en sí.

Ahora, ¿no sería mucho más simple (y más limpio) hacer esto en su lugar? -

$(document).ready(function() {
    $('ul.dropdown-menu').dropdownMenu();
});

Luego podemos poner la clase 'desplegable-menú' en nuestras listas como así:

<ul id="top-navigation" class="dropdown-menu">
    ...
</ul>

<!-- ... -->

<ul id="product-list" class="dropdown-menu">
    ...
</ul>

Esta forma de hacer las cosas tendría los siguientes beneficios:

• JavaScript más simple: solo necesitamos adjuntar una vez a la clase.
• Evitamos buscar instancias específicas que puedan no existir en una página determinada.
• Si eliminamos un elemento, no necesitamos cazar a través del JavaScript para encontrar el código adjunto para ese elemento.

Creo que las técnicas similares fueron pioneras por ciertos artículos en Alistapart.com.

Me sorprende que estas técnicas simples aún no hayan obtenido una adopción generalizada, y todavía veo las muestras de código de 'mejores prácticas' y los marcos de JavaScript que se refieren directamente a las instancias de la interfaz de usuario en lugar de los patrones de interfaz de usuario.

Hay alguna razón para esto? ¿Hay alguna gran desventaja en la técnica que acabo de describir de la que no soy consciente?

Answer 1

En primer lugar, estoy de acuerdo con usted en que usar el enfoque de clase es mejor, en general.

Pero no creo que llegue tan lejos como para decir que es menos acoplamiento del código para la interfaz de usuario. Si lo piensa, si el código asume ID "Foo" vs. Nombre de clase "Foo", aún tiene que saberlo cuando trabaje con la interfaz de usuario. Todavía hay un 'contrato' entre ellos, ya sea que lo cumpla a través de ID o clase no es realmente diferente.

Una desventaja para usar el enfoque de clase que imagino es la velocidad: debería ser más rápido encontrar un elemento particular por ID que encontrar elementos potencialmente múltiples por clase. Sin embargo, la diferencia es probablemente completamente insignificante.

Pero, en el caso de que su código esté diseñado para adjuntar múltiples comportamientos, como en su ejemplo de dos drogas, usar clase ciertamente tiene más sentido. Eso es menos acoplamiento ya que su código está un poco más generalizado, y es más probable que su interfaz de usuario sea personalizable sin cambiar el código.

Una cosa que cambiaría en sus dos ejemplos ... ¿por qué tener el UL en el selector? Si el código sabe que solo puede funcionar si el objetivo es un UL, bueno, eso es una cosa, pero en ese caso, sería mejor evitar el UL en el selector y dejar que el código arroje un error significativo si el Se encuentra que el objetivo no es un UL, para que la página no haga nada sin ninguna indicación de por qué (por ejemplo, porque la interfaz de usuario pone la identificación/clase en un OL).

Entonces, en otras palabras, solo "#foo" o ".foo" no "ul.foo", etc.

Debo señalar que en caso de que alguien piense que la UL de alguna manera hace que el selector sea más eficiente, no lo hace, ya que los selectores se evalúan de derecha a izquierda.

Answer 2

Se prefiere su enfoque.

La razón por la que las personas hacen las cosas de diferentes maneras es porque pueden y todavía funciona.