Polling vs eventi pro e contro in JavaScript

Question

Polling vs eventi pro e contro in JavaScript

#1 da (7 voti)
#2 da (1 voti)

1

Sono un po 'inesperto in JavaScript, quindi mi sono chiesto i lati positivi e negativi dell'utilizzo del polling rispetto all'utilizzo di eventi in JavaScript? Quando si usa l'uno o l'altro?

Mediante il polling considero qualsiasi effetto che viene attivato su qualcosa che si ripete usualmente usando setTimeout . Ma anche per esempio:

function render() {
   Bloop.renderComponent(box, document.body);
   requestAnimationFrame(render);
}

Esegue anche il polling poiché requestAnimationFrame(render) che viene chiamato prima che ogni frame venga chiamato.

Sostanzialmente tutto ciò che si adatta questa definizione

javascript performance polling

posta Daniel Fath 15.05.2014 - 15:05

fonte

2 risposte

1

In generale, la mia preferenza è di basare il progetto sul polling a frequenze abbastanza basse, ma poi di usare gli eventi per attivare le prime analisi.

Il bello degli eventi è la reattività.

Ci sono alcune cose negative su di loro:

Possono accadere più spesso di quanto tu voglia, dato che ad esempio possono esserci 10 eventi di seguito, i primi vengono sovrascritti da quelli successivi, e il programma viene tirato di scatto cercando di tracciare ogni piccolo cambiamento. Questo è il problema del "breve guinzaglio". Se ci sono due corpi di informazioni che devono essere mantenuti d'accordo, di solito uso una routine per scansionare i disaccordi e correggerli, piuttosto che contare su eventi o notifiche.
Gli eventi possono essere eliminati o duplicati, quindi se è importante tenere traccia delle modifiche, possono portare a errori. Questo è il "perché non è stato detto?" o "me l'hai già detto?" problema.
È facile creare gestori di eventi, in modo che sia facile creare più di quanto si desideri. Questo può portare a cose come la pittura a finestra lenta, perché è stato fatto molte volte quando doveva essere fatto solo una volta. Quindi, quando rimuovi un gestore di eventi, potresti pensare di aver disattivato la gestione degli eventi, ma non l'hai fatto, perché non li hai rimossi tutti. Questo è il problema "spam".

Quindi, come ho detto, preferisco ridurre al minimo la gestione degli eventi (ei suoi cugini - notifiche e proprietà annidate), ma impiegarli decisamente, con parsimonia, dove i loro benefici faranno il massimo.

risposta data 15.05.2014 - 20:00

fonte

Leggi altre domande sui tag javascript performance polling

E 'anti-pattern mescolare test di unità e test web? [duplicare] Design verificabile per una classe che può essere istanziata solo attraverso un metodo statico

score 7 · Accepted Answer

Questo è un po 'un tipo di domanda "che è meglio, pesce o colore arancione", ma in termini di comportamento generale di JavaScript, e in particolare il lato più funzionale della sua natura, è probabilmente più idiomatico da usare eventi per reagire ai cambiamenti di stato piuttosto che avere un sistema di polling temporizzato.

È molto più flessibile e meno confuso aggiungere e rimuovere i listener di eventi man mano che l'applicazione inizia a crescere. Il sondaggio è più facile da concettualizzare quando si immagina dapprima tutto in un punto centrale, ma la domanda diventa sempre più complessa e potrebbe diventare sempre più difficile, mentre gli eventi possono arrivare da qualsiasi luogo e andare ovunque, quindi sono molto meno strettamente accoppiati.

Anche quando un evento viene attivato e non c'è nessuno a sentirlo, non succede nulla. Se hai un sacco di loop di polling basati sul timeout, potresti scoprire che le cose accadono dopo che il sistema principale si è arrestato in modo anomalo come trigger di timeout, il che rende il debug del problema o il controllo di eventuali log più confusi.

In pratica, se stai animando le cose, probabilmente vorrai usare un certo grado di polling per il tuo ciclo di animazione e gli eventi per comunicare quando attivare altre animazioni o quando si verificano interazioni, quindi probabilmente vorrai usarle entrambe.