Miért vált ki egy adomány két riasztást a böngészőforrás frissítése után

Miért vált ki egy adomány két riasztást

A böngészőforrás frissítése után az oldal újraindul. A szkript újra csatlakozik a szerverhez, feliratkozik az eseményekre, és létrehozza az értesítések megjelenítéséhez szükséges kezelőket. Ha a régi kezelőt nem távolították el, vagy egyszerre két kapcsolat működik, egy adományesemény többször is feldolgozásra kerül.

Maga a frissítés nem feltétlenül a hiba oka. Gyakran csak felszínre hozza a kapcsolódási logika hibáját. Például az inicializáló függvény lefuthat az oldal betöltésekor, majd a kapcsolat helyreállításakor, és még egyszer egy szolgáltatási üzenet fogadása után. Minden futás új előfizetést ad a donation eseményhez.

Ennek eredményeként a szerver egyetlen adományobjektumot küld, de a böngésző ugyanazt a függvényt kétszer hívja meg. Néha a duplikálódás a szerver oldalán történik: az alkalmazás az új kapcsolatot külön címzettnek tekinti, és az eseményt a régi és az új munkamenetnek is elküldi. Ezért először meg kell határozni, hol jelenik meg az ismétlődés: a forrásban, a kezelőben vagy a megjelenítés szakaszában.

Hogyan találjuk meg a duplikálódás helyét

Kezdje egy egyszerű teszttel. Nyissa meg a böngészőforrás hivatkozását egy külön ablakban vagy lapon, hagyjon csak egy példányt az oldalból, és küldjön egy teszteseményt. Ha a riasztás egyszer jelenik meg, az ok valószínűleg a jelenet beállításaival vagy a forrás több példányával függ össze. Ha már a külön lapon is duplikálódik, ellenőrizze az oldal kódját és az előfizetési mechanizmust.

Hasznos az adomány feldolgozását több szakaszra bontani: az esemény fogadása, az esemény ellenőrzése, a riasztás sorba állítása és a kirajzolás. A naplóban vagy a konzolon ideiglenesen jelenítsen meg egy jelölést minden szakaszban. Ha a fogadásról szóló bejegyzés kétszer jelenik meg, a probléma a vizuális réteg előtt van. Ha az esemény egyszer érkezik meg, de a sorban két elem van, a hiba a kezelőben van. Ha a sor egy elemet tartalmaz, de a képernyőn két riasztás látható, ellenőrizze a megjelenítő függvényt és a HTML-konténert.

A diagnosztikához adjon hozzá minden eseményhez egy azonosítót, ha az átadásra kerül az adomány adataiban. Jegyezze fel ezt az azonosítót a fogadáskor és a megjelenítés előtt. Ugyanaz az azonosító két hívásban azt mutatja, hogy egy esemény ismételten feldolgozásra került. Két különböző azonosító két kézbesítésről árulkodik, amelyeket külön kell kivizsgálni.

Ne csak a lapok számát ellenőrizze. Az OBS-ben két példány jelenhet meg a jelenet másolása, egy beágyazott jelenet hozzáadása vagy a böngészőforrás ismételt hozzáadása után ugyanazzal a címmel. Néha az egyik forrás egy külön rétegben marad, a második pedig fölé kerül. Vizuálisan ez dupla riasztásnak tűnik, pedig az esemény egyszer érkezett meg.

Ismételt előfizetés újracsatlakozás után

A leggyakoribb ok, hogy a kezelő minden csatlakozáskor hozzáadódik, de leválasztáskor nem kerül eltávolításra. Leegyszerűsítve a probléma így néz ki: a függvény elindítja a socket.on-t a riasztásmegjelenítő kezelővel, majd a kapcsolat megszakad, az alkalmazás újra csatlakozik, és megismétli a socket.on-t. Ezt követően egy bejövő adomány két függvényt hív meg. A következő újracsatlakozáskor még több is lehet belőlük.

Ugyanez a hiba előfordul a hagyományos addEventListener esetében is. Ha az inicializáló függvény többször fut le, a böngésző több figyelőt ad ugyanahhoz az eseményhez. Az „inicializálás már megtörtént” jelző ellenőrzése nem mindig segít: az oldal teljes frissítésekor a változók visszaállnak, az ugyanazon az oldalon belüli újracsatlakozáskor pedig a probléma megmarad.

Az előfizetést egyszer kell létrehozni a kapcsolat életciklusára, a régi előfizetést pedig kifejezetten el kell távolítani az új előtt. Az eseménykezelőkhöz a removeEventListener-t kell használni, ugyanazzal a függvényhivatkozással, amelyet a csatlakozáskor átadtak. A socketeket használó könyvtárakhoz általában egy off, unsubscribe vagy hasonló leválasztási módszer szükséges.

A socket minimális sémája így nézhet ki: 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);

Itt nem a konkrét könyvtár a fontos, hanem a műveletek sorrendje. A kezelőt változóban tároljuk, így ugyanazzal a hivatkozással eltávolítható. Az új előfizetés előtt a régi törlődik, az oldal bezárásakor vagy a forrás leállításakor pedig lefut a cleanup. Ha minden indításkor új socket jön létre, először a régit kell bezárni, és csak utána létrehozni az újat. Ellenkező esetben mindkét kapcsolat továbbra is ugyanazokat az adatokat kaphatja.

Újracsatlakozáskor is zárja be a régi kapcsolatot, és törölje a kapcsolódó időzítőket. Ellenkező esetben a régi socket továbbra is fogadhat adatokat, miközben az új már működik. Ez különösen gyakran fordul elő, ha a kód új újracsatlakozási időzítőt indít anélkül, hogy az előzőt megszakítaná.

Mit kell ellenőrizni az OBS-ben és a böngészőforrásban

Ha egy külön ablak egyszer mutatja a riasztást, lépjen tovább a jelenethez. Állítsa le az előnézetet, ideiglenesen távolítsa el a felesleges rétegeket, és hagyjon meg egy böngészőforrást. Ezután ellenőrizze a viselkedést a kívánt jeleneten. Ez a teszt gyorsabb, mint az összes jelenet és szűrő egyidejű ellenőrzése.

• Keressen két forrást ugyanazzal az oldalcímmel.
• Ellenőrizze a jelenetmásolatokat és a beágyazott jeleneteket, ahol ugyanaz az overlay lehet.
• Győződjön meg róla, hogy a riasztás nem jelenik meg egyszerre a böngészőforrásból és egy másik, ugyanazt az oldalt tartalmazó rétegből.
• A beállítások módosítása után indítsa újra teljesen a forrást, ne csak váltson jelenetet.

Néha az OBS-ben egy régi böngészőforrás-fül marad az URL vagy a paraméterek frissítése után. A forrás bezárása és újbóli hozzáadása segít ellenőrizni a hipotézist, de ez nem helyettesíti a kód javítását. Ha minden frissítés után visszatér a probléma, keresse az ismételt kezelőregisztrációt vagy a kettős kapcsolatot.

Vegye figyelembe a leválasztási késleltetést is. Frissítéskor a régi munkamenet nem feltétlenül záródik be azonnal. Ha a szerver néhány másodpercig aktívnak tekinti, az ebben az időszakban érkező esemény két munkamenetbe is bekerülhet. A szerver normál logikájának el kell távolítania az inaktív kapcsolatokat, és nem szabad előfizetést hagynia az oldal bezárása után.

Védelem egy esemény ismételt kézbesítése ellen

Még a böngészőforrás helyes működése mellett is előfordulhat, hogy egy esemény ismételten kézbesítésre kerül. Ez lehetséges a kapcsolat helyreállításakor, egy üzenet újraküldésekor vagy az esemény fogadása és feldolgozásának visszaigazolása közötti hiba esetén. Ezért a riasztáskezelőnek ellenállónak kell lennie az ismétlésekkel szemben.

A legjobb módszer az adomány egyedi azonosítójának ellenőrzése. Mielőtt az eseményt a sorba állítja, mentse el az azonosítóját a már feldolgozott események halmazába. Ha ez az azonosító már szerepelt, az ismétlést ki kell hagyni. A listát korlátozott ideig érdemes tárolni, hogy ne növekedjen a végtelenségig.

Ne használjon ehhez csak az összeget, a küldő nevét vagy az üzenet szövegét. Két különböző adománynak lehetnek ugyanazok az adatai. Az idő szerinti ellenőrzés sem megbízható: több különböző adomány érkezhet szinte egyszerre. Ha nincs azonosító, ideiglenesen össze lehet hasonlítani a mezők és az idő kombinációját, de ez tartalék megoldás, amelynek kockázata, hogy két eseményt tévesen összevon.

A duplikálás elleni védelemnek a riasztás megjelenítése előtt kell lennie, nem az animáción belül. Ellenkező esetben a második hívás továbbra is hozzáad egy elemet az oldalhoz, lejátssza a hangot, vagy még egy bejegyzést tesz a sorba. A sort külön kell szabályozni: egy esemény csak egyszer kerülhet bele, és az ismételt hívás nem indíthat második független sort.

Ha az esemény több lap vagy komponens között kerül átadásra, ellenőrizze, hogy nem dolgozza-e fel egyszerre több címzett. Egy közös üzenetcsatorna több kezelőhöz is csatlakozhat. Ebben az esetben vagy egy fogyasztót kell megtartani, vagy egyértelműen meg kell határozni, melyik komponens felelős a riasztás megjelenítéséért.

Miért nem mindig segít a gyorsítótár törlése

A böngészőforrás frissítése után gyakran javasolják a gyorsítótár törlését. Ez orvosolhatja a helyzetet, ha egy régi szkriptverzió töltődött be, de a gyorsítótár nem távolítja el a felesleges kezelőket a már működő oldalból, és nem zárja be a forrás második példányát. Ha a duplikálódás minden újracsatlakozás után következetesen megismétlődik, az ok szinte biztosan a kapcsolódási logikában vagy a jelenet szerkezetében van.

Ellenőrizze, hogy valóban az új fájlverzió töltődik-e be. Ideiglenesen módosítsa az erőforrás címét, vagy használja a rendelkezésre álló frissítési mechanizmust, majd indítsa újra a böngészőforrást. Ezután ismét végezze el a tesztet egy ablakkal és a forrás egy példányával. Ne adjon véletlenszerű paramétereket folyamatosan a hivatkozáshoz: ez sok gyorsítótárazott változatot hozhat létre, és megnehezítheti a diagnosztikát.

Ha köztes gyorsítótárat vagy service workert használ, az is kiszolgálhat elavult szkriptet. Ebben az esetben hasonlítsa össze a betöltött fájl verzióját azzal a verzióval, amelyet látni szeretne. De még egy régi fájl esetén is meg kell szüntetni az ismételt előfizetés okát, különben a probléma a következő frissítés után újra megjelenik.

Mit kell ellenőrizni a riasztás kódjában

Először keresse meg az összes helyet, ahol a socket.on, addEventListener, a csatlakozási függvények és a sor indítása meghívásra kerül. Néha a probléma nem egyetlen kezelőben van, hanem abban, hogy két különböző modul egymástól függetlenül figyeli a donation eseményt, és mindegyik elindítja a saját megjelenítését.

Ezután ellenőrizze a komponens életciklusát, ha a riasztás keretrendszeren keresztül jelenik meg. Az előfizetést effektben vagy hasonló blokkban helyezik el, és visszaadnak egy tisztító függvényt. Nem lehet új kezelőt létrehozni minden állapotfrissítéskor az előző eltávolítása nélkül. A hagyományos JavaScriptben fontos az aktív socket és az aktuális kezelő hivatkozásának tárolása, hogy az oldal leállításakor megfelelően bezárhatók legyenek.

Ellenőrizze az újracsatlakozási időzítőket. Az új időzítő nem indulhat a régi fölött. Ellenkező esetben néhány megszakadás után párhuzamos csatlakozási kísérletek jönnek létre, és velük együtt további előfizetések. Minden időzítőhöz clearTimeout vagy clearInterval segítségével történő törlés szükséges, ha már nincs rá szükség.

Külön nézze meg a riasztást megjelenítő kódot. Nem szabad egyszerre hozzáadnia egy elemet a sorhoz, és azonnal meghívnia a megjelenítő függvényt ugyanahhoz az objektumhoz. Azt is ellenőrizze, hogy az animáció nem indul-e újra az elem állapotának változásakor. Ha a naplóban egy fogadás és egy sorbeli bejegyzés szerepel, de a képernyőn két értesítés látható, pontosan itt kell keresni.

Diagnosztikai ellenőrzőlista: mit kell tenni sorban

1. Nyissa meg a böngészőforrás URL-jét egy külön lapon, és küldjön egy teszt adományt. Jegyezze fel, hogy megjelenik-e a duplikálódás az OBS-en kívül.
2. Hagyjon a jelenetben csak egy példányt a forrásból. Ellenőrizze a jelenetmásolatokat, a beágyazott jeleneteket és a rétegeket, ahol ugyanaz a cím lehet.
3. Adjon hozzá egy naplót az esemény azonosítójával a fogadás, a sorba állítás és a megjelenítés szakaszaiban. Így látható lesz, hol növekszik az objektumok száma.
4. Keresse meg az összes socket.on és addEventListener hívást. Ellenőrizze, hogy a régi kezelők eltávolításra kerülnek-e a socket.off és removeEventListener segítségével, ugyanazzal a függvényhivatkozással.
5. Ellenőrizze az újracsatlakozást: bezáródik-e a régi socket, megszakításra kerül-e a régi időzítő, és nem jön-e létre új előfizetés a korábbi fölött.
6. Adjon hozzá egy ellenőrzést az adomány egyedi azonosítójára a sor előtt, majd indítsa újra teljesen a forrást, és ismételje meg a tesztet egyetlen eseménnyel.

Ha egy külön lap egyszer kapja meg az eseményt, de az OBS két riasztást mutat, keresse a forrás második példányát vagy a jelenetekben lévő duplikálódást. Ha az esemény már a külön lapon kétszer érkezik meg, ellenőrizze az előfizetéseket, a kapcsolatokat és a szerveroldali kézbesítést. Ha a fogadás és a sor egyszer kerül rögzítésre, de a képernyőn két értesítés látható, a probléma a vizuális rétegben van.