El caso contra los globales nombrados

Anteriormente, dije que usar elementos globales con nombre como referencias podría no ser la mejor idea. Hay muchas razones para eso, que TJ VanToll ha cubierto muy bien en su blog y lo resumiré aquí:

• Si el DOM cambia, también lo hace la referencia. Eso hace que algunos sean realmente "frágiles" (el término de la especificación para ello) código donde la separación de preocupaciones entre HTML y JavaScript podría ser demasiado.
• Las referencias accidentales son demasiado fáciles. Un simple error tipográfico puede muy bien terminar haciendo referencia a un nombre global y darte resultados inesperados.
• Se implementa de manera diferente en los navegadores. Por ejemplo, deberíamos poder acceder a un ancla con un id - p.ej — pero algunos navegadores (a saber, Safari y Firefox) devuelven un ReferenceError en la consola.
• Puede que no devuelva lo que piensas. De acuerdo con la especificación, cuando hay varias instancias del mismo elemento con nombre en el DOM, por ejemplo, dos instancias de

  — el navegador debería devolver un HTMLCollection con una matriz de las instancias. Firefox, sin embargo, solo devuelve la primera instancia. Entonces otra vez, la especificación dice deberíamos usar una instancia de un id en el árbol de un elemento de todos modos. Pero hacerlo no impedirá que una página funcione ni nada por el estilo.

• Tal vez hay un costo de rendimiento? Quiero decir, el navegador tiene que hacer esa lista de referencias y mantenerla. Un par de personas hicieron pruebas en este hilo de StackOverflow, donde los globales con nombre eran en realidad más rendimiento en una prueba y menos rendimiento en una prueba más reciente.

Consideraciones adicionales

Digamos que descartamos las críticas contra el uso de globales con nombre y los usamos de todos modos. Está todo bien. Pero hay algunas cosas que quizás desee considerar mientras lo hace.

polirellenos

Por más exagerado que parezca, este tipo de comprobaciones globales son un requisito de configuración típico para los polyfills. Mira el siguiente ejemplo donde configuramos una cookie usando el nuevo CookieStore API, polillenándolo en navegadores que aún no lo admiten:

  
  
    // Polyfill the CookieStore API if not yet implemented.
    // https://developer.mozilla.org/en-US/docs/Web/API/CookieStore
    if (!window.cookieStore) {
      window.cookieStore = myCookieStorePolyfill;
    }
    cookieStore.set("foo", "bar");
  

Este código funciona perfectamente bien en Chrome, pero arroja el siguiente error en Safari:

TypeError: cookieStore.set is not a function

Safari carece de soporte para el CookieStore API a partir de este escrito. Como resultado, el polyfill no se aplica porque el img elemento ID crea una variable global que choca con el cookieStore global.

Actualizaciones de la API de JavaScript

Podemos cambiar la situación y encontrar otro problema donde las actualizaciones del motor de JavaScript del navegador pueden romper las referencias globales de un elemento con nombre.

Por ejemplo:

  
  
    window.BarcodeDetector.focus();
  

Ese script toma una referencia al elemento de entrada e invoca focus() en eso. Funciona correctamente. Aún así, no sabemos cómo Corto seguirá funcionando.

Verá, la variable global que estamos usando para hacer referencia al elemento de entrada dejará de funcionar tan pronto como los navegadores comiencen a admitir el BarcodeDetector API. En ese punto, el window.BarcodeDetector global ya no será una referencia al elemento de entrada y .focus() lanzará un “window.BarcodeDetector.focus no es un error de función”.

Bonificación: no todos los elementos con nombre generan referencias globales

¿Quieres escuchar algo gracioso? Para colmo de males, los elementos con nombre son accesibles como variables globales solo si los nombres no contienen más que letras. Los navegadores no crearán una referencia global para un elemento con una ID que contenga caracteres especiales y números, como hello-world y item1.

Conclusión

Resumamos cómo llegamos aquí:

• Todos los principales navegadores crean automáticamente referencias globales a cada elemento DOM con un id (o, en algunos casos, un name atributo).
• Acceder a estos elementos a través de sus referencias globales no es confiable y es potencialmente peligroso. Usar querySelector or getElementById preferiblemente.
• Dado que las referencias globales se generan automáticamente, pueden tener algunos efectos secundarios en su código. Esa es una buena razón para evitar usar el id atributo a menos que realmente lo necesite.

Al final del día, probablemente sea una buena idea evitar el uso de globales con nombre en JavaScript. Cité la especificación anteriormente sobre cómo conduce a un código "frágil", pero aquí está el texto completo para aclarar el punto:

Como regla general, confiar en esto conducirá a un código frágil. Los ID que terminan mapeándose en esta API pueden variar con el tiempo, a medida que se agregan nuevas funciones a la plataforma web, por ejemplo. En lugar de esto, utilice document.getElementById() or document.querySelector().

Creo que el hecho de que la propia especificación HTML recomiende mantenerse alejado de esta función habla por sí solo.