Waarom één donatie twee alerts veroorzaakt na het vernieuwen van de browserbron

Waarom één donatie twee alerts veroorzaakt

Na het vernieuwen van de browserbron wordt de pagina opnieuw gestart. Het script maakt opnieuw verbinding met de server, abonneert zich op gebeurtenissen en maakt handlers aan om meldingen te tonen. Als de oude handler niet is verwijderd of als er tegelijkertijd twee verbindingen actief zijn, wordt één donatiegebeurtenis meerdere keren verwerkt.

De vernieuwing zelf is niet per se de oorzaak van de storing. Vaak maakt die alleen een fout in de verbindingslogica zichtbaar. Een initialisatiefunctie kan bijvoorbeeld worden uitgevoerd bij het laden van de pagina, vervolgens bij het herstellen van de verbinding en nog een keer na ontvangst van een servicebericht. Elke uitvoering voegt een nieuw abonnement op de donation-gebeurtenis toe.

Het gevolg is dat de server één donatieobject verstuurt, maar de browser dezelfde functie twee keer aanroept. Soms ontstaat de verdubbeling aan de serverkant: de applicatie beschouwt de nieuwe verbinding als een aparte ontvanger en stuurt de gebeurtenis naar zowel de oude als de nieuwe sessie. Daarom moet je eerst bepalen waar de herhaling optreedt: in de bron, in de handler of tijdens de weergave.

Hoe je de plek vindt waar de verdubbeling ontstaat

Begin met een eenvoudige test. Open de link van de browserbron in een apart venster of tabblad, laat slechts één exemplaar van de pagina open en stuur een testgebeurtenis. Als de alert één keer verschijnt, hangt de oorzaak waarschijnlijk samen met de scène-instellingen of met meerdere exemplaren van de bron. Als de alert al in een apart tabblad wordt verdubbeld, controleer dan de paginacode en het abonnementsmechanisme.

Het is handig om de verwerking van een donatie in verschillende fasen te splitsen: het ontvangen van de gebeurtenis, het controleren van de gebeurtenis, het in de wachtrij plaatsen van de alert en het weergeven. Voer tijdelijk in het logboek of de console een markering in bij elke fase. Als de registratie van ontvangst twee keer verschijnt, ligt het probleem vóór de visuele laag. Als de gebeurtenis één keer is ontvangen maar er twee items in de wachtrij staan, zit de fout in de handler. Als de wachtrij één item bevat maar er twee alerts op het scherm staan, controleer dan de weergavefunctie en de HTML-container.

Voeg voor diagnostiek aan elke gebeurtenis de id toe, als die in de donatiegegevens wordt meegegeven. Noteer deze id bij ontvangst en vóór de weergave. Dezelfde id in twee aanroepen toont aan dat één gebeurtenis opnieuw is verwerkt. Twee verschillende id's wijzen op twee leveringen, die afzonderlijk moeten worden onderzocht.

Controleer niet alleen het aantal tabbladen. In OBS kunnen twee exemplaren ontstaan na het kopiëren van een scène, het toevoegen van een geneste scène of het opnieuw toevoegen van een browserbron met hetzelfde adres. Soms blijft één bron in een aparte laag staan en wordt de tweede daarbovenop toegevoegd. Visueel lijkt dat een dubbele alert, hoewel de gebeurtenis één keer is aangekomen.

Opnieuw abonneren na herverbinden

De meest voorkomende oorzaak is dat de handler bij elke verbinding wordt toegevoegd, maar niet wordt verwijderd bij verbreking. Vereenvoudigd ziet het probleem er zo uit: de functie start socket.on met een handler voor het tonen van de alert, vervolgens valt de verbinding weg, de applicatie maakt opnieuw verbinding en herhaalt socket.on. Daarna veroorzaakt één inkomende donatie twee functies. Bij de volgende herverbinding kunnen het er nog meer worden.

Dezelfde fout komt voor met een gewone addEventListener. Als de initialisatiefunctie meerdere keren wordt uitgevoerd, voegt de browser meerdere listeners voor dezelfde gebeurtenis toe. Een controle met een vlag 'initialisatie al uitgevoerd' helpt niet altijd: bij een volledige vernieuwing van de pagina worden variabelen gereset, en bij herverbinden binnen dezelfde pagina blijft het probleem bestaan.

Het abonnement moet één keer per levenscyclus van de verbinding worden aangemaakt, en het oude abonnement moet expliciet worden verwijderd vóór het nieuwe. Voor gebeurtenishandlers gebruik je removeEventListener en dezelfde functiereferentie die bij het verbinden is doorgegeven. Voor bibliotheken met sockets is meestal een methode off, unsubscribe of een vergelijkbare manier van afmelden nodig.

Een minimale opzet voor een socket kan er zo uitzien: 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);

Niet de specifieke bibliotheek is hier belangrijk, maar de volgorde van handelingen. De handler wordt in een variabele opgeslagen, zodat die met dezelfde referentie kan worden verwijderd. Vóór een nieuw abonnement wordt het oude verwijderd, en bij het sluiten van de pagina of het stoppen van de bron wordt cleanup uitgevoerd. Als bij elke start een nieuwe socket wordt aangemaakt, moet eerst de oude worden gesloten en pas daarna de nieuwe worden aangemaakt. Anders kunnen beide verbindingen dezelfde gegevens blijven ontvangen.

Sluit bij herverbinden ook de oude verbinding en wis de bijbehorende timers. Anders kan de oude socket gegevens blijven ontvangen terwijl de nieuwe al werkt. Dit gebeurt vooral vaak wanneer de code een nieuwe timer voor herverbinding start zonder de vorige te annuleren.

Wat je moet controleren in OBS en de browserbron

Als een apart venster de alert één keer toont, ga dan naar de scène. Stop de voorbeeldweergave, verwijder tijdelijk overbodige lagen en laat één browserbron staan. Controleer daarna het gedrag in de betreffende scène. Zo'n test is sneller dan het tegelijk controleren van alle scènes en filters.

• Zoek naar twee bronnen met hetzelfde pagina-adres.
• Controleer kopieën van scènes en geneste scènes waarin dezelfde overlay kan zitten.
• Zorg ervoor dat de alert niet tegelijk wordt weergegeven door de browserbron en een andere laag met dezelfde pagina.
• Herstart de bron na het wijzigen van instellingen volledig, en schakel niet alleen van scène.

Soms blijft in OBS een oude tab van de browserbron achter na het vernieuwen van de URL of parameters. De bron sluiten en opnieuw toevoegen helpt om de hypothese te testen, maar vervangt niet het oplossen van de code. Als het probleem na elke vernieuwing terugkomt, zoek dan naar opnieuw registreren van de handler of een dubbele verbinding.

Houd ook rekening met vertraging bij het verbreken. Bij een vernieuwing sluit de oude sessie mogelijk niet onmiddellijk. Als de server die nog enkele seconden als actief beschouwt, kan een gebeurtenis die in dat interval binnenkomt in twee sessies terechtkomen. Een correcte serverlogica moet inactieve verbindingen verwijderen en geen abonnement laten staan nadat de pagina is gesloten.

Bescherming tegen dubbele levering van één gebeurtenis

Zelfs bij een correct werkende browserbron kan één gebeurtenis soms opnieuw worden geleverd. Dat is mogelijk bij het herstellen van een verbinding, bij het opnieuw versturen van een bericht of bij een storing tussen het ontvangen van de gebeurtenis en het bevestigen van de verwerking. Daarom moet de alerthandler bestand zijn tegen herhalingen.

De beste manier is om de unieke id van de donatie te controleren. Sla vóór het in de wachtrij plaatsen van de gebeurtenis de id op in een set van al verwerkte gebeurtenissen. Als zo'n id al is voorgekomen, moet de herhaling worden overgeslagen. Bewaar de lijst een beperkte tijd, zodat die niet eindeloos groeit.

Gebruik hiervoor niet alleen het bedrag, de naam van de afzender of de tekst van het bericht. Twee verschillende donaties kunnen dezelfde gegevens hebben. Een controle op tijd is ook onbetrouwbaar: meerdere verschillende donaties kunnen bijna tegelijk binnenkomen. Als er geen id is, kun je tijdelijk een combinatie van velden en tijd vergelijken, maar dat is een noodoplossing met het risico dat twee gebeurtenissen ten onrechte worden samengevoegd.

De bescherming tegen dubbele meldingen moet vóór het tonen van de alert plaatsvinden, niet binnen de animatie. Anders voegt de tweede aanroep alsnog een element aan de pagina toe, speelt geluid af of zet nog een item in de wachtrij. Beheer de wachtrij afzonderlijk: één gebeurtenis mag er maar één keer aan worden toegevoegd, en een herhaalde aanroep mag geen tweede onafhankelijke wachtrij starten.

Als de gebeurtenis tussen meerdere tabbladen of componenten wordt doorgegeven, controleer dan of meerdere ontvangers die tegelijk verwerken. Eén gedeeld berichtkanaal kan aan meerdere handlers zijn gekoppeld. In dat geval moet je ofwel één verbruiker aanhouden, ofwel expliciet bepalen welke component verantwoordelijk is voor het tonen van de alert.

Waarom het wissen van de cache niet altijd helpt

Na het vernieuwen van de browserbron wordt vaak aangeraden de cache te wissen. Dat kan de situatie verhelpen als een oude versie van het script is geladen, maar de cache verwijdert geen overbodige handlers in een al werkende pagina en sluit ook geen tweede exemplaar van de bron. Als de verdubbeling na elke herverbinding stabiel terugkomt, ligt de oorzaak vrijwel zeker in de verbindingslogica of in de scène-opbouw.

Controleer of echt de nieuwe versie van de bestanden wordt geladen. Wijzig tijdelijk het adres van de resource of gebruik het voorziene mechanisme voor vernieuwing, en herstart daarna de browserbron. Voer daarna opnieuw de test uit met één venster en één exemplaar van de bron. Voeg niet voortdurend willekeurige parameters aan de link toe: dat kan veel cachevarianten opleveren en de diagnose moeilijker maken.

Als er een tussenliggende cache of service worker wordt gebruikt, kan ook die een verouderd script leveren. Vergelijk in dat geval de versie van het geladen bestand met de versie die je verwacht te zien. Maar zelfs bij een oud bestand moet de oorzaak van het opnieuw abonneren worden verholpen, anders komt het probleem na de volgende vernieuwing weer terug.

Wat je moet controleren in de code van de alert

Zoek eerst alle plekken waar socket.on, addEventListener, verbindingsfuncties en het starten van de wachtrij worden aangeroepen. Soms zit het probleem niet in één handler, maar luisteren twee verschillende modules onafhankelijk naar de donation-gebeurtenis en start elk zijn eigen weergave.

Controleer vervolgens de levenscyclus van de component als de alert via een framework wordt weergegeven. Het abonnement wordt in een effect of een vergelijkbaar blok geplaatst en er wordt een opschoonfunctie teruggegeven. Je mag niet bij elke statusupdate een nieuwe handler aanmaken zonder de vorige te verwijderen. In gewoon JavaScript is het belangrijk een verwijzing naar de actieve socket en de huidige handler te bewaren, zodat ze bij het stoppen van de pagina correct kunnen worden gesloten.

Controleer de timers voor herverbinding. Een nieuwe timer mag niet over een oude heen worden gestart. Anders ontstaan na meerdere onderbrekingen parallelle verbindingspogingen, en daarmee extra abonnementen. Voor elke timer is opschonen via clearTimeout of clearInterval nodig als die niet meer nodig is.

Bekijk apart de code die de alert toont. Die mag niet tegelijk een element aan de wachtrij toevoegen en meteen de weergavefunctie voor hetzelfde object aanroepen. Controleer ook of de animatie niet opnieuw wordt gestart bij een wijziging van de status van het element. Als het logboek één ontvangst en één item in de wachtrij toont, maar er twee meldingen op het scherm staan, moet je juist hier zoeken.

Diagnosechecklist: wat je in welke volgorde moet doen

1. Open de URL van de browserbron in een apart tabblad en stuur één testdonatie. Noteer of de verdubbeling buiten OBS optreedt.
2. Laat in de scène slechts één exemplaar van de bron staan. Controleer kopieën van scènes, geneste scènes en lagen waarin hetzelfde adres kan zitten.
3. Voeg een logboek met de gebeurtenis-id toe bij de fasen ontvangen, in de wachtrij plaatsen en weergeven. Zo wordt zichtbaar waar het aantal objecten toeneemt.
4. Zoek alle aanroepen van socket.on en addEventListener. Controleer of oude handlers worden verwijderd via socket.off en removeEventListener met dezelfde functiereferentie.
5. Controleer het herverbinden: wordt de oude socket gesloten, wordt de oude timer geannuleerd en wordt er geen nieuw abonnement over het vorige heen aangemaakt.
6. Voeg een controle van de unieke donatie-id toe vóór de wachtrij, herstart daarna de bron volledig en herhaal de test met één gebeurtenis.

Als een apart tabblad de gebeurtenis één keer ontvangt maar OBS twee alerts toont, zoek dan naar een tweede exemplaar van de bron of verdubbeling in de scènes. Als de gebeurtenis al in een apart tabblad twee keer binnenkomt, controleer dan abonnementen, verbindingen en serverlevering. Als ontvangst en wachtrij één keer worden geregistreerd maar er twee meldingen op het scherm staan, ligt het probleem in de visuele laag.