Share
L'API Service Worker per i browser consente ai web designer di offrire ai visitatori qualcosa che non avevano mai avuto prima: accesso a siti o applicazioni Web anche offline, sia per brevi che lunghi periodi di tempo.
Se vuoi che un visitatore possa ancora leggere il tuo sito mentre attraversi un tunnel ferroviario o desideri creare app che non richiedono una connessione Internet, gli addetti all'assistenza forniscono la soluzione perfetta.
Per quanto grandi siano gli addetti all'assistenza, quando inizi a codificarli per la prima volta ci sono alcuni inconvenienti che possono rallentare i tuoi progressi, a meno che tu non sia consapevole di quali ostacoli sono in sospeso. Questo tutorial ti fornirà cinque consigli essenziali per lo sviluppo del service worker e speriamo che ti aiutino a evitare questi singhiozzi e ti salvi dal mal di testa associato alla risoluzione dei problemi.
Se sei nuovo agli addetti all'assistenza visita il corso per principianti Operatori di servizio semplici per siti web offline e il libro di Jeremy Keith Going Offline, entrambi disponibili su Envato Elements.
Il primo problema che potrebbe farti inciampare quando scrivi il tuo primo operatore di servizio, è che probabilmente farai quello che fai sempre e inserirai lo script in una sottodirectory di nome js o script. Tuttavia, con gli addetti al servizio, questa azione run-of-the-mill può essere problematica.
Il motivo è che l'ambito del vostro addetto al servizio è, per impostazione predefinita, definito dalla sua posizione. Cosa significa? Significa che tu metti la tua sceneggiatura in a / js directory il suo ambito è ora limitato a quello / js directory. Di conseguenza, può gestire solo le richieste di pagina che arrivano via www.yoursite.com/js/, e ignorerà completamente altre richieste, come quelle in corso www.yoursite.com o www.yoursite.com/news/ per esempio.
Questo ambito limitato a sua volta significa che non sarai in grado di fornire fallback offline per la maggior parte del tuo sito. Affinché il tuo addetto all'assistenza sia in grado di gestire qualsiasi richiesta proveniente da qualsiasi parte del tuo sito, il suo ambito deve essere onnicomprensivo.
Nota: puoi effettivamente ignorare l'ambito predefinito del tuo operatore di servizio quando lo si registra, ad es.
Accentsconagua
navigator.serviceWorker.register ('/ sw.js', scope: '/'); Con questo approccio puoi comunque ospitare tutti gli script in una sottodirectory se ciò è molto importante per il tuo progetto.
Ma in generale, l'approccio più semplice è quello di mettere il vostro operatore di servizio nella directory radice, quindi impostare automaticamente il suo ambito per coprire l'intero sito.
Mentre gli addetti all'assistenza sono supportati in tutti i principali browser, al momento Chrome o Chromium è indiscutibilmente il miglior browser per svilupparli. Ciò è dovuto al pannello dell'applicazione molto utile, disponibile negli Strumenti per sviluppatori. Quando stai attraversando il processo di sviluppo ti troverai praticamente in questa scheda:
In questa scheda è presente una sezione dedicata per gli operatori del servizio in cui è possibile verificare che lo script sia registrato, attivo e in esecuzione. Puoi anche utilizzare questa scheda per simulare l'offline, bypassare temporaneamente gli addetti all'assistenza e annullare manualmente la registrazione degli script precedenti che non ti servono più.
Oltre a non inserire script in una sottodirectory, un'altra abitudine di sviluppo che dovrai interrompere quando si mettono insieme i lavoratori dell'assistenza sta utilizzando "Hard Reload" o "Empty Cache and Hard Reload". Probabilmente lo hai fatto migliaia di volte durante il test dei siti, utilizzando la funzionalità per eliminare la cache e assicurarti di vedere un riflesso accurato delle tue modifiche allo sviluppo. Ma con i lavoratori del servizio questo non otterrà l'effetto desiderato.
Quando un operatore di servizio è registrato e attivo, qualsiasi utilizzo di "Hard Reload" lo ignorerà completamente. Potresti ricaricare il tuo sito, vedere che il tuo codice non è eseguito come ti aspetti e pensare di aver commesso un errore, solo per rendersi conto che in seguito la sceneggiatura non è mai stata pubblicata.
Quindi la cattiva notizia è "Hard Reload" e "Empty Cache and Hard Reload" sono fuori limite durante lo sviluppo del service worker, portandoci alla nostra prossima domanda:
Come puoi aggiornare correttamente la tua pagina e testare le modifiche al tuo codice di servizio se non puoi usare "Hard Reload" o "Empty Cache and Hard Reload"?
La risposta a questa domanda si trova nei seguenti due suggerimenti:
Per impostazione predefinita, quando si aggiorna una pagina su cui si sta testando un lavoratore del servizio, non si vedranno effettivamente i risultati di alcuna delle modifiche al codice. Questo perché la versione dello script inizialmente registrata è quella che rimane attiva nel browser, anche dopo il ricaricamento della pagina, a meno che non si intraprenda un'azione esplicita per aggiornarlo.
Quindi, di nuovo qui, abbiamo una situazione in cui potresti aggiornare la tua pagina e chiedervi perché le modifiche al codice non abbiano effetto, a meno che non siate a conoscenza delle stranezze dei lavoratori dei servizi.
Per essere sicuro di caricare sempre la versione più recente del tuo script, vai su applicazioni scheda e controllare il Aggiorna su Ricarica scatola. Questo assicura che ogni volta che ricarichi la pagina, (e ricorda, usa solo la ricarica normale, non la ricarica dura), il browser aggiornerà automaticamente l'addetto all'assistenza per te.
Nota: c'è l'opzione aggiuntiva per fare clic sul Aggiornare collegamento visualizzato accanto al tuo operatore di servizio registrato, ma l'utilizzo dell'approccio automatico su ricarica è in genere più semplice.
La funzione finale, molto utile, del applicazioni la scheda che stiamo per toccare è la possibilità di sbirciare all'interno degli oggetti memorizzati nella cache e di eliminarli manualmente secondo necessità. Dato che non vogliamo usare Cache vuota e Hard Reload, questa funzionalità diventerà una parte essenziale del processo di sviluppo del servizio di assistenza.
Nella colonna di sinistra del applicazioni scheda, vedrai un'area etichettata Archiviazione della cache. Se si espande quest'area, sarà possibile vedere tutti gli oggetti cache conservati nella memoria che si riferiscono all'URL corrente.
Fare clic su uno di questi elementi ed è possibile ispezionarne il contenuto, il che è molto utile per verificare che le risorse che si desidera servire offline vengano correttamente aggiunte alla cache dall'operatore del servizio.
Per eliminare gli oggetti cache non più necessari, fai clic con il pulsante destro del mouse su un oggetto e scegli Elimina.
Tra questa funzione di cancellazione dell'oggetto cache e il Aggiorna su Ricarica checkbox, sei pronto per continuare a utilizzare la normale ricarica della pagina, assicurandoti comunque di testare correttamente le ultime modifiche al tuo lavoro.
Per ulteriori informazioni sugli addetti ai servizi, consulta il nostro nuovo corso Simple Service Workers per i siti offline e il libro di Jeremy Keith Going Offline, ora disponibile su Envato Elements.
