Soms wordt er een servicemedewerker met buggy ingezet en dan ontstaan er problemen. Een servicemedewerker kan bijvoorbeeld tijdens de registratie worden geparseerd en de installatie met succes voltooien. Toch kan code met fouten in een fetch -gebeurtenis ervoor zorgen dat deze niet op verzoeken reageert, wat resulteert in een lege pagina. Een andere mogelijkheid is dat pagina-opmaak agressief in de cache wordt opgeslagen, en dat een servicemedewerker alleen verouderde opmaakreacties van een Cache instantie retourneert voor volgende bezoeken.
Er zijn veel manieren waarop een servicemedewerker een averechts effect kan hebben, en dat is een beangstigend probleem op een productiewebsite. Toch is niet alles verloren. Er zijn manieren om de situatie op te lossen en weer op het goede spoor te komen.
Zet een servicemedewerker zonder operationele activiteiten in
Het enige dat normaal gesproken nodig is om met een servicemedewerker met fouten om te gaan, is het inzetten van een standaard no-op- servicemedewerker die onmiddellijk wordt geïnstalleerd en geactiveerd zonder een fetch :
// sw.js
self.addEventListener('install', () => {
// Skip over the "waiting" lifecycle state, to ensure that our
// new service worker is activated immediately, even if there's
// another tab open controlled by our older service worker code.
self.skipWaiting();
});
self.addEventListener('activate', () => {
// Optional: Get a list of all the current open windows/tabs under
// our service worker's control, and force them to reload.
// This can "unbreak" any open windows/tabs as soon as the new
// service worker activates, rather than users having to manually reload.
self.clients.matchAll({
type: 'window'
}).then(windowClients => {
windowClients.forEach((windowClient) => {
windowClient.navigate(windowClient.url);
});
});
});
Deze servicemedewerker zal onmiddellijk installeren en activeren door self.skipWaiting() aan te roepen tijdens de install . Optioneel kan extra code worden geïmplementeerd in de activate om andere geopende tabbladen geforceerd opnieuw te laden met een WindowClient die de servicemedewerker beheert.
Het is heel belangrijk dat een no-op-servicemedewerker geen gebeurtenishandler fetch bevat. Wanneer een servicemedewerker geen verzoeken afhandelt, worden deze aanvragen doorgestuurd naar de browser alsof er geen servicemedewerker aanwezig is. Zodra een no-op-servicemedewerker is ingezet, kan de servicemedewerker met fouten worden gerepareerd en later als update worden ingezet.
Deze aanpak werkt gedeeltelijk omdat browsers sterke beveiligingen hebben tegen het plaatsen van servicemedewerkers in de HTTP-cache , en omdat ze byte-voor-byte controles uitvoeren op de inhoud van een servicemedewerker op updates. Deze standaardinstellingen maken het mogelijk om een no-op-vervanging in te zetten voor een servicemedewerker met fouten om het probleem snel op te lossen.
Extra maatregelen te nemen
Het inzetten van een no-op-servicemedewerker zou voldoende moeten zijn om een medewerker met fouten te neutraliseren, maar indien nodig kunnen aanvullende maatregelen worden genomen.
Wat moet u doen als u de URL van de oude servicemedewerker niet kent?
Soms is de URL van een eerder geïnstalleerde servicemedewerker onbekend. Dit kan zijn omdat het een versienummer heeft (het bevat bijvoorbeeld een hash in de bestandsnaam). In dit geval kan het een uitdaging zijn om een no-op-servicemedewerker in te zetten die overeenkomt met de URL van elke oude servicemedewerker die mogelijk is geregistreerd. Dit druist in tegen best practices , omdat ontwikkelaars waarschijnlijk niet elke hash zullen onthouden voor elke service worker-versie die is geïmplementeerd.
Gelukkig wordt er een nuttige HTTP-verzoekheader verzonden met een verzoek om een service worker-script: Service-Worker . Controleer op de webserver of deze header aanwezig is en onderschep het verzoek om in plaats daarvan een servicemedewerker te bedienen die buiten dienst is. Het bereiken van deze prestatie is afhankelijk van de gebruikte webserver en backend-stack, dus raadpleeg de documentatie van de relevante taal over hoe u dit kunt doen.
Wat betreft toekomstige implementaties van servicemedewerkers, blijf bij activanamen zonder versiebeheer (bijvoorbeeld sw.js ). Dit maakt de zaken later een stuk minder ingewikkeld.
Stel een Clear-Site-Data header in
Sommige browsers zullen de registratie van alle servicemedewerkers voor een oorsprong ongedaan maken als een Clear-Site-Data antwoordheader met de waarde 'storage' is ingesteld. Er zijn echter een aantal dingen waar u rekening mee moet houden bij deze aanpak:
- Wees gewaarschuwd: hierdoor wordt alle opslagruimte voor de bijbehorende oorsprong gewist. Dat omvat
localStorage, IndexedDB,sessionStorageen andere opslag (maar niet de HTTP-cache voor de oorsprong). - Deze header wordt niet in alle browsers ondersteund .
Omdat de ondersteuning voor deze header niet volledig is, kan er niet alleen op worden vertrouwd om het probleem op te lossen. Het is daarom het beste om Clear-Site-Data te zien als een maatregel die u kunt nemen naast het inzetten van een no-op-servicemedewerker.
De schade is niet blijvend
Het kan beangstigend zijn als de gebruikerservaring wordt verstoord door een servicemedewerker met fouten, vooral voor grote en bekende websites, maar de schade is tijdelijk en omkeerbaar!
Als het nodig is om een buitendienstmedewerker in te zetten om de situatie op te lossen, neem dan achteraf de tijd om erachter te komen wat er precies is misgegaan. Zorg er in de toekomst voor dat een servicemedewerker alleen de verzoeken afhandelt die van hem worden verwacht. Test regelmatig tijdens de fasering en implementeer alleen updates als u er zeker van bent.