De ce o singură donație declanșează două alerte după actualizarea sursei de browser

De ce o singură donație declanșează două alerte

După actualizarea sursei de browser, pagina pornește din nou. Scriptul se reconectează la server, se abonează la evenimente și creează handler-e pentru afișarea notificărilor. Dacă vechiul handler nu este eliminat sau dacă funcționează simultan două conexiuni, un singur eveniment de donație este procesat de mai multe ori.

Actualizarea în sine nu este neapărat cauza defecțiunii. Ea doar evidențiază adesea o eroare în logica de conectare. De exemplu, funcția de inițializare poate rula la încărcarea paginii, apoi la restabilirea conexiunii și încă o dată după primirea unui mesaj de serviciu. Fiecare rulare adaugă un nou abonament la evenimentul donation.

Ca urmare, serverul trimite un singur obiect de donație, dar browserul apelează aceeași funcție de două ori. Uneori duplicarea apare pe partea serverului: aplicația consideră noua conexiune un destinatar separat și trimite evenimentul atât sesiunii vechi, cât și celei noi. De aceea, mai întâi trebuie să stabilim unde apare duplicarea: în sursă, în handler sau în etapa de afișare.

Cum găsești locul unde apare duplicarea

Începe cu un test simplu. Deschide linkul sursei de browser într-o fereastră sau un tab separat, lasă doar o singură instanță a paginii și trimite un eveniment de test. Dacă alerta apare o singură dată, cauza este probabil legată de setările scenei sau de mai multe instanțe ale sursei. Dacă se duplică deja în tabul separat, verifică codul paginii și mecanismul de abonare.

Este util să împarți procesarea donației în mai multe etape: primirea evenimentului, verificarea evenimentului, punerea alertei în coadă și randarea. În jurnal sau în consolă, afișează temporar un marcaj la fiecare etapă. Dacă înregistrarea despre primire apare de două ori, problema se află înainte de stratul vizual. Dacă evenimentul este primit o singură dată, dar în coadă sunt două elemente, eroarea este în handler. Dacă coada conține un singur element, dar pe ecran apar două alerte, verifică funcția de afișare și containerul HTML.

Pentru diagnosticare, adaugă fiecărui eveniment identificatorul său, dacă acesta este transmis în datele donației. Înregistrează acest identificator la primire și înainte de afișare. Același identificator în două apeluri arată că un singur eveniment a fost procesat din nou. Doi identificatori diferiți indică două livrări, care trebuie analizate separat.

Verifică nu doar numărul de taburi. În OBS, două instanțe pot apărea după copierea scenei, adăugarea unei scene imbricate sau adăugarea din nou a sursei de browser cu aceeași adresă. Uneori o sursă rămâne într-un strat separat, iar a doua este adăugată peste ea. Vizual, aceasta arată ca o alertă dublă, deși evenimentul a sosit o singură dată.

Abonare repetată după reconectare

Cea mai frecventă cauză este că handler-ul este adăugat la fiecare conectare, dar nu este eliminat la deconectare. Simplificat, problema arată astfel: funcția apelează socket.on cu handler-ul de afișare a alertei, apoi conexiunea se întrerupe, aplicația se reconectează și repetă socket.on. După aceea, o singură donație primită apelează două funcții. La următoarea reconectare, pot deveni și mai multe.

Aceeași eroare apare și cu addEventListener obișnuit. Dacă funcția de inițializare este apelată de mai multe ori, browserul adaugă mai mulți listeneri pentru același eveniment. Verificarea indicatorului „inițializarea a fost deja executată” nu ajută întotdeauna: la o actualizare completă a paginii variabilele se resetează, iar la reconectarea în cadrul aceleiași pagini problema persistă.

Abonamentul trebuie creat o singură dată pe ciclul de viață al conexiunii, iar abonamentul vechi trebuie eliminat explicit înainte de cel nou. Pentru handler-ele de evenimente se folosește removeEventListener și aceeași referință la funcție care a fost transmisă la conectare. Pentru bibliotecile cu socketuri este de obicei nevoie de metoda off, unsubscribe sau un mod similar de deconectare.

O schemă minimă pentru socket poate arăta astfel: const onDonation = data => showAlert(data); socket.off('donation', onDonation); socket.on('donation', onDonation); function cleanup() { socket.off('donation', onDonation); window.removeEventListener('beforeunload', cleanup); socket.close(); } window.addEventListener('beforeunload', cleanup);

Aici nu contează biblioteca concretă, ci ordinea acțiunilor. Handler-ul este păstrat într-o variabilă, astfel încât poate fi eliminat cu aceeași referință. Înainte de un nou abonament, cel vechi este eliminat, iar la închiderea paginii sau oprirea sursei se execută cleanup. Dacă la fiecare pornire se creează un socket nou, mai întâi trebuie închis cel vechi și abia apoi creat cel nou. Altfel, ambele conexiuni pot continua să primească aceleași date.

La reconectare, închide de asemenea conexiunea veche și curăță timer-ele asociate. Altfel, socketul vechi poate continua să primească date în timp ce cel nou funcționează deja. Acest lucru se întâmplă mai ales când codul pornește un nou timer de reconectare fără a-l anula pe cel anterior.

Ce să verifici în OBS și în sursa de browser

Dacă fereastra separată afișează alerta o singură dată, treci la scenă. Oprește previzualizarea, elimină temporar straturile în plus și lasă o singură sursă de browser. Apoi verifică comportamentul în scena dorită. Acest test este mai rapid decât verificarea simultană a tuturor scenelor și filtrelor.

• Caută două surse cu aceeași adresă de pagină.
• Verifică copiile scenelor și scenele imbricate în care poate exista același overlay.
• Asigură-te că alerta nu este afișată simultan de sursa de browser și de un alt strat cu aceeași pagină.
• După modificarea setărilor, repornește complet sursa, nu doar comută scena.

Uneori, în OBS rămâne un tab vechi al sursei de browser după actualizarea URL-ului sau a parametrilor. Închiderea și adăugarea din nou a sursei ajută la verificarea ipotezei, dar nu înlocuiește corectarea codului. Dacă problema revine după fiecare actualizare, caută înregistrarea repetată a handler-ului sau conexiunea dublă.

Ține cont și de întârzierea deconectării. La actualizare, sesiunea veche poate să nu se închidă instantaneu. Dacă serverul o consideră activă câteva secunde, un eveniment care sosește în acest interval poate ajunge în două sesiuni. Logica normală a serverului ar trebui să elimine conexiunile inactive și să nu păstreze abonamentul după închiderea paginii.

Protecție împotriva livrării repetate a unui singur eveniment

Chiar și cu o funcționare corectă a sursei de browser, un eveniment poate fi uneori livrat din nou. Acest lucru este posibil la restabilirea conexiunii, la retransmiterea unui mesaj sau la o defecțiune între primirea evenimentului și confirmarea procesării lui. De aceea, handler-ul alertei trebuie să fie rezistent la repetări.

Cea mai bună metodă este verificarea unui identificator unic al donației. Înainte de a pune evenimentul în coadă, salvează identificatorul său într-un set de evenimente deja procesate. Dacă acest identificator a mai apărut, repetarea trebuie ignorată. Lista trebuie păstrată un timp limitat, pentru a nu crește la nesfârșit.

Nu folosi în acest scop doar suma, numele expeditorului sau textul mesajului. Două donații diferite pot avea aceleași date. Nici verificarea după timp nu este sigură: mai multe donații diferite pot sosi aproape simultan. Dacă nu există un identificator, poți compara temporar o combinație de câmpuri și timpul, dar aceasta este o soluție de rezervă cu riscul de a uni greșit două evenimente.

Protecția împotriva duplicatelor trebuie să se afle înainte de afișarea alertei, nu în interiorul animației. Altfel, al doilea apel va adăuga oricum un element pe pagină, va reda sunetul sau va mai pune o înregistrare în coadă. Controlează separat coada: un eveniment trebuie adăugat în ea o singură dată, iar un apel repetat nu trebuie să pornească o a doua coadă independentă.

Dacă evenimentul este transmis între mai multe taburi sau componente, verifică dacă nu cumva este procesat simultan de mai mulți destinatari. Un singur canal comun de mesaje poate fi conectat la mai mulți handler-i. În acest caz, trebuie fie să lași un singur consumator, fie să stabilești explicit care componentă este responsabilă de afișarea alertei.

De ce curățarea cache-ului nu ajută întotdeauna

După actualizarea sursei de browser se recomandă adesea curățarea cache-ului. Aceasta poate remedia situația dacă a fost încărcată o versiune veche a scriptului, dar cache-ul nu elimină handler-ele în plus dintr-o pagină deja funcțională și nu închide a doua copie a sursei. Dacă duplicarea se repetă constant după fiecare reconectare, cauza se află aproape sigur în logica conexiunii sau în structura scenei.

Verifică dacă se încarcă într-adevăr versiunea nouă a fișierelor. Modifică temporar adresa resursei sau folosește mecanismul de actualizare prevăzut, apoi repornește sursa de browser. După aceea, rulează din nou testul cu o singură fereastră și o singură instanță a sursei. Nu adăuga permanent parametri aleatori la link: acest lucru poate crea numeroase variante de cache și poate îngreuna diagnosticarea.

Dacă se folosește un cache intermediar sau un service worker, și acesta poate furniza un script învechit. În acest caz, compară versiunea fișierului încărcat cu versiunea pe care te aștepți să o vezi. Dar chiar și cu un fișier vechi, trebuie eliminată cauza abonării repetate, altfel problema va reapărea după următoarea actualizare.

Ce să verifici în codul alertei

Mai întâi găsește toate locurile unde sunt apelate socket.on, addEventListener, funcțiile de conectare și pornirea cozii. Uneori problema nu este într-un singur handler, ci în faptul că două module diferite ascultă independent evenimentul donation și fiecare își pornește propria afișare.

Apoi verifică ciclul de viață al componentei, dacă alerta este afișată printr-un framework. Abonamentul se plasează într-un efect sau într-un bloc similar și se returnează o funcție de curățare. Nu trebuie creat un handler nou la fiecare actualizare a stării fără eliminarea celui anterior. În JavaScript obișnuit este important să păstrezi referința la socketul activ și la handler-ul curent, pentru ca la oprirea paginii să poată fi închise corect.

Verifică timer-ele de reconectare. Un timer nou nu trebuie pornit peste cel vechi. Altfel, după mai multe întreruperi se creează încercări de conectare paralele și, odată cu ele, abonamente suplimentare. Pentru fiecare timer este nevoie de curățare prin clearTimeout sau clearInterval, dacă nu mai este necesar.

Uită-te separat la codul care afișează alerta. Acesta nu trebuie să adauge simultan elementul în coadă și să apeleze imediat funcția de afișare pentru același obiect. Verifică de asemenea dacă animația nu este repornită la modificarea stării elementului. Dacă în jurnal există o singură primire și o singură înregistrare în coadă, dar pe ecran apar două notificări, exact aici trebuie căutat.

Listă de verificare pentru diagnosticare: ce să faci în ordine

1. Deschide URL-ul sursei de browser într-un tab separat și trimite o singură donație de test. Notează dacă duplicarea apare în afara OBS.
2. Lasă în scenă doar o singură instanță a sursei. Verifică copiile scenelor, scenele imbricate și straturile în care poate exista aceeași adresă.
3. Adaugă un jurnal cu identificatorul evenimentului la etapele de primire, punere în coadă și afișare. Astfel se va vedea unde crește numărul de obiecte.
4. Găsește toate apelurile socket.on și addEventListener. Verifică dacă handler-ele vechi sunt eliminate prin socket.off și removeEventListener cu aceeași referință la funcție.
5. Verifică reconectarea: dacă socketul vechi este închis, dacă timer-ul vechi este anulat și dacă nu se creează un abonament nou peste cel anterior.
6. Adaugă o verificare a identificatorului unic al donației înainte de coadă, apoi repornește complet sursa și repetă testul cu un singur eveniment.

Dacă tabul separat primește evenimentul o singură dată, iar OBS afișează două alerte, caută a doua instanță a sursei sau duplicarea în scene. Dacă evenimentul sosește de două ori deja în tabul separat, verifică abonamentele, conexiunile și livrarea pe server. Dacă primirea și coada sunt înregistrate o singură dată, dar pe ecran apar două notificări, problema se află în stratul vizual.