Jak sprawić, by Twoje PWA działało w trybie offline?

Zapewne wiesz, czym jest Progressive Web App – wraz z jej funkcjami, które zmieniają branżę – ale w celu powtórzenia powtórzmy jeszcze raz niesamowite, unikalne funkcje PWA, które mogą potencjalnie zrewolucjonizować sposób korzystania z sieci, czyli jej możliwości offline .

 Zalecana literatura: Co to jest PWA?

W przeciwieństwie do zwykłej sieci, w której przeglądanie treści jest dostępne tylko przy połączeniu, progresywna aplikacja internetowa różni się w ten sposób, że gdy pracownicy usług — wbudowany mechanizm odpowiedzialny za wiele progresywnych funkcji PWA — załadują niezbędne pliki, przeglądanie w trybie offline będzie możliwe, a użytkownicy będą mogli wchodzić w interakcję z aplikacją nawet w trybie offline.

Progresywne aplikacje internetowe i dostępność offline

Aby dowiedzieć się, na czym polega całe zamieszanie związane z PWA — zwłaszcza z możliwościami ich pracy w trybie offline, być może nadszedł czas, abyś osobiście zobaczył w trybie offline naszą główną stronę internetową, która z definicji jest również PWA.

Dzięki progresywnym aplikacjom internetowym całe doświadczenie offline nie różni się od typowego doświadczenia z połączeniem — i to jest jego piękno. Jest to funkcja szczególnie przydatna dla sklepów eCommerce, które potrzebują nieprzerwanego przeglądania, nawet gdy nie ma połączenia.

Uwagi : Każda witryna PWA wymaga wstępnego buforowania podstawowych zasobów przed udostępnieniem użytkownikowi przeglądania w trybie offline.

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

Trudno byłoby zagłębić się we wszystkie szczegóły tworzenia w pełni funkcjonalnej, działającej w trybie offline progresywnej aplikacji internetowej, dlatego dzisiaj najpierw zaczniemy od podstaw. Naszym celem jest stworzenie progresywnej aplikacji internetowej typu barebone działającej w trybie offline .

Warunki wstępne

• Zwykła strona internetowa/aplikacja internetowa. Wszystko z jednym index.html , jednym index.js i jednym style.css zrobi.

Gdy masz już wszystkie wymagania wstępne, nadszedł czas, aby Twój barebone PWA działał w trybie offline!

Tworzenie podstawowego pracownika serwisu

Najpierw musisz stworzyć swój sw.js , który zawiera cały niezbędny kod dla funkcjonalnego service workera.

 // sw.js
self.addEventListener("pobierz", zdarzenie => {
    console.log("Pobrałeś " + event.url);
});

Po utworzeniu Service Workera sprawdźmy, czy Twoja przeglądarka go obsługuje i odnieś się do niego w swoim index.js :

 // index.js
if ("serviceWorker" w nawigatorze) {
    nawigator.serviceWorker
        .register("sw.js")
        .then(() => console.log("zarejestrowany pracownik serwisu!"));
}
// reszta kodu strony...

Powyższy kod powinien być dość prosty. Sprawdza, czy Twoja przeglądarka obsługuje pracowników serwisu, a jeśli tak, zwraca „ zarejestrowanego pracownika serwisu! ”. Rejestrując pracowników usług, zasadniczo mówisz przeglądarce, aby używała sw.js jako instrukcji dla pracowników usług, co z kolei wiąże nowych pracowników usług z Twoją witryną.

Teraz wróć do sw.js , dodaj następujący kod:

 // sw.js
self.addEventListener("pobierz", zdarzenie => {
    console.log("Pobrałeś " + event.url);
});

Kod dodaje EventListener , który jest niezbędny do dalszego działania. W rzeczywistości wiele przeglądarek, w tym Chrome, nie pozwala na zainstalowanie PWA, chyba że zarejestrowany jest odbiornik fetch .

addEventListener w powyższym kodzie ma dwa argumenty: zdarzenia, które mają być nasłuchiwane oraz wywołanie zwrotne, które przyjmuje obiekt zdarzenia. Gdy to zdarzenie zostanie uruchomione, Twój Service Worker zacznie teraz nasłuchiwać zdarzeń fetch , które obejmują żądania dotyczące kodu HTML, CSS, JS, audio, obrazów i wszelkich innych żądań Twojej witryny do interfejsów API/innych witryn internetowych.

Buforowanie zasobów

Aby Twoja aplikacja PWA działała w trybie offline, pracownicy usług biorą udział w udostępnianiu treści , ale musisz także buforować zasoby swojej strony.

Aby buforować zasoby swojej strony, najpierw musisz zaplanować rozmiar pamięci podręcznej, ponieważ jest to limit.

Limit pamięci podręcznej

Każda przeglądarka ma inny sposób obsługi pamięci podręcznej. Prawie wszystkie z nich mają jednak limit rozmiaru pamięci podręcznej — ten limit jest często powodem, dla którego nie widzisz dużych i otyłych witryn, takich jak Amazon, buforuje cały swój sklep za pomocą pracowników usług.

Teraz ten limit jest różny, ponieważ jest zależny od urządzenia użytkownika końcowego; ale normalnie powinno to być około 20% maksymalnej przestrzeni dyskowej użytkownika. Więcej informacji można znaleźć w poniższej tabeli lub w oficjalnym przewodniku Google dotyczącym pamięci masowej offline dla progresywnych aplikacji internetowych.

Teraz, gdy już usunęliśmy ten limit pamięci podręcznej, przejdźmy do faktycznego buforowania zasobów .

Aby buforować zasoby Twojej strony, potrzebujemy globalnej tablicy, która zawiera wszystkie zasoby, które chcemy przechowywać:

 /* 
  To wszystko, co chcemy zapisać w pamięci podręcznej.
  Aby aplikacja działała w trybie offline/była instalowana,
  musimy zapisywać nie tylko obrazy, ale nasz kod HTML, JS i CSS
  także - wszystko, czego chcemy używać w trybie offline.
*/
const AKTYWA = [
    "https://i.imgur.com/Kbkqr2n.png",
    "https://i.imgur.com/lgLaG0x.png",
    "https://i.imgur.com/0iL8mxP.png",
    "https://i.imgur.com/KDsdYeS.png",
    "https://i.imgur.com/mK50fqL.png",
    "https://i.imgur.com/KYGH2Qa.png",
    "/styl.css",
    "/indeks.html",
    "/offline.html",
    „/”
];

Tutaj przechowywane jest wszystko, z czego chcesz korzystać w trybie offline. W powyższym przykładzie kilka pierwszych obrazów to ścieżki do Imgur, w których przechowywane są różne logo SimiCart.

W tym kroku nasza lista niezbędnych zasobów do użytku w trybie offline jest już gotowa. Zbuforujmy je za pomocą pracowników usług.

Dodaj tę górę u góry swojego pliku sw.js:

 // sw.js

let cache_name = "SimiCart"; // Ciąg używany do identyfikacji naszej pamięci podręcznej

self.addEventListener("zainstaluj", zdarzenie => {
    console.log("instalowanie...");
    event.waitUntil(
        skrytki
            .open(nazwa_cache)
            .następnie(pamięć podręczna => {
                return cache.addAll(assets);
            })
            .catch(err => console.log(err))
    );
});

Zasadniczo ten kod instruuje przeglądarkę, aby czekała (za pomocą waitUntil() ) na nasze buforowanie.

Korzystając z interfejsu API pamięci podręcznej, a konkretnie metody addAll() , nasza tablica zasobów może być bezproblemowo dodawana do pamięci podręcznej, gotowa do obsługi przez pracowników usług. Cóż, po namyśle, to nie jest gotowe. Nadal musielibyśmy nieco zmodyfikować nasz program obsługi zdarzeń fetch .

Tak będzie teraz wyglądać:

 self.addEventListener("pobierz", zdarzenie => {
    if (event.request.url === "https://www.simicart.com/") {
        // lub jakikolwiek adres URL Twojej aplikacji
        zdarzenie.odpowiedźZ(
            fetch(event.request).catch(err =>
                self.cache.open(cache_name).then(cache => cache.match("/offline.html"))
            )
        );
    } w przeciwnym razie {
        zdarzenie.odpowiedźZ(
            fetch(event.request).catch(err =>
                caches.match(event.request).then(odpowiedź => odpowiedź)
            )
        );
    }
});

W powyższym kodzie powinno być teraz jasne, że próbujemy buforować zasoby, nawet gdy aplikacja jest w trybie offline. Logika jest następująca:

• Najpierw aplikacja próbuje uzyskać dostęp do zasobów w trybie online i odpowiadać za pomocą zasobów z pamięci podręcznej, jeśli to pobieranie nie powiedzie się (przy użyciu funkcji respondWith() ).
• W funkcji respondWith() wywołujemy fetch(event.request) , aby spróbować pobrać zasoby z sieci, a ponieważ pobieranie jest oparte na Promise , Promise odrzuci, jeśli nie uda się połączyć z siecią, co z kolei spowoduje uruchomienie catch() oświadczenie.
• W instrukcji catch() jest miejsce, w którym chcesz wywołać swoje buforowane zasoby.

I to wszystko. Twoje PWA powinno teraz działać w trybie offline! Całkiem proste, prawda?

Wniosek

W świecie technologii sprawy toczą się dość szybko i im dłużej czekasz na konwersję na PWA lub zintegrowanie ważnej funkcji, takiej jak funkcje offline z PWA, tym większy koszt alternatywny dla Ciebie i Twojej firmy.

Mimo to zawsze są łatwo dostępni dostawcy rozwiązań, tacy jak SimiCart, którzy mogą zająć się każdą Twoją potrzebą. Jeśli przypadkiem jesteś sprzedawcą internetowym i szukasz wszechstronnego idealnego rozwiązania Magento PWA , jesteś we właściwym miejscu. Jesteśmy znanym dostawcą rozwiązań dla witryn Magento eCommerce z ponad 5-letnim doświadczeniem w PWA i aplikacjach natywnych.