Serwisant PWA dla manekinów

Opublikowany: 2020-08-27

Spis treści

Faktem jest, że service worker ma do odegrania ważną rolę w nadchodzących latach, a im szybciej będziesz mógł zapoznać się z nową technologią, tym lepiej możesz dostosować się do nowej przyszłości sieci.

Dlatego, aby pomóc Ci lepiej poznać tę nową technologię, wspólnie porozmawiamy o pracownikach usług – co to jest, co wnosi do sieci, jak możemy lepiej przygotować się do tej nowej technologii sieć.

Kim jest pracownik serwisu?

Definicje

Powszechnie uważany za technologię, która tworzy lub łamie PWA, service worker to interfejs API, który działa niezależnie od przeglądarki i jest odpowiedzialny za przechwytywanie sieci — iz tego powodu może wykonywać wiele rzeczy, które wcześniej były niemożliwe w sieci. Witryny internetowe (zazwyczaj PWA) kontrolowane przez pracowników usług mogą mieć głębszą integrację z używanym urządzeniem, co w konsekwencji zapewnia więcej możliwości sprzętowych i funkcji podobnych do aplikacji w sieci Web (np. powiadomienia push, synchronizacja w tle i inne).

Jak to działa

W skrócie. Service worker to zasadniczo warstwa oparta na zdarzeniach między przeglądarką a serwerem, która przechwytuje, modyfikuje i obsługuje wychodzące żądania sieciowe:

Jak działa pracownik serwisu

A ponieważ Service Worker jest pracownikiem opartym na zdarzeniach , reaguje na zdarzenia i komunikuje się za ich pośrednictwem, a także używa obietnic, aby stwierdzić, kiedy operacja została zakończona. Jednak wszystkie odbieranie zdarzeń (np. fetch i push ) jest możliwe tylko wtedy, gdy service worker jest aktywny , co wskazuje, kiedy przeglądarka rozpoznaje i rejestruje service workera (a także, kiedy sam service worker pomyślnie zakończył instalację) . W uproszczeniu jest to typowy cykl życia pracownika serwisu:

Cykl życia pracownika serwisu

Zwróć także uwagę na wszystkie dostępne zdarzenia w Service Worker:

Wydarzenia dla pracowników serwisu
Podsumowanie dostępnego zdarzenia Service Worker [Źródło: Mozilla]

Wszystkie zdarzenia funkcjonalne ( fetch , sync i push ) powinny być dla Ciebie oczywiste, ponieważ są to zdarzenia, które składają się na prawie wszystkie cechy progresywnej funkcji PWA (tj. możliwości offline, synchronizacja w tle, powiadomienia push).

 Zalecana literatura: Co to jest PWA? Wszystko, co musisz wiedzieć o progresywnych aplikacjach internetowych

Ograniczenia pracowników usług

Ponieważ jest to skrypt, który działa niezależnie od przeglądarki, istnieją pewne ograniczenia:

  • Protokół HTTPS : Service Workery muszą być uruchamiane na stronach internetowych opartych na HTTPS
  • Brak dostępu do localStorage , DOM i okna.
  • Ograniczony scope : Service Worker może działać tylko w scope bieżącego katalogu (i podkatalogów), w którym znajduje się service-worker.js .
  • Asynchroniczny : procesy robocze usług są z natury asynchroniczne, dlatego opierają się na interfejsach API opartych na Promise.

Co pracownicy serwisowi oznaczają dla PWA

Jak wspomniano wcześniej, service worker jest kręgosłupem PWA, bez którego wiele rewolucyjnych funkcji PWA jest po prostu niemożliwych. Zasadniczo to, co robi service worker, to zapewnia środki na:

Lepsza wydajność

Wydajność przy wielokrotnych wizytach jest znacznie lepsza na PWA, ponieważ pracownicy serwisu ogromnie pomagają w procesie buforowania. W porównaniu do typowej pamięci podręcznej WWW (cache HTTP) stosowanej w większości serwisów, PWA doskonale radzi sobie z serwowaniem treści nawet w niesprzyjających warunkach sieciowych:

Porównanie średnich czasów ładowania strony

To wszystko dzięki temu, że service workery dają programistom całkowitą swobodę w tym, co dokładnie i jak odbywa się buforowanie. Aby zobaczyć, o ile lepsza jest wydajność buforowania pracowników usług, zalecamy ostatnie badanie Google: Pomiar rzeczywistego wpływu pracowników usług na wydajność. Badanie ma jasną metodologię, skupiającą się na czasie do pierwszego malowania jako miara określająca wydajność pracownika serwisu.

Średnio strony ładowały się nieco szybciej, gdy pracownik obsługi kontrolował stronę, niż bez pracownika obsługi, zarówno dla nowych, jak i powracających użytkowników.

Philip Walton, Mierzenie rzeczywistego wpływu pracowników usług na wydajność

Dostęp offline

Po zarejestrowaniu pracownicy serwisu buforują zawartość niezbędną dla Twojej witryny PWA i udostępniają ją później. To skutecznie sprawia, że ​​witryny oparte na PWA mogą działać w trybie offline, ponieważ użytkownicy mogą nadal wchodzić w interakcje z witryną i wyświetlać całą zawartość pamięci podręcznej.

Wyświetlaj treści, nawet gdy jesteś offline, dzięki pracownikowi serwisu

Nie oznacza to, że dostęp w trybie offline jest również funkcją wcześniej niewidoczną w sieci — możliwe było zapewnienie użytkownikom korzystania z sieci w trybie offline, po prostu nie było to optymalne doświadczenie (patrz Pamięć podręczna aplikacji to douchebag) i usługi pracownicy zostali wymyśleni, aby rozwiązać (a raczej uniknąć) wady AppCache.

 Polecana literatura: Jak sprawić, by PWA działało w trybie offline

Natywne funkcje aplikacji

Oprócz oferowania dostępu w trybie offline i lepszej wydajności, pracownicy usług służą również jako podstawa dla większej liczby funkcji podobnych do aplikacji, takich jak powiadomienia push i synchronizacja w tle (a w niedalekiej przyszłości geofencing i okresowa synchronizacja). Na przykład funkcja powiadomień push w PWA jest tworzona przy użyciu dwóch interfejsów API: Notifications API i Push API, które są zbudowane na bazie Service Worker API.

Cykl życia pracownika usług

Czas życia usługi składa się z trzech części: rejestracji, instalacji i aktywacji, z których wszystkie omówimy poniżej:

Rejestracja

Pierwszym krokiem, który musimy zrobić, jest zarejestrowanie pracownika serwisu. Bez tego kroku przeglądarka nie będzie wiedziała, gdzie znajduje się Twój Service Worker, co uniemożliwi zainstalowanie Service Workera w tle.
Serwisanta możemy zarejestrować za pomocą kodu:

 if('serviceWorker' w nawigatorze) {
    navigator.serviceWorker.register('./pwa-examples/simicart/sw.js', {zakres: './sw-scope/'})
.to((reg) => {
   // rejestracja zadziałała
       console.log('Rejestracja powiodła się. Zakres to ' + reg.scope);
};

Powyższy kod najpierw zacznie szukać Service Worker API w przeglądarce i jeśli przeglądarka obsługuje wspomniane API, rejestruje nowego service workera przy użyciu metody serviceworkerContainer.register() i podaje scope service workera. Na przykład w powyższym kodzie, naszym scope jest /pwa-examples/simicart/ , co oznacza, że ​​nasz service worker działałby tylko dla stron zaczynających się od /pwa-examples/simicart/ . Nazywamy te strony „ stronami kontrolowanymi ”.

Instalacja

Teraz, gdy przeglądarka wie, gdzie znajduje się nasz service worker i jaki jest jego zakres, spróbuje go zainstalować. Możesz nic nie robić w tej fazie, ale nadal chcielibyśmy zauważyć, że jest to faza, w której odbywa się większość procesu buforowania. Na przykład w ten sposób zwykle odbywa się proces buforowania zasobów:

 const cacheName = 'witryna-cache-v1'
const assetToCache = [
    '/pwa-przyklady/',
    '/pwa-przyklady/index.html',
    '/pwa-examples/css/styles.css',
    '/pwa-przyklady/js/app.js',
]

self.addEventListener('install', ( event ) => {
    event.waitUntil(  
        caches.open(cacheName).then((cache) => {
              return cache.addAll(assetsToCache);
        })
      );
});

Jak widać w powyższym przykładzie, używamy Cache API do buforowania naszych zasobów, które później wykorzystamy, aby nasze PWA działały w trybie offline. Ten proces buforowania ma miejsce podczas zdarzenia instalacji.

Aktywacja

Po etapie instalacji możemy teraz aktywować pracownika serwisu. Jednak ten etap aktywacji zwykle nie odbywa się automatycznie i aby aktywować pracownika serwisu, należy upewnić się, że żaden pracownik serwisu nie kontroluje obecnie stron.

Alternatywnie możesz również zautomatyzować proces aktywacji swojego Service Workera za pomocą metody skipWaiting() .

 const cacheName = 'witryna-cache-v1'
const assetToCache = [
    '/pwa-przyklady/',
    '/pwa-przyklady/index.html',
    '/pwa-examples/css/styles.css',
    '//pwa-przyklady/js/app.js',
]
self.addEventListener('install', ( event ) => {
    self.skipOczekiwanie(); // pomiń czekanie
    event.waitUntil(  
        caches.open(cacheName).then((cache) => {
              return cache.addAll(assetsToCache);
        })
      );
});

Sieć potrzebuje pracownika serwisu

W tym momencie wszyscy możemy się zgodzić, że service worker jest niemal ostatecznym krokiem, który musi podjąć sieć. Użytkownicy stają się coraz bardziej wymagający od funkcji podobnych do aplikacji, a w połączeniu z faktem, że PWA staje się przyszłością dostarczania oprogramowania, wygląda na to, że Internet ma duży potencjał w nadchodzących latach.

Zobacz ten post na Instagramie

Dzisiejszy Internet jest niesamowicie potężną platformą, ale wciąż istnieje przepaść między możliwościami aplikacji internetowych a możliwościami aplikacji natywnych. Dzięki progresywnym aplikacjom internetowym jesteśmy na dobrej drodze, ale aby naprawdę konkurować, sieć potrzebuje również dostępu do wydajniejszych interfejsów API. Dobra wiadomość! Nadchodzą! Posłuchaj wykładu zatytułowanego „Bidging the native app gap” Sama Richarda, aby dowiedzieć się więcej o nowych i nadchodzących interfejsach API. . . #SimiCart #ChromeDevSummit #ChromeDevSummit #SamRichard #pwa #nativeapp

Post udostępniony przez SimiCart (@simicart.official) on

Sprzedawcom Magento, którzy chcą przekształcić witrynę sklepową, zapewniamy opłacalne i kompletne rozwiązanie bezgłowego PWA dla Twojej firmy.

Rozwiń swój sklep Magento PWA Storefront