Ho sentito molte volte che usare eventi JavaScript, come onClick()HTML, è una cattiva pratica, perché non è buono per la semantica. Vorrei sapere quali sono gli svantaggi e come risolvere il codice seguente?

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

Probabilmente stai parlando di Javascript discreto , che sarebbe simile a questo:

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

con la logica in un file JavaScript centrale simile a questo:

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

I vantaggi sono:

• il comportamento (Javascript) è separato dalla presentazione (HTML)
• nessuna miscelazione di lingue
• stai utilizzando un framework javascript come jQuery in grado di gestire la maggior parte dei problemi tra browser
• È possibile aggiungere il comportamento a molti elementi HTML contemporaneamente senza duplicazione del codice

Se stai usando jQuery, allora:

HTML:

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

JS:

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

Questo ha il vantaggio di continuare a lavorare senza JS o se l'utente fa clic sul collegamento al centro.

Significa anche che potrei gestire i popup generici riscrivendoli di nuovo 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;
    });
});

Ciò ti consentirebbe di aggiungere un popup a qualsiasi link semplicemente assegnandogli la classe popup.

Questa idea potrebbe essere ulteriormente estesa in questo modo:

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;
    });
});

Ora posso usare lo stesso codice per molti popup su tutto il mio sito senza dover scrivere un sacco di cose onclick! Yay per riusabilità!

Significa anche che se in seguito decido che i popup sono cattive pratiche (che sono!) E che voglio sostituirli con una finestra modale in stile lightbox, posso cambiare:

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

per

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

e tutti i miei popup sull'intero sito ora funzionano in modo totalmente diverso. Potrei anche fare il rilevamento delle funzionalità per decidere cosa fare in un popup o memorizzare le preferenze degli utenti per consentirli o meno. Con il clic on-line, ciò richiede un enorme sforzo di copia e incolla.

Con applicazioni JavaScript di dimensioni molto grandi, i programmatori utilizzano una maggiore incapsulamento del codice per evitare di inquinare l'ambito globale. E per rendere una funzione disponibile per l'azione onClick in un elemento HTML, deve essere nell'ambito globale.

Potresti aver visto i file JS che assomigliano a questo ...

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

Si tratta di espressioni di funzione invocate immediatamente (IIFE) e qualsiasi funzione dichiarata al loro interno esiste solo nell'ambito di applicazione interno.

Se dichiari function doSomething(){}all'interno di un IIFE, quindi esegui doSomething()un'azione onClick di un elemento nella tua pagina HTML, otterrai un errore.

Se, d'altra parte, crei un eventListener per quell'elemento all'interno di quell'IIFE e chiami doSomething()quando l'ascoltatore rileva un evento click, sei bravo perché ascoltatore e doSomething()condividi l'ambito di IIFE.

Per le piccole app Web con una quantità minima di codice, non importa. Ma se aspiri a scrivere basi di codice grandi e mantenibili, onclick=""è un'abitudine che dovresti lavorare per evitare.

Non va bene per diversi motivi:

• mescola codice e markup
• il codice scritto in questo modo passa attraverso eval
• e funziona nell'ambito globale

La cosa più semplice sarebbe aggiungere un nameattributo al tuo <a>elemento, quindi potresti fare:

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

sebbene la migliore pratica moderna sarebbe quella di usare un idinvece di un nome, e usare addEventListener()invece di usare onclickpoiché ciò consente di associare più funzioni a un singolo evento.

Ci sono alcuni motivi:

1. Trovo che aiuti la manutenzione per separare il markup, vale a dire l'HTML e gli script lato client. Ad esempio, jQuery semplifica l'aggiunta programmativa di gestori di eventi.

2. L'esempio fornito verrà interrotto in qualsiasi agente utente che non supporta javascript o che JavaScript è disattivato. Il concetto di miglioramento progressivo incoraggerebbe un semplice collegamento ipertestuale /map/per gli user agent senza javascript, quindi l'aggiunta di un gestore di clic in modo prgrammatico per gli user agent che supportano javascript.

Per esempio:

markup:

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

Javascript:

$(document).ready(function(){

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

})

Revisione

L' approccio JavaScript non invadente è stato positivo nel PAST, in particolare il legame del gestore di eventi in HTML è stato considerato una cattiva pratica (principalmente perché onclick events run in the global scope and may cause unexpected errorciò che è stato menzionato da YiddishNinja )

Però...

Attualmente sembra che questo approccio sia un po 'datato e necessiti di un aggiornamento. Se qualcuno vuole essere uno sviluppatore di frontend professionale e scrivere app di grandi dimensioni e complicate, allora deve usare framework come Angular, Vue.js, ecc ... Comunque quei framework usano solitamente (o permettono di usare) template HTML dove i gestori di eventi sono vincolati nel codice del modello html direttamente e questo è molto utile, chiaro ed efficace - ad esempio nel modello angolare di solito le persone scrivono:

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

In js / html non elaborato sarà l'equivalente di questo

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

La differenza è che nel raw js l' onclickevento viene eseguito nell'ambito globale - ma i framework forniscono l'incapsulamento.

Quindi dov'è il problema?

Il problema è quando il programmatore principiante che ha sempre sentito che html-onclick è male e che usa sempre btn.addEventListener("onclick", ... )vuole usare un framework con i template (ha addEventListeneranche degli svantaggi - se aggiorniamo DOM in modo dinamico usando innerHTML=(che è piuttosto veloce ) - perdiamo gli eventi i gestori si legano in quel modo). Quindi dovrà affrontare qualcosa come le cattive abitudini o l'approccio sbagliato all'utilizzo del framework - e userà il framework in modo molto cattivo - perché si concentrerà principalmente su js-part e no su template-part (e produrrà poco chiaro e difficile da mantenere codice). Per cambiare questa abitudine perderà molto tempo (e probabilmente avrà bisogno di fortuna e di insegnante).

Quindi secondo me, in base all'esperienza con i miei studenti, sarebbe meglio per loro se all'inizio usassero html-handlers-bind. Come ho detto, è vero che i gestori sono chiamati in ambito globale, ma in questa fase gli studenti di solito creano piccole applicazioni che sono facili da controllare. Per scrivere applicazioni più grandi scelgono alcuni framework.

Quindi che si fa?

Possiamo AGGIORNARE l'approccio JavaScript discreto e consentire i gestori di eventi bind (eventualmente con parametri semplici) in html (ma solo il gestore bind - non mettere la logica in onclick come in OP quesiton). Quindi secondo me in js / html non elaborati questo dovrebbe essere permesso

<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>

Ma sotto gli esempi NON dovrebbero essere ammessi

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

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

La realtà cambia, anche il nostro punto di vista dovrebbe

È un nuovo paradigma chiamato " JavaScript discreto ". L'attuale "standard web" dice di separare funzionalità e presentazione.

Non è proprio una "cattiva pratica", è solo che la maggior parte dei nuovi standard vuole che tu usi gli ascoltatori di eventi invece di incorporare JavaScript.

Inoltre, questa potrebbe essere solo una cosa personale, ma penso che sia molto più facile da leggere quando usi i listener di eventi, specialmente se hai più di una dichiarazione JavaScript che vuoi eseguire.

La tua domanda scatenerà la discussione, suppongo. L'idea generale è che è bene separare comportamento e struttura. Inoltre, un gestore di clic inline deve essere evalportato a "diventare" una vera funzione javascript. Ed è piuttosto vecchio stile, anche se questa è una discussione piuttosto traballante. Ah, beh, leggi qualcosa a riguardo @ quirksmode.org

• gli eventi onclick vengono eseguiti nell'ambito globale e possono causare errori imprevisti.
• L'aggiunta di eventi onclick a molti elementi DOM rallenterà le
  prestazioni e l'efficienza.

Altre due ragioni per non usare i gestori in linea:

Possono richiedere noiose citazioni che sfuggono alle quotazioni

Dato un arbitrario stringa, se si vuole essere in grado di costruire un gestore di linea che chiama una funzione con quella stringa, per la soluzione generale, si dovrà sfuggire alle attributi delimitatori (con l'entità HTML associato), e sarete deve uscire dal delimitatore usato per la stringa all'interno dell'attributo, come il seguente:

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>'
);

È incredibilmente brutto. Dall'esempio precedente, se non si sostituisce 's, si otterrebbe un errore di alert('foo'"bar')sintassi , poiché non è una sintassi valida. Se non sostituissi i messaggi di posta "elettronica, il browser lo interpreterebbe come una fine onclickdell'attributo (delimitato con "i messaggi precedenti), che sarebbe anche errato.

Se si usano abitualmente gestori in linea, si dovrebbe assicurarsi di ricordare di fare qualcosa di simile a quanto sopra (e farlo bene ) ogni volta , che è noioso e difficile da capire a colpo d'occhio. Meglio evitare completamente i gestori inline in modo che la stringa arbitraria possa essere utilizzata in una semplice chiusura:

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);

Non è molto più bello?

La catena di portata di un gestore in linea è estremamente peculiare

Cosa pensi che registrerà il seguente codice?

let disabled = true;

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

Provalo, esegui lo snippet. Probabilmente non è quello che ti aspettavi. Perché produce quello che fa? Perché i gestori inline corrono all'interno di withblocchi. Il codice sopra è all'interno di tre with blocchi: uno per il document, uno per il <form>e uno per il <button>:

let disabled = true;

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

Poiché disabledè una proprietà del pulsante, il riferimento disabledall'interno del gestore inline si riferisce alla proprietà del pulsante, non alla disabledvariabile esterna . Questo è abbastanza intuitivo. withha molti problemi: può essere la fonte di bug confusi e rallenta significativamente il codice. Non è nemmeno permesso affatto in modalità rigorosa. Ma con i gestori in linea, lo sei costretto a eseguire il codice attraverso withs - e non solo attraverso uno with, ma attraverso più withs nidificati . È pazzesco.

withnon dovrebbe mai essere usato nel codice. Poiché i gestori inline implicitamente richiedono withinsieme a tutto il suo comportamento confuso, anche i gestori inline dovrebbero essere evitati.