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

Dukungan Browser

• 40
• 17
• 44
• 11,1

Sumber

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}`);
});

Perhatian: Meskipun Anda dapat memiliki lebih dari satu pengendali peristiwa pengambilan per pekerja layanan, hanya satu pengendali yang dapat merespons per permintaan. Misalnya, Anda dapat memiliki pengendali berbeda yang akan bertindak pada pola URL yang berbeda. Panggilan tersebut dijalankan sesuai urutan pendaftarannya hingga salah satu darinya memanggil respondWith().

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)

Peringatan: Berhati-hatilah saat membuat respons dengan kode yang berisi bug pekerja layanan dapat menyebabkan kasus ekstrem dan masalah sulit di-debug, seperti browser tidak dapat memuat dokumen HTML yang merender PWA Anda. Saat melakukan debug, Anda selalu dapat menggunakan tombol muat ulang browser dengan menekan tombol Shift, yang akan mengabaikan pekerja layanan; atau gunakan pekerja layanan devtools di browser yang didukung seperti yang akan kita lihat di Alat dan Debug.

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");
  });
});

Jika menggunakan match() dengan respondWith(), promise yang cocok akan di-resolve dengan item yang ditemukan atau tanpa apa pun. Fitur ini hanya akan menolak jika ada masalah yang mencegah selesainya operasi penelusuran. Untuk menampilkan error jika tidak ada hasil yang ditemukan, Anda harus memeriksa hasilnya sebelum menampilkan respons ke respondWith().

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.

Catatan: Perlu diingat bahwa antarmuka penyimpanan cache tidak akan menampilkan objek Response. Referensinya akan menjadi undefined, jika permintaan tidak di-cache.

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.

Catatan: Dengan strategi ini, aset diperbarui di latar belakang. Artinya pengguna Anda tidak akan mendapatkan versi aset baru hingga jalur tersebut diminta lagi. Pada saat itu, strategi tersebut akan memeriksa kembali apakah versi baru sudah ada dan siklusnya berulang.

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
      }
    )
  )
})

Perhatian: Isi Respons adalah ReadableStream yang hanya dapat digunakan satu kali. Artinya, jika Anda memanggil fetch() untuk mengirimkan respons ke PWA karena aset tidak di-cache, Anda tidak dapat menggunakan kembali respons yang sama untuk memperbaruinya dalam cache. Anda perlu memanggil Response.clone() untuk menggunakannya dua kali.

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));
});

Catatan: Dengan strategi cache saja, Anda meng-cache aset sebelum membutuhkannya, biasanya di pengendali peristiwa install pekerja layanan. Karena strategi ini tidak pernah masuk ke jaringan, aset ini hanya akan diperbarui saat Anda mengupdate pekerja layanan dan peristiwa install baru diaktifkan.

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