Qual è la differenza tra addEventListenere onclick?

var h = document.getElementById("a");
h.onclick = dothing1;
h.addEventListener("click", dothing2);

Il codice sopra si trova insieme in un file .js separato ed entrambi funzionano perfettamente.

Entrambi sono corretti, ma nessuno di essi è "il migliore" di per sé e potrebbe esserci un motivo per cui lo sviluppatore ha scelto di utilizzare entrambi gli approcci.

Listener di eventi (addEventListener e IE's attachEvent)

Le versioni precedenti di Internet Explorer implementano javascript in modo diverso da qualsiasi altro browser. Con versioni inferiori a 9, si utilizza il metodo attachEvent[ doc ], in questo modo:

element.attachEvent('onclick', function() { /* do stuff here*/ });

Nella maggior parte degli altri browser (incluso IE 9 e versioni successive), usi addEventListener[ doc ], in questo modo:

element.addEventListener('click', function() { /* do stuff here*/ }, false);

Utilizzando questo approccio ( eventi DOM livello 2 ), è possibile collegare un numero teoricamente illimitato di eventi a qualsiasi singolo elemento. L'unica limitazione pratica è la memoria lato client e altri problemi di prestazioni, che sono diversi per ciascun browser.

Gli esempi precedenti rappresentano l'utilizzo di una funzione anonima [ doc ]. Puoi anche aggiungere un listener di eventi usando un riferimento di funzione [ doc ] o una chiusura [ doc ]:

var myFunctionReference = function() { /* do stuff here*/ }

element.attachEvent('onclick', myFunctionReference);
element.addEventListener('click', myFunctionReference , false);

Un'altra caratteristica importante di addEventListenerè il parametro finale, che controlla il modo in cui l'ascoltatore reagisce agli eventi gorgoglianti [ doc ]. Ho passato falsi negli esempi, che è standard per probabilmente il 95% dei casi d'uso. Non esiste un argomento equivalente per attachEvento quando si utilizzano eventi inline.

Eventi incorporati (HTML onclick = "" proprietà ed element.onclick)

In tutti i browser che supportano JavaScript, puoi mettere in linea un listener di eventi, il che significa proprio nel codice HTML. Probabilmente hai visto questo:

<a id="testing" href="#" onclick="alert('did stuff inline');">Click me</a>

Gli sviluppatori più esperti evitano questo metodo, ma ottiene il lavoro fatto; è semplice e diretto. Non è possibile utilizzare chiusure o funzioni anonime qui (anche se il gestore stesso è una sorta di funzione anonima) e il controllo dell'ambito è limitato.

L'altro metodo che menzioni:

element.onclick = function () { /*do stuff here */ };

... è l'equivalente di JavaScript inline, tranne per il fatto che hai un maggiore controllo dell'ambito (poiché stai scrivendo uno script anziché HTML) e puoi utilizzare funzioni anonime, riferimenti di funzione e / o chiusure.

Lo svantaggio significativo degli eventi inline è che, diversamente dai listener di eventi sopra descritti, è possibile assegnare un solo evento inline. Gli eventi incorporati sono memorizzati come un attributo / proprietà dell'elemento [ doc ], il che significa che può essere sovrascritto.

Utilizzando l'esempio <a>dall'HTML sopra:

var element = document.getElementById('testing');
element.onclick = function () { alert('did stuff #1'); };
element.onclick = function () { alert('did stuff #2'); };

... quando fai clic sull'elemento, vedrai solo "Did stuff # 2" - hai sovrascritto il primo assegnato della onclickproprietà con il secondo valore e hai sovrascritto anche la onclickproprietà HTML incorporata originale . Dai un'occhiata qui: http://jsfiddle.net/jpgah/ .

In linea di massima, non utilizzare eventi in linea . Potrebbero esserci casi d'uso specifici per questo, ma se non sei sicuro al 100% di avere quel caso d'uso, allora non devi e non dovresti usare eventi in linea.

Javascript moderno (angolare e simili)

Da quando questa risposta è stata originariamente pubblicata, i framework javascript come Angular sono diventati molto più popolari. Vedrai un codice come questo in un modello angolare:

<button (click)="doSomething()">Do Something</button>

Sembra un evento in linea, ma non lo è. Questo tipo di modello verrà trasformato in codice più complesso che utilizza i listener di eventi dietro le quinte. Tutto ciò che ho scritto sugli eventi qui si applica ancora, ma tu sei rimosso dal grintoso nocciolo di almeno uno strato. Dovresti capire i dettagli, ma se le tue migliori pratiche del framework JS moderno prevedono la scrittura di questo tipo di codice in un modello, non pensare di utilizzare un evento in linea - non lo sei.

Qual è il migliore?

La domanda è una questione di compatibilità e necessità del browser. Devi collegare più di un evento a un elemento? Lo farai in futuro? Le probabilità sono, lo farai. attachEvent e addEventListener sono necessari. Altrimenti, un evento in linea può sembrare che farebbero il trucco, ma sei molto meglio servito a prepararti per un futuro che, sebbene possa sembrare improbabile, almeno è prevedibile. È possibile che tu debba passare a listener di eventi basati su JS, quindi potresti anche iniziare da lì. Non utilizzare eventi in linea.

jQuery e altri framework javascript incapsulano le diverse implementazioni del browser degli eventi di livello DOM 2 in modelli generici in modo da poter scrivere codice conforme a più browser senza doversi preoccupare della storia di IE come ribelle. Stesso codice con jQuery, tutto cross-browser e pronto per il rock:

$(element).on('click', function () { /* do stuff */ });

Non finire e ottenere un framework solo per questa cosa, però. Puoi facilmente girare la tua piccola utility per occuparti dei browser più vecchi:

function addEvent(element, evnt, funct){
  if (element.attachEvent)
   return element.attachEvent('on'+evnt, funct);
  else
   return element.addEventListener(evnt, funct, false);
}

// example
addEvent(
    document.getElementById('myElement'),
    'click',
    function () { alert('hi!'); }
);

Provalo: http://jsfiddle.net/bmArj/

Considerando tutto ciò, a meno che lo script che stai osservando non tenga conto delle differenze del browser in un altro modo (nel codice non mostrato nella tua domanda), la parte che utilizza addEventListenernon funzionerebbe nelle versioni di IE inferiori a 9.

Documentazione e lettura correlata

• Specifica HTML W3, elemento Attributi gestore eventi
• element.addEventListener su MDN
• element.attachEvent su MSDN
• Jquery.on
• blog quirksmode "Introduzione agli eventi"
• Librerie javascript ospitate da CDN su Google

La differenza che potresti vedere se avessi un'altra coppia di funzioni:

var h = document.getElementById('a');
h.onclick = doThing_1;
h.onclick = doThing_2;

h.addEventListener('click', doThing_3);
h.addEventListener('click', doThing_4);

Le funzioni 2, 3 e 4 funzionano, ma 1 no. Questo perché addEventListenernon sovrascrive i gestori di eventi esistenti, mentre onclicksovrascrive eventuali onclick = fngestori di eventi esistenti .

L'altra differenza significativa, ovviamente, è che onclickfunzionerà sempre, mentre addEventListenernon funziona in Internet Explorer prima della versione 9. Puoi usare l'analogo attachEvent(che ha leggermente sintassi diversa) in IE <9.

In questa risposta descriverò i tre metodi per definire i gestori di eventi DOM.

element.addEventListener()

Esempio di codice:

const element = document.querySelector('a');
element.addEventListener('click', event => event.preventDefault(), true);

<a href="//google.com">Try clicking this link.</a>

element.addEventListener() ha molteplici vantaggi:

• Consente di registrare gestori di eventi illimitati e rimuoverli con element.removeEventListener().
• Ha un useCaptureparametro, che indica se si desidera gestire l'evento nella sua fase di acquisizione o bolle . Vedi: Impossibile capire l'attributo useCapture in addEventListener .
• Si preoccupa della semantica . Fondamentalmente, rende più esplicita la registrazione dei gestori di eventi. Per un principiante, una chiamata di funzione rende ovvio che succede qualcosa , mentre l'assegnazione di eventi ad alcune proprietà dell'elemento DOM non è almeno intuitiva.
• Consente di separare la struttura del documento (HTML) e la logica (JavaScript) . In piccole applicazioni web potrebbe non sembra avere importanza, ma fa materia con qualsiasi progetto più grande. È molto più semplice mantenere un progetto che separa struttura e logica rispetto a un progetto che non lo fa.
• Elimina la confusione con i nomi degli eventi corretti. A causa dell'utilizzo dei listener di eventi inline o dell'assegnazione dei listener di eventi alle .oneventproprietà degli elementi DOM, molti programmatori JavaScript inesperti pensano che il nome dell'evento sia ad esempio onclicko onload. nonon fa parte del nome dell'evento . I nomi degli eventi corretti sono clicke load, ed è così che vengono passati i nomi degli eventi .addEventListener().
• Funziona in quasi tutti i browser . Se devi ancora supportare IE <= 8, puoi usare un polyfill da MDN .

element.onevent = function() {}(ad es onclick. onload)

Esempio di codice:

const element = document.querySelector('a');
element.onclick = event => event.preventDefault();

<a href="//google.com">Try clicking this link.</a>

Questo era un modo per registrare i gestori di eventi in DOM 0. Ora è scoraggiato, perché:

• Consente di registrare solo un gestore eventi. Anche la rimozione del gestore assegnato non è intuitiva, poiché per rimuovere il gestore eventi assegnato utilizzando questo metodo, è necessario ripristinare la oneventproprietà allo stato iniziale (ad es null.).
• Non risponde agli errori in modo appropriato. Ad esempio, se per errore si assegna una stringa window.onload, ad esempio: window.onload = "test";non genererà errori. Il tuo codice non funzionerebbe e sarebbe davvero difficile scoprire perché. .addEventListener()tuttavia, verrebbe generato un errore (almeno in Firefox): TypeError: l'argomento 2 di EventTarget.addEventListener non è un oggetto .
• Non fornisce un modo per scegliere se si desidera gestire l'evento nella sua fase di acquisizione o bolle.

Gestori di eventi inline ( oneventattributo HTML)

Esempio di codice:

<a href="//google.com" onclick="event.preventDefault();">Try clicking this link.</a>

Allo stesso modo element.onevent, ora è scoraggiato. Oltre ai problemi che element.oneventha, esso:

• È un potenziale problema di sicurezza , perché rende XSS molto più dannoso. Oggigiorno i siti Web dovrebbero inviare Content-Security-Policyun'intestazione HTTP corretta per bloccare gli script incorporati e consentire gli script esterni solo da domini attendibili. Vedi Come funziona la politica di sicurezza dei contenuti?
• Non separa la struttura e la logica del documento .
• Se generi la tua pagina con uno script sul lato server e, ad esempio, generi un centinaio di collegamenti, ciascuno con lo stesso gestore di eventi inline, il tuo codice sarebbe molto più lungo rispetto a se il gestore di eventi fosse definito una sola volta. Ciò significa che il client dovrebbe scaricare più contenuti e, di conseguenza, il tuo sito web sarà più lento.

Guarda anche

• EventTarget.addEventListener()documentazione (MDN)
• EventTarget.removeEventListener()documentazione (MDN)
• onclick vs addEventListener
• dom-events tag wiki

Mentre onclickfunziona in tutti i browser, addEventListenernon funziona nelle versioni precedenti di Internet Explorer, che utilizza attachEventinvece.

Il rovescio della medaglia onclickè che può esserci solo un gestore di eventi, mentre gli altri due genereranno tutti i callback registrati.

Per quanto ne so, l'evento "load" DOM ​​funziona ancora solo in modo molto limitato. Ciò significa che sparerà solo per window object, imagesed <script>elementi per esempio. Lo stesso vale per l' onloadassegnazione diretta . Non c'è alcuna differenza tecnica tra questi due. Probabilmente .onload =ha una migliore disponibilità tra browser.

Tuttavia, non è possibile assegnare load eventa a <div>o <span>elemento o whatnot.

Sommario:

1. addEventListenerpuò aggiungere più eventi, mentre con onclickciò non si può fare.
2. onclickpuò essere aggiunto come HTMLattributo, mentre addEventListenerpuò essere aggiunto solo all'interno di <script>elementi.
3. addEventListener può prendere un terzo argomento che può fermare la propagazione dell'evento.

Entrambi possono essere utilizzati per gestire gli eventi. Tuttavia, addEventListenerdovrebbe essere la scelta preferita in quanto può fare tutto ciò che onclick fa e altro ancora. Non utilizzare in linea onclickcome attributi HTML in quanto questo mescola javascript e HTML, il che è una cattiva pratica. Rende il codice meno gestibile.

Un dettaglio non è stato ancora notato: i moderni browser desktop considerano le diverse pressioni dei pulsanti come "clic" per AddEventListener('click'e onclickper impostazione predefinita.

• Su Chrome 42 e IE11, entrambi onclicke AddEventListenerfai clic sul pulsante destro e sinistro del mouse.
• Su Firefox 38, onclicksi attiva solo con il clic sinistro, ma il AddEventListenerclic viene attivato con il clic sinistro, centrale e destro.

Inoltre, il comportamento del clic centrale è molto incoerente tra i browser quando sono coinvolti i cursori di scorrimento:

• Su Firefox, gli eventi del clic centrale si attivano sempre.
• Su Chrome, non si attivano se il clic centrale apre o chiude un cursore di scorrimento.
• Su IE, si attivano quando il cursore di scorrimento si chiude, ma non quando si apre.

Vale anche la pena notare che gli eventi "clic" per qualsiasi elemento HTML selezionabile da tastiera, come inputanche l'attivazione dello spazio o l'invio quando l'elemento è selezionato.

Javascript tende a fondere tutto in oggetti e questo può renderlo confuso. Tutto in uno è il modo JavaScript.

Essenzialmente onclick è un attributo HTML. Al contrario, addEventListener è un metodo sull'oggetto DOM che rappresenta un elemento HTML.

Negli oggetti JavaScript, un metodo è semplicemente una proprietà che ha una funzione come valore e funziona con l'oggetto a cui è collegato (usando questo ad esempio).

In JavaScript come elemento HTML rappresentato da DOM avrà i suoi attributi mappati sulle sue proprietà.

È qui che le persone si confondono perché JavaScript fonde tutto in un singolo contenitore o spazio dei nomi senza livello di riferimento indiretto.

In un normale layout OO (che almeno unisce lo spazio dei nomi di proprietà / metodi) potresti avere qualcosa del tipo:

domElement.addEventListener // Object(Method)
domElement.attributes.onload // Object(Property(Object(Property(String))))

Ci sono varianti come potrebbe usare un getter / setter per onload o HashMap per gli attributi, ma alla fine è così che apparirebbe. JavaScript ha eliminato questo livello di riferimento indiretto nell'aspettativa di sapere che cosa è tra l'altro. Ha unito domElement e attributi insieme.

Escludendo la compatibilità, è consigliabile utilizzare addEventListener come best practice. Mentre altre risposte parlano delle differenze al riguardo, piuttosto che delle differenze programmatiche fondamentali, la rinuncerò. Fondamentalmente, in un mondo ideale sei davvero destinato a usare solo * da HTML ma in un mondo ancora più ideale non dovresti fare nulla del genere da HTML.

Perché è dominante oggi? È più veloce da scrivere, più facile da imparare e tende a funzionare.

L'intero punto di onload in HTML è in primo luogo dare accesso al metodo o alla funzionalità addEventListener. Usandolo in JS stai attraversando HTML quando potresti applicarlo direttamente.

Ipoteticamente puoi creare i tuoi attributi:

$('[myclick]').each(function(i, v) {
     v.addEventListener('click', function() {
         eval(v.myclick); // eval($(v).attr('myclick'));
     });
});

Quello che fa JS è un po 'diverso da quello.

Puoi equipararlo a qualcosa del genere (per ogni elemento creato):

element.addEventListener('click', function() {
    switch(typeof element.onclick) {
          case 'string':eval(element.onclick);break;
          case 'function':element.onclick();break;
     }
});

I dettagli di implementazione effettivi probabilmente differiranno con una serie di sottili variazioni che rendono i due leggermente diversi in alcuni casi, ma questo è l'essenza di esso.

È probabilmente un hack di compatibilità che è possibile aggiungere una funzione a un attributo on poiché, per impostazione predefinita, gli attributi sono tutti stringhe.

Secondo MDN , la differenza è la seguente:

addEventListener:

Il metodo EventTarget.addEventListener () aggiunge l'oggetto compatibile EventListener specificato all'elenco dei listener di eventi per il tipo di evento specificato su EventTarget su cui viene chiamato. La destinazione dell'evento può essere un elemento in un documento, il documento stesso, una finestra o qualsiasi altro oggetto che supporti eventi (come XMLHttpRequest).

al clic:

La proprietà onclick restituisce il codice del gestore eventi click sull'elemento corrente. Quando si utilizza l'evento click per attivare un'azione, considerare anche l'aggiunta di questa stessa azione all'evento keydown, per consentire l'uso di quella stessa azione da parte di persone che non usano un mouse o un touchscreen. Sintassi element.onclick = functionRef; dove functionRef è una funzione, spesso il nome di una funzione dichiarata altrove o un'espressione di funzione. Vedere "Guida JavaScript: funzioni" per i dettagli.

C'è anche una differenza di sintassi in uso, come si vede nei seguenti codici:

addEventListener:

// Function to change the content of t2
function modifyText() {
  var t2 = document.getElementById("t2");
  if (t2.firstChild.nodeValue == "three") {
    t2.firstChild.nodeValue = "two";
  } else {
    t2.firstChild.nodeValue = "three";
  }
}

// add event listener to table
var el = document.getElementById("outside");
el.addEventListener("click", modifyText, false);

al clic:

function initElement() {
    var p = document.getElementById("foo");
    // NOTE: showAlert(); or showAlert(param); will NOT work here.
    // Must be a reference to a function name, not a function call.
    p.onclick = showAlert;
};

function showAlert(event) {
    alert("onclick Event detected!");
}

Se non sei troppo preoccupato per il supporto del browser, c'è un modo per ricollegare il riferimento 'this' nella funzione chiamata dall'evento. Normalmente punterà all'elemento che ha generato l'evento quando viene eseguita la funzione, che non è sempre ciò che si desidera. La parte difficile è allo stesso tempo essere in grado di rimuovere lo stesso listener di eventi, come mostrato in questo esempio: http://jsfiddle.net/roenbaeck/vBYu3/

/*
    Testing that the function returned from bind is rereferenceable, 
    such that it can be added and removed as an event listener.
*/
function MyImportantCalloutToYou(message, otherMessage) {
    // the following is necessary as calling bind again does 
    // not return the same function, so instead we replace the 
    // original function with the one bound to this instance
    this.swap = this.swap.bind(this); 
    this.element = document.createElement('div');
    this.element.addEventListener('click', this.swap, false);
    document.body.appendChild(this.element);
}
MyImportantCalloutToYou.prototype = {
    element: null,
    swap: function() {
        // now this function can be properly removed 
        this.element.removeEventListener('click', this.swap, false);           
    }
}

Il codice sopra funziona bene in Chrome, e probabilmente c'è qualche spunto per rendere "bind" compatibile con altri browser.

L'uso dei gestori in linea non è compatibile con la politica di sicurezza dei contenuti, pertanto l' addEventListenerapproccio è più sicuro da quel punto di vista. Ovviamente puoi abilitare i gestori inline con unsafe-inline, ma, come suggerisce il nome, non è sicuro in quanto riporta indietro tutte le orde di exploit JavaScript che CSP impedisce.

Dovrebbe anche essere possibile estendere l'ascoltatore prototipandolo (se abbiamo un riferimento ad esso e la sua non è una funzione anonima) -o effettuare la chiamata 'onclick' una chiamata a una libreria di funzioni (una funzione che chiama altre funzioni)

piace

    elm.onclick = myFunctionList
    function myFunctionList(){
      myFunc1();
      myFunc2();
    }

questo significa che non dobbiamo mai smettere di chiamare onclick, basta modificare la funzione myFunctionList () per fare ciò che vogliamo, ma questo ci lascia senza controllo sulle fasi di bolle / cattura, quindi dovrebbe essere evitato per i browser più recenti.

nel caso in cui qualcuno trovi questa discussione in futuro ...

element.onclick = function () {/ * do stuff * /}

element.addEventListener ('click', function () {/ * do stuff * /}, false);

Apparentemente fanno la stessa cosa: ascoltano l'evento click ed eseguono una funzione di callback. Tuttavia, non sono equivalenti. Se mai dovessi scegliere tra i due, questo potrebbe aiutarti a capire quale è il migliore per te.

La differenza principale è che onclick è solo una proprietà e, come tutte le proprietà degli oggetti, se scrivi più di una volta, verrà sovrascritta . Con addEventListener () invece, possiamo semplicemente associare un gestore di eventi all'elemento e possiamo chiamarlo ogni volta che ne abbiamo bisogno senza preoccuparci delle proprietà sovrascritte. L'esempio è mostrato qui,

Provalo: https://jsfiddle.net/fjets5z4/5/

In primo luogo sono stato tentato di continuare a usare onclick, perché è più corto e sembra più semplice ... e in effetti lo è. Ma non consiglio più di usarlo. È come usare JavaScript incorporato. L'uso di qualcosa di simile - ovvero JavaScript inline - è altamente scoraggiato al giorno d'oggi (anche CSS inline è scoraggiato, ma questo è un altro argomento).

Tuttavia, la funzione addEventListener (), nonostante sia lo standard, non funziona nei vecchi browser (Internet Explorer sotto la versione 9), e questa è un'altra grande differenza. Se hai bisogno di supportare questi antichi browser, dovresti seguire il metodo onclick. Ma potresti anche usare jQuery (o una delle sue alternative): sostanzialmente semplifica il tuo lavoro e riduce le differenze tra i browser, quindi può farti risparmiare un sacco di tempo.

var clickEvent = document.getElementByID("onclick-eg");
var EventListener = document.getElementByID("addEventListener-eg");

clickEvent.onclick = function(){
    window.alert("1 is not called")
}
clickEvent.onclick = function(){
    window.alert("2 is not called")
}

EventListener.addEventListener("click",function(){
    window.alert("1 is called")
})
EventListener.addEventListener("click",function(){
    window.alert("2 is also called")
})

addEventListener consente di impostare più gestori, ma non è supportato in IE8 o versioni precedenti.

IE ha attachEvent, ma non è esattamente lo stesso.

Il contesto a cui fa riferimento la 'this'parola chiave in JavasSript è diverso.

guarda il seguente codice:

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title></title>

</head>
<body>
    <input id="btnSubmit" type="button" value="Submit" />
    <script>
        function disable() {
            this.disabled = true;
        }
        var btnSubmit = document.getElementById('btnSubmit');
        btnSubmit.onclick = disable();
        //btnSubmit.addEventListener('click', disable, false);
    </script>
</body>
</html>

Quello che fa è davvero semplice. quando si fa clic sul pulsante, il pulsante verrà disabilitato automaticamente.

Innanzitutto, quando si tenta di collegare gli eventi in questo modo, l' button.onclick = function(), evento onclick verrà attivato facendo clic sul pulsante, tuttavia, il pulsante non verrà disabilitato perché non esiste un legame esplicito tra button.onclick e il gestore eventi onclick. Se esegui il debug per vedere l' 'this'oggetto, puoi vedere che si riferisce 'window'all'oggetto.

In secondo luogo, se commentate btnSubmit.onclick = disable(); e commenti //btnSubmit.addEventListener('click', disable, false);, puoi vedere che il pulsante è disabilitato perché in questo modo esiste un legame esplicito tra l'evento button.onclick e il gestore eventi onclick. Se esegui il debug nella funzione di disabilitazione, puoi vedere i 'this'riferimenti button controlanziché a window.

Questo è qualcosa che non mi piace di JavaScript, che è incoerenza. A proposito, se si utilizza jQuery ( $('#btnSubmit').on('click', disable);), utilizza l'associazione esplicita.

onclick è fondamentalmente un addEventListener che esegue specificamente una funzione quando si fa clic sull'elemento. Quindi, utile quando si dispone di un pulsante che esegue operazioni semplici, come un pulsante della calcolatrice. addEventlistener può essere utilizzato per una moltitudine di cose come eseguire un'operazione quando viene caricato DOM o tutto il contenuto, simile a window.onload ma con un maggiore controllo.

Nota, puoi effettivamente usare più di un evento con inline, o almeno usando onclick separando ogni funzione con un punto e virgola, come questo ....

Non scriverei una funzione con inline, poiché potresti potenzialmente avere problemi in seguito e sarebbe imo disordinato. Usalo per chiamare le funzioni già fatte nel tuo file di script.

Quale che usi suppongo dipenderebbe da quello che vuoi. addEventListener per operazioni complesse e onclick per semplicità. Ho visto alcuni progetti non associarne uno specifico agli elementi e implementerei invece un listener di eventi più globale che determinerebbe se un tocco era su un pulsante ed eseguiva determinate attività a seconda di ciò che veniva premuto. Imo che potrebbe potenzialmente portare a problemi penserei, e anche se piccolo, probabilmente, uno spreco di risorse se quell'ascoltatore di eventi dovesse gestire ogni singolo clic