Zakaj ena donacija sproži dve opozorili po posodobitvi brskalniškega vira

Zakaj ena donacija sproži dve opozorili

Po posodobitvi brskalniškega vira se stran zažene znova. Skript se ponovno poveže s strežnikom, naroči na dogodke in ustvari obdelovalce za prikaz obvestil. Če stari obdelovalec ni odstranjen ali hkrati delujeta dve povezavi, se en dogodek donacije obdela večkrat.

Sama posodobitev ni nujno vzrok za napako. Pogosto le razkrije napako v logiki povezovanja. Na primer, funkcija za inicializacijo se lahko zažene ob nalaganju strani, nato ob obnovitvi povezave in še enkrat po prejemu servisnega sporočila. Vsak zagon doda novo naročnino na dogodek donation.

Posledično strežnik pošlje en objekt donacije, brskalnik pa pokliče isto funkcijo dvakrat. Včasih do podvajanja pride na strani strežnika: aplikacija obravnava novo povezavo kot ločenega prejemnika in pošlje dogodek tako stari kot novi seji. Zato je treba najprej ugotoviti, kje se pojavi ponovitev: v viru, v obdelovalcu ali v fazi prikaza.

Kako najti mesto, kjer nastane dvojnik

Začnite s preprostim testom. Odprite povezavo brskalniškega vira v ločenem oknu ali zavihku, pustite samo en primerek strani in pošljite testni dogodek. Če se opozorilo pojavi enkrat, je vzrok najverjetneje povezan z nastavitvami prizora ali z več primerki vira. Če se podvoji že v ločenem zavihku, preverite kodo strani in mehanizem naročnine.

Koristno je obdelavo donacije razdeliti na več faz: prejem dogodka, preverjanje dogodka, postavitev opozorila v čakalno vrsto in izris. V dnevniku ali konzoli začasno izpišite oznako v vsaki fazi. Če se zapis o prejemu pojavi dvakrat, je težava pred vidnim slojem. Če je dogodek prejet enkrat, v čakalni vrsti pa sta dva elementa, je napaka v obdelovalcu. Če čakalna vrsta vsebuje en element, na zaslonu pa sta dve opozorili, preverite funkcijo prikaza in HTML-vsebnik.

Za diagnostiko vsakemu dogodku dodajte njegov identifikator, če se prenaša v podatkih donacije. Zapišite ta identifikator ob prejemu in pred prikazom. Enak identifikator v dveh klicih pokaže, da je bil en dogodek obdelan znova. Dva različna identifikatorja kažeta na dve dostavi, ki ju je treba obravnavati ločeno.

Ne preverjajte le števila zavihkov. V OBS se lahko dva primerka pojavita po kopiranju prizora, dodajanju ugnezdenega prizora ali ponovnem dodajanju brskalniškega vira z istim naslovom. Včasih en vir ostane v ločenem sloju, drugi pa se doda nad njim. Vizualno je to videti kot dvojno opozorilo, čeprav je dogodek prišel enkrat.

Ponovna naročnina po ponovni povezavi

Najpogostejši vzrok je, da se obdelovalec doda ob vsaki povezavi, ne odstrani pa se ob prekinitvi. Poenostavljeno je težava videti takole: funkcija zažene socket.on z obdelovalcem za prikaz opozorila, nato se povezava prekine, aplikacija se znova poveže in ponovi socket.on. Po tem ena dohodna donacija sproži dve funkciji. Ob naslednji ponovni povezavi jih je lahko še več.

Ista napaka se pojavi pri običajnem addEventListener. Če se funkcija za inicializacijo pokliče večkrat, brskalnik doda več poslušalcev istega dogodka. Preverjanje zastavice »inicializacija je že izvedena« ne pomaga vedno: ob popolni posodobitvi strani se spremenljivke ponastavijo, ob ponovni povezavi znotraj iste strani pa težava ostane.

Naročnino je treba ustvariti enkrat za življenjski cikel povezave, staro naročnino pa pred novo izrecno odstraniti. Za obdelovalce dogodkov se uporablja removeEventListener in ista referenca na funkcijo, ki je bila posredovana ob povezavi. Za knjižnice z vtičnicami je običajno potrebna metoda off, unsubscribe ali podoben način odjave.

Minimalna shema za vtičnico je lahko videti takole: 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);

Tu ni pomembna določena knjižnica, temveč vrstni red dejanj. Obdelovalec je shranjen v spremenljivki, zato ga je mogoče odstraniti z isto referenco. Pred novo naročnino se stara odstrani, ob zaprtju strani ali ustavitvi vira pa se izvede cleanup. Če se ob vsakem zagonu ustvari nova vtičnica, je treba najprej zapreti staro in šele nato ustvariti novo. Sicer lahko obe povezavi še naprej prejemata iste podatke.

Ob ponovni povezavi zaprite tudi staro povezavo in počistite povezane časovnike. Sicer lahko stara vtičnica še naprej prejema podatke, medtem ko nova že deluje. To se še posebej pogosto zgodi, če koda zažene nov časovnik za ponovno povezavo, ne da bi preklicala prejšnjega.

Kaj preveriti v OBS in brskalniškem viru

Če ločeno okno prikaže opozorilo enkrat, pojdite na prizor. Ustavite predogled, začasno odstranite odvečne sloje in pustite en brskalniški vir. Nato preverite vedenje na želenem prizoru. Tak test je hitrejši od hkratnega preverjanja vseh prizorov in filtrov.

• Iščite dva vira z istim naslovom strani.
• Preverite kopije prizorov in ugnezdene prizore, kjer je lahko isti overlay.
• Prepričajte se, da se opozorilo ne prikazuje hkrati prek brskalniškega vira in drugega sloja z isto stranjo.
• Po spremembi nastavitev popolnoma znova zaženite vir, ne le preklopite prizora.

Včasih v OBS po posodobitvi URL-ja ali parametrov ostane stari zavihek brskalniškega vira. Zaprtje in ponovno dodajanje vira pomaga preveriti hipotezo, vendar ne nadomesti popravka kode. Če se težava po vsaki posodobitvi vrne, iščite ponovno registracijo obdelovalca ali dvojno povezavo.

Upoštevajte tudi zakasnitev odjave. Ob posodobitvi se stara seja morda ne zapre takoj. Če strežnik nekaj sekund meni, da je še aktivna, lahko dogodek, ki pride v tem intervalu, pade v dve seji. Normalna strežniška logika bi morala odstraniti neaktivne povezave in ne pustiti naročnine po zaprtju strani.

Zaščita pred ponovno dostavo enega dogodka

Tudi ob pravilnem delovanju brskalniškega vira se lahko en dogodek včasih dostavi znova. To je mogoče ob obnovitvi povezave, ponovnem pošiljanju sporočila ali napaki med prejemom dogodka in potrditvijo njegove obdelave. Zato mora biti obdelovalec opozorila odporen na ponovitve.

Najboljši način je preverjanje edinstvenega identifikatorja donacije. Pred postavitvijo dogodka v čakalno vrsto shranite njegov identifikator v nabor že obdelanih dogodkov. Če se je ta identifikator že pojavil, je treba ponovitev preskočiti. Seznam je treba hraniti omejen čas, da ne raste v nedogled.

Za to ne uporabljajte samo zneska, imena pošiljatelja ali besedila sporočila. Dve različni donaciji imata lahko enake podatke. Tudi preverjanje po času je nezanesljivo: več različnih donacij lahko pride skoraj hkrati. Če identifikatorja ni, lahko začasno primerjate kombinacijo polj in časa, vendar je to rezervna možnost s tveganjem, da se dva dogodka napačno združita.

Zaščita pred dvojniki mora biti pred prikazom opozorila, ne znotraj animacije. Sicer bo drugi klic vseeno dodal element na stran, predvajal zvok ali dodal še en zapis v čakalno vrsto. Čakalno vrsto nadzorujte ločeno: en dogodek se mora vanjo dodati enkrat, ponovni klic pa ne sme zagnati druge neodvisne čakalne vrste.

Če se dogodek prenaša med več zavihki ali komponentami, preverite, ali ga ne obdeluje več prejemnikov hkrati. En skupni kanal sporočil je lahko povezan z več obdelovalci. V tem primeru je treba pustiti enega potrošnika ali izrecno določiti, katera komponenta je odgovorna za prikaz opozorila.

Zakaj čiščenje predpomnilnika ne pomaga vedno

Po posodobitvi brskalniškega vira se pogosto svetuje čiščenje predpomnilnika. To lahko odpravi težavo, če se je naložila stara različica skripta, vendar predpomnilnik ne odstrani odvečnih obdelovalcev v že delujoči strani in ne zapre druge kopije vira. Če se dvojnik stalno ponavlja po vsaki ponovni povezavi, je vzrok skoraj zagotovo v logiki povezave ali v strukturi prizora.

Preverite, ali se res nalaga nova različica datotek. Začasno spremenite naslov vira ali uporabite predvideni mehanizem za posodobitev, nato znova zaženite brskalniški vir. Po tem znova izvedite test z enim oknom in enim primerkom vira. Naključnih parametrov ne dodajajte povezavi stalno: to lahko ustvari številne različice predpomnilnika in oteži diagnostiko.

Če se uporablja vmesni predpomnilnik ali service worker, lahko tudi ta ponuja zastarel skript. V tem primeru primerjajte različico naložene datoteke z različico, ki jo pričakujete. Toda tudi pri stari datoteki je treba odpraviti vzrok ponovne naročnine, sicer se bo težava znova pojavila po naslednji posodobitvi.

Kaj preveriti v kodi opozorila

Najprej poiščite vsa mesta, kjer se kličejo socket.on, addEventListener, funkcije povezovanja in zagon čakalne vrste. Včasih težava ni v enem obdelovalcu, temveč v tem, da dva različna modula neodvisno poslušata dogodek donation in vsak zažene svoj prikaz.

Nato preverite življenjski cikel komponente, če se opozorilo prikazuje prek ogrodja. Naročnina se postavi v efekt ali podoben blok, vrne pa se funkcija za čiščenje. Novega obdelovalca ni dovoljeno ustvarjati ob vsaki posodobitvi stanja brez odstranitve prejšnjega. V običajnem JavaScriptu je pomembno shraniti referenco na aktivno vtičnico in trenutni obdelovalec, da ju je ob ustavitvi strani mogoče pravilno zapreti.

Preverite časovnike za ponovno povezavo. Nov časovnik se ne sme zagnati prek starega. Sicer se po več prekinitvah ustvarijo vzporedni poskusi povezave, skupaj z njimi pa dodatne naročnine. Za vsak časovnik je potrebno čiščenje prek clearTimeout ali clearInterval, če ni več potreben.

Ločeno poglejte kodo, ki prikazuje opozorilo. Ta ne sme hkrati dodati elementa v čakalno vrsto in takoj poklicati funkcije prikaza za isti objekt. Preverite tudi, ali se animacija znova zažene ob spremembi stanja elementa. Če je v dnevniku en prejem in en zapis v čakalni vrsti, na zaslonu pa dve obvestili, je treba iskati prav tu.

Kontrolni seznam za diagnostiko: kaj storiti po vrsti

1. Odprite URL brskalniškega vira v ločenem zavihku in pošljite eno testno donacijo. Zabeležite, ali se dvojnik pojavi zunaj OBS.
2. V prizoru pustite samo en primerek vira. Preverite kopije prizorov, ugnezdene prizore in sloje, kjer je lahko isti naslov.
3. Dodajte dnevnik z identifikatorjem dogodka v fazah prejema, postavitve v čakalno vrsto in prikaza. Tako bo vidno, kje se število objektov poveča.
4. Poiščite vse klice socket.on in addEventListener. Preverite, ali se stari obdelovalci odstranijo prek socket.off in removeEventListener z isto referenco na funkcijo.
5. Preverite ponovno povezavo: ali se stara vtičnica zapre, ali se stari časovnik prekliče in ali se nova naročnina ne ustvari prek prejšnje.
6. Pred čakalno vrsto dodajte preverjanje edinstvenega identifikatorja donacije, nato popolnoma znova zaženite vir in ponovite test z enim dogodkom.

Če ločen zavihek prejme dogodek enkrat, OBS pa prikaže dve opozorili, iščite drugi primerek vira ali podvajanje v prizorih. Če dogodek pride dvakrat že v ločenem zavihku, preverite naročnine, povezave in strežniško dostavo. Če sta prejem in čakalna vrsta zabeležena enkrat, na zaslonu pa sta dve obvestili, je težava v vidnem sloju.