Angular 2
Pracownik serwisowy

Wprowadzenie

Dodaj Service Worker do naszej aplikacji

Po pierwsze, jeśli konsultujesz mobile.angular.io z flagą - mobile już nie działa.

Na początek możemy stworzyć normalny projekt z kątowym cli.

ng new serviceWorking-example
cd serviceWorking-example

Teraz ważne jest, aby powiedzieć kątowemu cli, że chcemy skorzystać z usług pracownika, musimy:

ng set apps.0.serviceWorker = true

Jeśli z jakiegoś powodu nie masz zainstalowanego @ angular / service-worker, zobaczysz komunikat:

Twój projekt jest skonfigurowany z serviceWorker = true, ale @ angular / service-worker nie jest zainstalowany. Uruchom npm install --save-dev @angular/service-worker i spróbuj ponownie lub uruchom ng set apps.0.serviceWorker=false w pliku .angular-cli.json.

Sprawdź plik .angular-cli.json, a powinieneś zobaczyć: „serviceWorker”: true

Gdy ta flaga jest prawdziwa, kompilacje produkcyjne zostaną skonfigurowane z pracownikiem serwisu.

Plik ngsw-manifest.json zostanie wygenerowany (lub rozszerzony w przypadku, gdy utworzymy plik ngsw-manifest.json w katalogu głównym projektu, zwykle odbywa się to w celu określenia routingu, w przyszłości prawdopodobnie zostanie to zrobione automatycznie) w dist / root, a skrypt procesu roboczego usługi zostanie tam skopiowany. Krótki skrypt zostanie dodany do index.html w celu zarejestrowania pracownika serwisu.

Teraz, jeśli zbudujemy aplikację w trybie produkcyjnym ng build --prod

I sprawdź folder dist /.

Zobaczysz tam trzy nowe pliki:

• worker-basic.min.js
• sw-register.HASH.bundle.js
• ngsw-manifest.json

Ponadto index.html zawiera teraz ten skrypt sw-register, który rejestruje dla nas Angular Service Worker (ASW).

Odśwież stronę w przeglądarce (obsługiwanej przez serwer sieci Web dla Chrome)

Otwórz narzędzia programistyczne. Przejdź do aplikacji -> pracowników serwisu

Dobrze teraz, pracownik serwisowy działa!

Teraz nasza aplikacja powinna ładować się szybciej i powinniśmy móc korzystać z aplikacji offline.

Teraz, jeśli włączysz tryb offline w konsoli Chrome, powinieneś zobaczyć, że nasza aplikacja w http: // localhost: 4200 / index.html działa bez połączenia z Internetem.

Ale w http: // localhost: 4200 / mamy problem i nie można go załadować, ponieważ pamięć podręczna zawartości statycznej obsługuje tylko pliki wymienione w manifeście.

Na przykład, jeśli manifest deklaruje adres URL /index.html, żądania do /index.html zostaną odebrane przez pamięć podręczną, ale żądanie do / lub / some / route trafi do sieci.

Właśnie tam pojawia się wtyczka przekierowania trasy. Odczytuje konfigurację routingu z manifestu i przekierowuje skonfigurowane trasy do określonej trasy indeksu.

Obecnie ta sekcja konfiguracji musi być napisana ręcznie (19–7–2017). Ostatecznie zostanie wygenerowany z konfiguracji trasy obecnej w źródle aplikacji.

Więc jeśli teraz tworzymy lub ngsw-manifest.json w katalogu głównym projektu

{
  "routing": {
    "routes": {
      "/": {
        "prefix": false
      }
    },
    "index": "/index.html"
  }
}

I budujemy ponownie naszą aplikację, teraz, gdy przejdziemy do http: // localhost: 4200 / , powinniśmy zostać przekierowani do http: // localhost: 4200 / index.html .

Aby uzyskać więcej informacji na temat routingu, przeczytaj oficjalną dokumentację tutaj

Tutaj możesz znaleźć więcej dokumentacji na temat pracowników serwisu:

https://developers.google.com/web/fundamentals/getting-started/primers/service-workers

https://docs.google.com/document/d/19S5ozevWighny788nI99worpcIMDnwWVmaJDGf_RoDY/edit#

I tutaj możesz zobaczyć alternatywny sposób implementacji usługi działającej przy użyciu biblioteki pamięci podręcznej SW:

https://coryrylan.com/blog/fast-offline-angular-apps-with-service-workers