Aktif

Aspek utama dari Progressive Web App adalah bahwa mereka dapat diandalkan; mereka dapat memuat aset dengan cepat, membuat pengguna tetap berinteraksi dan memberikan masukan dengan segera, bahkan dalam kondisi jaringan yang buruk. Bagaimana mungkin? Berkat peristiwa fetch pekerja layanan.

Peristiwa pengambilan

Peristiwa fetch memungkinkan kita mencegat setiap permintaan jaringan yang dibuat oleh PWA dalam cakupan pekerja layanan, untuk permintaan origin yang sama dan lintas origin. Selain navigasi dan permintaan aset, pengambilan dari pekerja layanan yang terinstal memungkinkan kunjungan halaman setelah pemuatan pertama situs dirender tanpa panggilan jaringan.

Pengendali fetch menerima semua permintaan dari aplikasi, termasuk URL dan header HTTP, dan memungkinkan developer aplikasi memutuskan cara memprosesnya.

Pekerja layanan Anda dapat meneruskan permintaan ke jaringan, merespons dengan respons yang di-cache sebelumnya, atau membuat respons baru. Anda yang menentukan. Berikut adalah contoh sederhana:

self.addEventListener("fetch", event => {
    console.log(`URL requested: ${event.request.url}`);
});

Merespons permintaan

Ketika permintaan masuk ke pekerja layanan, ada dua hal yang bisa Anda lakukan; Anda dapat mengabaikannya, yang memungkinkannya masuk ke jaringan, atau Anda dapat menanggapinya. Merespons permintaan dari dalam pekerja layanan merupakan cara untuk memilih apa, dan bagaimana hal tersebut dikembalikan ke PWA Anda, bahkan saat pengguna sedang offline.

Untuk merespons permintaan masuk, panggil event.respondWith() dari dalam pengendali peristiwa fetch, seperti ini:

// fetch event handler in your service worker file
self.addEventListener("fetch", event => {
    const response = .... // a response or a Promise of response
    event.respondWith(response);
});

Anda harus memanggil respondWith() secara sinkron dan harus menampilkan objek Response. Namun, Anda tidak dapat memanggil respondWith() setelah pengendali peristiwa pengambilan selesai, seperti dalam panggilan asinkron. Jika perlu menunggu respons lengkap, Anda dapat meneruskan Promise ke respondWith() yang di-resolve dengan Respons.

Membuat respons

Berkat Fetch API, Anda dapat membuat respons HTTP dalam kode JavaScript Anda, dan respons tersebut dapat disimpan dalam cache menggunakan Cache Storage API dan ditampilkan seolah-olah berasal dari server web.

Untuk membuat respons, buat objek Response baru, dengan menetapkan isi dan opsinya seperti status dan header:

const simpleResponse = new Response("Body of the HTTP response");

const options = {
   status: 200,
   headers: {
    'Content-type': 'text/html'
   }
};
const htmlResponse = new Response("<b>HTML</b> content", options)

Merespons dari cache

Sekarang Anda tahu cara menyajikan respons HTTP dari pekerja layanan, Sekarang saatnya menggunakan antarmuka Penyimpanan Cache untuk menyimpan aset di perangkat.

Anda dapat menggunakan cache storage API untuk memeriksa apakah permintaan yang diterima dari PWA tersedia di cache, dan jika ya, merespons respondWith() dengannya. Untuk melakukannya, Anda harus melakukan penelusuran di dalam cache terlebih dahulu. Fungsi match(), yang tersedia di antarmuka caches tingkat teratas menelusuri semua penyimpanan di asal Anda, atau pada satu objek cache terbuka.

Fungsi match() menerima permintaan HTTP atau URL sebagai argumen dan menampilkan promise yang di-resolve dengan Respons yang terkait dengan kunci yang sesuai.

// Global search on all caches in the current origin
caches.match(urlOrRequest).then(response => {
   console.log(response ? response : "It's not in the cache");
});

// Cache-specific search
caches.open("pwa-assets").then(cache => {
  cache.match(urlOrRequest).then(response => {
    console.log(response ? response : "It's not in the cache");
  });
});

Strategi penyimpanan dalam cache

Hanya menyajikan file dari cache browser tidak sesuai untuk setiap kasus penggunaan. Misalnya, pengguna atau browser dapat menghapus cache. Itulah sebabnya Anda harus menentukan strategi sendiri dalam mengirimkan aset untuk PWA Anda. Anda tidak dibatasi pada satu strategi penyimpanan dalam cache. Anda dapat menentukan URL yang berbeda untuk pola URL yang berbeda. Misalnya, Anda dapat memiliki satu strategi untuk aset UI minimum, strategi lain untuk panggilan API, dan strategi ketiga untuk URL gambar dan data. Untuk melakukannya, baca event.request.url di ServiceWorkerGlobalScope.onfetch dan uraikan melalui ekspresi reguler atau Pola URL. (Pada saat penulisan, Pola URL tidak didukung di semua platform).

Strategi yang paling umum adalah:

Cache Terlebih Dahulu

Mencari respons yang di-cache terlebih dahulu dan melakukan fallback ke jaringan jika tidak ditemukan.

Jaringan di Depan

Meminta respons dari jaringan terlebih dahulu dan jika tidak ada respons yang ditampilkan, memeriksa respons di cache.

Tidak Berlaku Saat Validasi Ulang

Mengirimkan respons dari cache, sementara di latar belakang meminta versi terbaru dan menyimpannya ke cache saat berikutnya aset diminta.

Khusus Jaringan

Selalu membalas dengan respons dari jaringan atau menampilkan error. Cache tidak pernah dimintai masukannya.

Hanya Cache

Selalu membalas dengan respons dari cache atau error yang keluar. Jaringan tidak akan dimintai pendapatnya. Aset yang akan ditayangkan menggunakan strategi ini harus ditambahkan ke cache sebelum diminta.

Cache terlebih dahulu

Dengan menggunakan strategi ini, pekerja layanan akan mencari permintaan yang cocok dalam cache dan menampilkan Respons yang sesuai jika di-cache. Jika tidak, metode ini akan mengambil respons dari jaringan (secara opsional, memperbarui cache untuk panggilan di masa mendatang). Jika tidak ada respons cache atau respons jaringan, permintaan akan mengalami error. Karena menayangkan aset tanpa membuka jaringan cenderung lebih cepat, strategi ini lebih memprioritaskan performa daripada keaktualan.

self.addEventListener("fetch", event => {
   event.respondWith(
     caches.match(event.request)
     .then(cachedResponse => {
       // It can update the cache to serve updated content on the next request
         return cachedResponse || fetch(event.request);
     }
   )
  )
});

Mengutamakan jaringan

Strategi ini merupakan duplikat dari strategi Cache First; {i>router<i} memeriksa apakah permintaan dapat dipenuhi dari jaringan dan, jika tidak bisa, mencoba mengambilnya dari {i>cache<i}. Seperti {i>cache<i} terlebih dahulu. Jika tidak ada respons jaringan atau respons cache, permintaan akan mengalami error. Mendapatkan respons dari jaringan biasanya lebih lambat daripada mendapatkannya dari cache, strategi ini akan memprioritaskan konten yang telah diperbarui daripada performa.

self.addEventListener("fetch", event => {
   event.respondWith(
     fetch(event.request)
     .catch(error => {
       return caches.match(event.request) ;
     })
   );
});

Tidak berlaku saat memvalidasi ulang

Strategi yang sudah tidak berlaku saat validasi ulang menampilkan respons yang di-cache, lalu memeriksa update pada jaringan, menggantikan respons yang di-cache jika ditemukan. Strategi ini selalu membuat permintaan jaringan, karena meskipun resource yang di-cache ditemukan, strategi ini akan mencoba mengupdate apa yang ada di cache dengan apa yang diterima dari jaringan, untuk menggunakan versi yang diupdate dalam permintaan berikutnya. Oleh karena itu, strategi ini memberikan cara bagi Anda untuk mendapatkan manfaat dari penayangan cepat strategi cache terlebih dahulu dan mengupdate cache di latar belakang.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cachedResponse => {
        const networkFetch = fetch(event.request).then(response => {
          // update the cache with a clone of the network response
          const responseClone = response.clone()
          caches.open(url.searchParams.get('name')).then(cache => {
            cache.put(event.request, responseClone)
          })
          return response
        }).catch(function (reason) {
          console.error('ServiceWorker fetch failed: ', reason)
        })
        // prioritize cached response over network
        return cachedResponse || networkFetch
      }
    )
  )
})

Khusus jaringan

Strategi khusus jaringan ini mirip dengan perilaku browser tanpa pekerja layanan atau Cache Storage API. Permintaan hanya akan menampilkan resource jika dapat diambil dari jaringan. Hal ini sering kali berguna untuk resource seperti permintaan API khusus online.

Cache saja

Strategi khusus cache memastikan bahwa permintaan tidak pernah masuk ke jaringan; semua permintaan masuk akan direspons dengan item cache yang telah diisi sebelumnya. Kode berikut menggunakan pengendali peristiwa fetch dengan metode match penyimpanan cache untuk hanya merespons cache:

self.addEventListener("fetch", event => {
   event.respondWith(caches.match(event.request));
});

Strategi kustom

Meskipun hal di atas adalah strategi penyimpanan dalam cache yang umum, Anda dapat mengontrol pekerja layanan dan cara menangani permintaan. Jika tidak ada yang sesuai dengan kebutuhan Anda, buat sendiri.

Misalnya, Anda dapat menggunakan strategi yang mengutamakan jaringan dengan waktu tunggu untuk memprioritaskan konten yang diperbarui, tetapi hanya jika respons muncul dalam batas yang Anda tetapkan. Anda juga bisa menggabungkan respons yang di-cache dengan respons jaringan dan membangun respons kompleks dari pekerja layanan.

Memperbarui aset

Memastikan aset yang di-cache PWA Anda selalu terbaru bisa menjadi tantangan tersendiri. Meskipun strategi yang usang saat memvalidasi ulang adalah salah satu cara untuk melakukannya, itu bukan satu-satunya. Dalam bab Update, Anda akan mempelajari berbagai teknik untuk terus mengupdate konten dan aset aplikasi.

Resource

• Mengambil peristiwa di MDN
• Buku Resep Offline
• Kecocokan Cache di MDN