Muchas veces he escuchado que usar eventos JavaScript, como onClick()HTML, es una mala práctica, porque no es bueno para la semántica. Me gustaría saber cuáles son las desventajas y cómo solucionar el siguiente código.

<a href="#" onclick="popup('/map/', 300, 300, 'map'); return false;">link</a>

Probablemente estés hablando de un JavaScript discreto , que se vería así:

<a href="#" id="someLink">link</a>

con la lógica en un archivo javascript central que se parece a esto:

$('#someLink').click(function(){
    popup('/map/', 300, 300, 'map'); 
    return false;
});

Las ventajas son

• el comportamiento (Javascript) está separado de la presentación (HTML)
• no mezclar idiomas
• está utilizando un marco de JavaScript como jQuery que puede manejar la mayoría de los problemas entre navegadores por usted
• Puede agregar comportamiento a muchos elementos HTML a la vez sin duplicación de código

Si está utilizando jQuery, entonces:

HTML:

 <a id="openMap" href="/map/">link</a>

JS:

$(document).ready(function() {
    $("#openMap").click(function(){
        popup('/map/', 300, 300, 'map');
        return false;
    });
});

Esto tiene la ventaja de seguir trabajando sin JS, o si el usuario hace clic en el medio del enlace.

También significa que podría manejar ventanas emergentes genéricas reescribiendo nuevamente a:

HTML:

 <a class="popup" href="/map/">link</a>

JS:

$(document).ready(function() {
    $(".popup").click(function(){
        popup($(this).attr("href"), 300, 300, 'map');
        return false;
    });
});

Esto le permitiría agregar una ventana emergente a cualquier enlace simplemente dándole la clase emergente.

Esta idea podría extenderse aún más así:

HTML:

 <a class="popup" data-width="300" data-height="300" href="/map/">link</a>

JS:

$(document).ready(function() {
    $(".popup").click(function(){
        popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');
        return false;
    });
});

¡Ahora puedo usar el mismo código para muchas ventanas emergentes en todo mi sitio sin tener que escribir un montón de cosas onclick! ¡Yay por la reutilización!

También significa que si más tarde decido que las ventanas emergentes son una mala práctica (¡lo que son!) Y que quiero reemplazarlas con una ventana modal de estilo lightbox, puedo cambiar:

popup($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');

a

myAmazingModalWindow($(this).attr("href"), $(this).data('width'), $(this).data('height'), 'map');

y todas mis ventanas emergentes en todo mi sitio ahora funcionan de manera totalmente diferente. Incluso podría hacer una detección de funciones para decidir qué hacer en una ventana emergente, o almacenar una preferencia de los usuarios para permitirlos o no. Con el clic en línea, esto requiere una gran copia y un esfuerzo de pegado.

Con aplicaciones JavaScript muy grandes, los programadores están utilizando más encapsulación de código para evitar contaminar el alcance global. Y para que una función esté disponible para la acción onClick en un elemento HTML, debe estar en el ámbito global.

Es posible que haya visto archivos JS que se parecen a esto ...

(function(){
    ...[some code]
}());

Estas son expresiones de función invocadas inmediatamente (IIFE) y cualquier función declarada dentro de ellas solo existirá dentro de su alcance interno.

Si declara function doSomething(){}dentro de un IIFE, luego realiza doSomething()la acción onClick de un elemento en su página HTML, obtendrá un error.

Si, por otro lado, crea un EventListener para ese elemento dentro de ese IIFE y llama doSomething()cuando el oyente detecta un evento de clic, es bueno porque el oyente y doSomething()comparte el alcance del IIFE.

Para pequeñas aplicaciones web con una cantidad mínima de código, no importa. Pero si aspira a escribir bases de código grandes y fáciles de mantener, onclick=""es un hábito que debe evitar.

No es bueno por varias razones:

• mezcla código y marcado
• el código escrito de esta manera pasa por eval
• y se ejecuta en el ámbito global

Lo más simple sería agregar un nameatributo a su <a>elemento, luego podría hacer:

document.myelement.onclick = function() {
    window.popup('/map/', 300, 300, 'map');
    return false;
};

aunque la mejor práctica moderna sería usar un en idlugar de un nombre, y usar en addEventListener()lugar de usar onclickya que eso le permite vincular múltiples funciones a un solo evento.

Hay unas pocas razones:

1. Me parece que ayuda a mantener el marcado separado, es decir, los scripts HTML y del lado del cliente. Por ejemplo, jQuery facilita la adición de controladores de eventos mediante programación.

2. El ejemplo que proporcione se rompería en cualquier agente de usuario que no sea compatible con JavaScript o que tenga JavaScript desactivado. El concepto de mejora progresiva fomentaría un hipervínculo simple /map/para los agentes de usuario sin javascript, y luego agregaría un controlador de clics de forma protocolaria para los agentes de usuario que admitan javascript.

Por ejemplo:

Margen:

<a id="example" href="/map/">link</a>

Javascript:

$(document).ready(function(){

    $("#example").click(function(){
        popup('/map/', 300, 300, 'map');
        return false;
    });

})

Revisión

El enfoque discreto de JavaScript fue bueno en el PASADO, especialmente el enlace de controlador de eventos en HTML se consideró una mala práctica (principalmente porque onclick events run in the global scope and may cause unexpected errorlo mencionado por YiddishNinja )

Sin embargo...

Actualmente parece que este enfoque está un poco desactualizado y necesita alguna actualización. Si alguien quiere ser un desarrollador frontend profesional y escribir aplicaciones grandes y complicadas, entonces necesita usar marcos como Angular, Vue.js, etc. Sin embargo, esos marcos generalmente usan (o permiten usar) plantillas HTML donde los controladores de eventos están vinculados en el código html-template directamente y esto es muy útil, claro y efectivo, por ejemplo, en la plantilla angular la gente suele escribir:

<button (click)="someAction()">Click Me</button> 

En raw js / html el equivalente de esto será

<button onclick="someAction()">Click Me</button>

La diferencia es que en el onclickevento js sin procesar se ejecuta en el ámbito global, pero los marcos proporcionan la encapsulación.

¿Entonces, dónde está el problema?

El problema es cuando un programador novato que siempre escuchó que html-onclick es malo y que siempre usa btn.addEventListener("onclick", ... )quiere usar un marco con plantillas ( addEventListenertambién tiene inconvenientes , si actualizamos DOM usando dinámicamente innerHTML=(lo cual es bastante rápido ), entonces perdemos eventos los manejadores se unen de esa manera). Luego se enfrentará a algo como malos hábitos o enfoque incorrecto para el uso del marco, y usará el marco de una manera muy mala, porque se centrará principalmente en la parte js y no en la parte de la plantilla (y producirá poco claro y difícil de mantener código). Para cambiar estos hábitos, perderá mucho tiempo (y probablemente necesitará algo de suerte y un maestro).

En mi opinión, según la experiencia con mis alumnos, sería mejor para ellos si utilizan html-handlers-bind al principio. Como digo, es cierto que los controladores son de alcance global, pero en esta etapa los estudiantes generalmente crean pequeñas aplicaciones que son fáciles de controlar. Para escribir aplicaciones más grandes, eligen algunos marcos.

¿Entonces lo que hay que hacer?

Podemos ACTUALIZAR el enfoque de JavaScript discreto y permitir controladores de eventos de enlace (eventualmente con parámetros simples) en html (pero solo controlador de enlace, no poner lógica en onclick como en la pregunta OP). Entonces, en mi opinión en js / html sin procesar, esto debería permitirse

<button onclick="someAction(3)">Click Me</button>

o

function popup(num,str,event) {
   let re=new RegExp(str);  
   // ... 
   event.preventDefault();
   console.log("link was clicked");
}

<a href="https://example.com" onclick="popup(300,'map',event)">link</a>

Pero los ejemplos a continuación NO deberían permitirse

<button onclick="console.log('xx'); someAction(); return true">Click Me</button>

<a href="#" onclick="popup('/map/', 300, 300, 'map'); return false;">link</a>

La realidad cambia, nuestro punto de vista también debería

Es un nuevo paradigma llamado " JavaScript discreto ". El "estándar web" actual dice separar la funcionalidad y la presentación.

No es realmente una "mala práctica", es solo que la mayoría de los estándares nuevos quieren que uses oyentes de eventos en lugar de JavaScript en línea.

Además, esto puede ser algo personal, pero creo que es mucho más fácil de leer cuando usa oyentes de eventos, especialmente si tiene más de 1 declaración de JavaScript que desea ejecutar.

Su pregunta desencadenará la discusión, supongo. La idea general es que es bueno separar el comportamiento y la estructura. Además, afaik, un controlador de clics en línea tiene que ser eval'convertido' en una verdadera función de JavaScript. Y es bastante anticuado, aunque ese es un argumento bastante inestable. Ah, bueno, lee algo al respecto @ quirksmode.org

• Los eventos onclick se ejecutan en el ámbito global y pueden causar un error inesperado.
• Agregar eventos onclick a muchos elementos DOM disminuirá el
  rendimiento y la eficiencia.

Dos razones más para no usar controladores en línea:

Pueden requerir problemas tediosos de escape de cotizaciones

Dada una arbitraria cadena, si usted quiere ser capaz de construir un controlador de línea que llama a una función con la cadena, por la solución general, que tendrá que escapar de los atributos delimitadores (con la entidad HTML asociado), y se le tiene que escapar del delimitador utilizado para la cadena dentro del atributo, como el siguiente:

const str = prompt('What string to display on click?', 'foo\'"bar');
const escapedStr = str
  // since the attribute value is going to be using " delimiters,
  // replace "s with their corresponding HTML entity:
  .replace(/"/g, '"')
  // since the string literal inside the attribute is going to delimited with 's,
  // escape 's:
  .replace(/'/g, "\\'");
  
document.body.insertAdjacentHTML(
  'beforeend',
  '<button onclick="alert(\'' + escapedStr + '\')">click</button>'
);

Eso es increíblemente feo. En el ejemplo anterior, si no reemplazó la 's, se produciría un SyntaxError, porque alert('foo'"bar')no es una sintaxis válida. Si no reemplazó el "s, entonces el navegador lo interpretaría como un fin al onclickatributo (delimitado con "s arriba), que también sería incorrecto.

Si uno usa habitualmente manipuladores en línea, debe asegurarse de recordar hacer algo similar a lo anterior (y hacerlo bien ) cada vez , lo cual es tedioso y difícil de entender de un vistazo. Es mejor evitar los controladores en línea por completo para que la cadena arbitraria se pueda usar en un cierre simple:

const str = prompt('What string to display on click?', 'foo\'"bar');
const button = document.body.appendChild(document.createElement('button'));
button.textContent = 'click';
button.onclick = () => alert(str);

¿No es eso mucho mejor?

La cadena de alcance de un controlador en línea es extremadamente peculiar

¿Qué crees que registrará el siguiente código?

let disabled = true;

<form>
  <button onclick="console.log(disabled);">click</button>
</form>

Pruébalo, ejecuta el fragmento. Probablemente no sea lo que estabas esperando. ¿Por qué produce lo que hace? Porque los manejadores en línea se ejecutan dentro de withbloques. El código anterior está dentro de tres with bloques: uno para el document, uno para el <form>y otro para el <button>:

let disabled = true;

<form>
  <button onclick="console.log(disabled);">click</button>
</form>

Como disabledes una propiedad del botón, la referencia disableddentro del controlador en línea se refiere a la propiedad del botón, no a la disabledvariable externa . Esto es bastante contrario a la intuición. withtiene muchos problemas: puede ser la fuente de errores confusos y ralentiza significativamente el código. Ni siquiera está permitido en modo estricto. Pero con los controladores en línea, se ve obligado a ejecutar el código a través de withs, y no solo a través de uno with, sino a través de múltiples withs anidados . Es una locura.

withnunca debe usarse en código. Debido a que los controladores en línea requieren implícitamente withjunto con todo su comportamiento confuso, también deben evitarse los controladores en línea.