Blazor ASP.NET Core Progressive Web Application (PWA)

Blazor Aplikasi Web Progresif (PWA) adalah aplikasi satu halaman (SPA) yang menggunakan API browser modern dan kemampuan untuk berulah seperti aplikasi desktop.

Blazor WebAssembly adalah platform aplikasi web sisi klien berbasis standar, sehingga dapat menggunakan API browser apa pun, termasuk API PWA yang diperlukan untuk kemampuan berikut:

• Bekerja offline dan memuat secara instan, terlepas dari kecepatan jaringan.
• Berjalan di jendela aplikasinya sendiri, bukan hanya jendela browser.
• Diluncurkan dari menu start sistem operasi host, dock, atau layar utama.
• Menerima pemberitahuan push dari server backend, bahkan saat pengguna tidak menggunakan aplikasi.
• Memperbarui secara otomatis di latar belakang.

Kata progresif digunakan untuk menjelaskan aplikasi ini karena:

• Pengguna mungkin terlebih dahulu menemukan dan menggunakan aplikasi dalam browser web mereka seperti SPA lainnya.
• Kemudian, pengguna berkembang untuk menginstalnya di OS mereka dan mengaktifkan pemberitahuan push.

Membuat proyek dari templat PWA

Visual Studio

Saat membuat AplikasiBlazor WebAssembly, pilih kotak centang Aplikasi Web Progresif.

Visual Studio Code / .NET CLI

Gunakan perintah berikut untuk membuat proyek PWA di shell perintah dengan sakelar --pwa :

dotnet new blazorwasm -o MyBlazorPwa --pwa

Dalam perintah sebelumnya, -o|--output opsi membuat folder baru untuk aplikasi bernama MyBlazorPwa.

Mengonversi aplikasi yang ada Blazor WebAssembly menjadi PWA

Konversikan aplikasi yang ada Blazor WebAssembly menjadi PWA dengan mengikuti panduan di bagian ini.

Dalam file proyek aplikasi:

• Tambahkan properti berikut ServiceWorkerAssetsManifest ke PropertyGroup:

    ...
    <ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>
  </PropertyGroup>
  

• Tambahkan item berikut ServiceWorker ke ItemGroup:

  <ItemGroup>
    <ServiceWorker Include="wwwroot\service-worker.js" 
      PublishedContent="wwwroot\service-worker.published.js" />
  </ItemGroup>
  

Untuk mendapatkan aset statis, gunakan salah satu pendekatan berikut:

• Buat proyek PWA baru yang terpisah dengan perintah dotnet new dalam jendela perintah:

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  Dalam perintah sebelumnya, -o|--output opsi membuat folder baru untuk aplikasi bernama MyBlazorPwa.

  Jika Anda tidak mengonversi aplikasi untuk versi rilis terbaru, gunakan opsi -f|--framework. Contoh berikut membuat aplikasi untuk .NET 5:

  dotnet new blazorwasm -o MyBlazorPwa --pwa -f net5.0
  

• Masuk ke repositori GitHub ASP.NET Core di URL berikut, yang menuju ke main sumber referensi cabang dan aset. Pilih rilis yang sedang Anda kerjakan dari daftar tarik-turun Beralih Cabang atau Tag yang berlaku untuk aplikasi Anda.

  Blazor WebAssembly folder template wwwroot proyek (dotnet/aspnetcore cabang repositori main GitHub)

  Nota

  Tautan dokumentasi ke sumber referensi .NET biasanya memuat cabang default repositori, yang mewakili pengembangan saat ini untuk rilis .NET berikutnya. Untuk memilih tag untuk rilis tertentu, gunakan menu dropdown Ganti cabang atau tag. Untuk informasi lebih lanjut, lihat Cara memilih tag versi kode sumber ASP.NET Core (dotnet/AspNetCore.Docs #26205).

  Dari folder sumber wwwroot baik di aplikasi yang Anda buat atau dari aset referensi di dotnet/aspnetcore repositori GitHub, salin file berikut ke folder aplikasi wwwroot :

  • icon-192.png
  • icon-512.png
  • manifest.webmanifest
  • service-worker.js
  • service-worker.published.js

Di file aplikasi wwwroot/index.html :

• Tambahkan <link> elemen untuk ikon manifes dan aplikasi:

  <link href="manifest.webmanifest" rel="manifest" />
  <link rel="apple-touch-icon" sizes="512x512" href="icon-512.png" />
  <link rel="apple-touch-icon" sizes="192x192" href="icon-192.png" />
  

• Tambahkan JavaScript berikut di dalam tag penutup </body> segera setelah blazor.webassembly.js tag skrip:

  <script>
    navigator.serviceWorker.register('service-worker.js', { updateViaCache: 'none' });
  </script>
  

  OpsiupdateViaCache: 'none' memastikan bahwa:

  • Browser tidak menggunakan versi cache skrip pekerja layanan.
  • Update service worker diterapkan dengan andal tanpa diblokir oleh caching HTTP.
  • Aplikasi PWA dapat memperbarui pekerja layanan mereka dengan lebih terprediksi.

  Ini mengatasi masalah caching yang dapat mencegah pembaruan service worker diterapkan dengan benar, yang sangat penting untuk PWAs yang mengandalkan service worker untuk fungsionalitas offline.

Penginstalan dan manifes aplikasi

Saat mengunjungi aplikasi yang dibuat menggunakan templat PWA, pengguna memiliki opsi untuk menginstal aplikasi ke menu mulai, dok, atau layar beranda OS mereka. Cara opsi ini disajikan tergantung pada browser pengguna. Saat menggunakan browser berbasis desktop Chromium, seperti Edge atau Chrome, tombol Tambahkan muncul di dalam bilah URL. Setelah pengguna memilih tombol Tambahkan , mereka menerima dialog konfirmasi:

Di iOS, pengunjung dapat menginstal PWA menggunakan tombol Bagikan Safari dan opsi Tambahkan ke Layar Beranda. Di Chrome untuk Android, pengguna harus memilih tombol Menu di sudut kanan atas, diikuti dengan layar Tambahkan keHome.

Setelah diinstal, aplikasi muncul di jendelanya sendiri tanpa bilah alamat:

Untuk mengkustomisasi judul jendela, skema warna, ikon, atau detail lainnya, lihat manifest.json file di direktori proyek wwwroot . Skema file ini ditentukan oleh standar web. Untuk informasi selengkapnya, lihat dokumen web MDN: Manifest Aplikasi Web.

Dukungan offline

Aplikasi yang dibuat menggunakan opsi templat PWA memiliki dukungan untuk berjalan offline. Pengguna harus terlebih dahulu mengunjungi aplikasi saat mereka online. Browser secara otomatis mengunduh dan menyimpan semua sumber daya yang diperlukan untuk beroperasi secara offline.

Penting

Dukungan pengembangan akan mengganggu siklus pengembangan yang biasa dalam membuat perubahan dan mengujinya. Oleh karena itu, dukungan offline hanya diaktifkan untuk aplikasi yang diterbitkan .

Peringatan

Jika Anda berniat mendistribusikan PWA yang bisa digunakan secara offline, ada beberapa peringatan dan peringatan khusus. Skenario ini melekat pada PWAs offline dan tidak spesifik untuk Blazor. Pastikan untuk membaca dan memahami peringatan ini sebelum membuat asumsi tentang cara kerja aplikasi berkemampuan offline Anda.

Untuk melihat cara kerja dukungan offline:

1. Terbitkan aplikasi. Untuk informasi selengkapnya, lihat Host dan sebarkan ASP.NET Core Blazor.

2. Sebarkan aplikasi ke server yang mendukung HTTPS, dan akses aplikasi di browser di alamat HTTPS amannya.

3. Buka alat pengembang browser dan verifikasi bahwa Service Worker terdaftar untuk host pada tab Aplikasi :

   

4. Muat ulang halaman dan periksa tab Jaringan . Service Worker atau cache memori terdaftar sebagai sumber untuk semua aset halaman:

   

5. Untuk memverifikasi bahwa browser tidak bergantung pada akses jaringan untuk memuat aplikasi, Anda bisa:

   • Matikan server web dan lihat bagaimana aplikasi terus berfungsi secara normal, yang mencakup muatan ulang halaman. Demikian juga, aplikasi terus berfungsi secara normal ketika ada koneksi jaringan yang lambat.
   • Instruksikan browser untuk mensimulasikan mode offline di tab Jaringan :

   

Dukungan offline menggunakan pekerja layanan adalah standar web, tidak khusus untuk Blazor. Untuk informasi selengkapnya tentang pekerja layanan, lihat dokumen web MDN: API Pekerja Layanan. Untuk mempelajari selengkapnya tentang pola penggunaan umum untuk pekerja layanan, lihat Google Web: Siklus Hidup Pekerja Layanan.

BlazorTemplat PWA menghasilkan dua file pekerja layanan:

• wwwroot/service-worker.js, yang digunakan selama proses pengembangan.
• wwwroot/service-worker.published.js, yang digunakan setelah aplikasi diterbitkan.

Untuk berbagi logika antara dua file pekerja layanan, pertimbangkan pendekatan berikut:

• Tambahkan file JavaScript ketiga untuk menyimpan logika umum.
• Gunakan self.importScripts untuk memuat logika umum ke dalam kedua file service worker.

Strategi pemanggilan cache-first

Pekerja layanan bawaan service-worker.published.js menyelesaikan permintaan menggunakan strategi cache-first . Ini berarti bahwa pekerja layanan lebih suka mengembalikan konten yang di-cache, terlepas dari apakah pengguna memiliki akses jaringan atau konten yang lebih baru tersedia di server.

Strategi cache-first sangat berharga karena:

• Ini memastikan keandalan. Akses jaringan tidak dalam keadaan boolean. Pengguna tidak hanya online atau offline:

  • Perangkat pengguna mungkin menganggapnya online, tetapi jaringan mungkin sangat lambat sehingga tidak praktis untuk menunggu.
  • Jaringan mungkin mengembalikan hasil yang tidak valid untuk URL tertentu, misalnya ketika ada portal Wi-Fi penguncian yang sedang memblokir atau mengalihkan permintaan tertentu.

  Inilah sebabnya mengapa API browser navigator.onLine tidak dapat diandalkan dan tidak boleh diandalkan.

• Ini memastikan kebenaran. Saat membangun cache sumber daya offline, *service worker* menggunakan metode hashing konten untuk memastikan bahwa ia telah mengambil cuplikan sumber daya yang lengkap dan konsisten pada satu titik waktu. Cache ini kemudian digunakan sebagai unit atom. Tidak ada gunanya meminta jaringan untuk sumber daya yang lebih baru, karena satu-satunya versi yang diperlukan adalah yang sudah di-cache. Hal lain berisiko inkonsistensi dan ketidakcocokan (misalnya, mencoba menggunakan versi rakitan .NET yang tidak dikompilasi bersama-sama).

Untuk mencegah browser mengunduh service-worker-assets.js dari cache HTTP-nya, misalnya untuk mengatasi kegagalan pemeriksaan integritas sementara saat mendeploy versi baru service worker, pendaftaran service worker di wwwroot/index.html menggunakan updateViaCache diatur ke none.

<script>
  navigator.serviceWorker.register('/service-worker.js', { updateViaCache: 'none' });
</script>

OpsiupdateViaCache: 'none' memastikan bahwa:

• Browser tidak menggunakan versi cache skrip pekerja layanan.
• Update service worker diterapkan dengan andal tanpa diblokir oleh caching HTTP.
• Aplikasi PWA dapat memperbarui pekerja layanan mereka dengan lebih terprediksi.

Ini mengatasi masalah caching yang dapat mencegah pembaruan service worker diterapkan dengan benar, yang sangat penting untuk PWAs yang mengandalkan service worker untuk fungsionalitas offline.

Pembaruan latar belakang

Sebagai model mental, Anda dapat membayangkan PWA offline-first berperilaku seperti aplikasi seluler yang dapat diinstal. Aplikasi ini langsung aktif terlepas dari konektivitas jaringan, tetapi logika operasional aplikasi yang telah diinstal berasal dari cuplikan sewaktu-waktu yang mungkin bukan versi terbaru.

Templat Blazor PWA menghasilkan aplikasi yang secara otomatis mencoba memperbarui diri mereka sendiri di latar belakang setiap kali pengguna mengunjungi dan memiliki koneksi jaringan yang berfungsi. Cara kerjanya adalah sebagai berikut:

• Selama kompilasi, proyek menghasilkan manifes aset pekerja layanan, yang diberi nama service-worker-assets.js. Manifes mencantumkan semua sumber daya statis yang diperlukan aplikasi untuk berfungsi offline, seperti rakitan .NET, file JavaScript, dan CSS, termasuk hash kontennya. Daftar sumber daya dimuat oleh pekerja layanan sehingga tahu sumber daya mana yang akan di-cache.
• Setiap kali pengguna mengunjungi aplikasi, browser meminta ulang service-worker.js dan service-worker-assets.js di latar belakang. File-file dibandingkan byte-for-byte dengan service worker yang sudah terinstal. Jika server mengembalikan konten yang diubah untuk salah satu file ini, pekerja layanan mencoba menginstal versi baru itu sendiri.
• Saat menginstal versi baru itu sendiri, pekerja layanan membuat cache baru yang terpisah untuk sumber daya offline dan mulai mengisi cache dengan sumber daya yang tercantum di service-worker-assets.js. Logika ini diimplementasikan dalam fungsi di onInstall dalam service-worker.published.js.
• Proses berhasil diselesaikan ketika semua sumber daya dimuat tanpa kesalahan dan semua hash konten cocok. Jika berhasil, pekerja layanan baru memasuki status menunggu aktivasi . Segera setelah pengguna menutup aplikasi (tidak ada tab aplikasi atau jendela yang tersisa), pekerja layanan baru menjadi aktif dan digunakan untuk kunjungan aplikasi berikutnya. Pekerja layanan lama dan cache-nya dihapus.
• Jika proses tidak berhasil diselesaikan, instans pekerja layanan baru akan dibuang. Proses pembaruan dicoba lagi pada kunjungan pengguna berikutnya, ketika mudah-mudahan klien memiliki koneksi jaringan yang lebih baik yang dapat menyelesaikan permintaan.

Sesuaikan proses ini dengan mengedit logika pekerja layanan. Tidak ada perilaku sebelumnya yang spesifik terhadap Blazor tetapi hanya merupakan pengalaman default yang disediakan oleh opsi templat PWA. Untuk informasi selengkapnya, lihat dokumen web MDN: API Service Worker.

Bagaimana permintaan diselesaikan

Seperti yang dijelaskan di bagian Strategi pengambilan cache-first, pekerja layanan default menggunakan strategi pengambilan cache-first, yang berarti mencoba menyajikan konten cache saat tersedia. Jika tidak ada konten yang di-cache untuk URL tertentu, misalnya saat meminta data dari API backend, pekerja layanan kembali pada permintaan jaringan biasa. Permintaan jaringan berhasil jika server dapat dijangkau. Logika ini diimplementasikan di dalam onFetch fungsi dalam service-worker.published.js.

Jika komponen aplikasi Razor mengandalkan permintaan data dari API backend dan Anda ingin memberikan pengalaman pengguna yang ramah untuk permintaan yang gagal karena tidak tersedianya jaringan, terapkan logika dalam komponen aplikasi. Misalnya, gunakan try/catch sekeliling HttpClient permintaan.

Mendukung halaman yang dirender oleh server

Pertimbangkan apa yang terjadi saat pengguna pertama kali menavigasi ke URL seperti /counter atau tautan mendalam lainnya di aplikasi. Dalam kasus ini, Anda tidak ingin mengembalikan konten yang di-cache sebagai /counter, tetapi sebaliknya memerlukan browser untuk memuat konten yang di-cache /index.html untuk memulai aplikasi Anda Blazor WebAssembly . Permintaan awal ini dikenal sebagai permintaan navigasi , dibandingkan dengan:

• subresource permintaan untuk gambar, lembar gaya, atau file lainnya.
• fetch/XHR permintaan untuk data API.

Pekerja layanan default berisi logika kasus khusus untuk permintaan navigasi. Pekerja layanan menyelesaikan permintaan dengan mengembalikan konten yang di-cache untuk /index.html, terlepas dari URL yang diminta. Logika ini diimplementasikan dalam fungsi di onFetch dalam service-worker.published.js.

Jika aplikasi Anda memiliki URL tertentu yang harus mengembalikan HTML yang dirender oleh server, dan tidak mengambil dari cache, maka Anda perlu mengedit logika di service worker Anda. Jika semua URL yang berisi /Identity/ perlu ditangani sebagai permintaan reguler online-saja ke server, maka ubah logika service-worker.published.jsonFetch. Temukan kode berikut:

const shouldServeIndexHtml = event.request.mode === 'navigate';

Ubah kode menjadi berikut:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/');

Jika Anda tidak melakukan ini, maka terlepas dari konektivitas jaringan, pekerja layanan mencegat permintaan UNTUK URL tersebut dan menyelesaikannya menggunakan /index.html.

Tambahkan titik akhir tambahan untuk penyedia autentikasi eksternal ke dalam proses pemeriksaan. Dalam contoh berikut, /signin-google untuk autentikasi Google ditambahkan ke pemeriksaan:

const shouldServeIndexHtml = event.request.mode === 'navigate'
  && !event.request.url.includes('/Identity/')
  && !event.request.url.includes('/signin-google');

Tidak ada tindakan yang diperlukan untuk lingkungan Development, di mana konten selalu diambil dari jaringan.

Mengontrol penyimpanan sementara aset

Jika proyek Anda mendefinisikan ServiceWorkerAssetsManifest properti MSBuild, Blazor alat pembangunan menghasilkan manifest aset pekerja layanan dengan nama yang ditentukan. Templat PWA default menghasilkan file proyek yang berisi properti berikut:

<ServiceWorkerAssetsManifest>service-worker-assets.js</ServiceWorkerAssetsManifest>

File ditempatkan di wwwroot direktori output, sehingga browser dapat mengambil file ini dengan meminta /service-worker-assets.js. Untuk melihat isi file ini, buka /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js di editor teks. Namun, jangan mengedit file, karena diregenerasi pada setiap build.

Isi dari daftar manifes:

• Sumber daya apa pun yang dikelola Blazor, seperti rakitan .NET dan file runtime .NET WebAssembly yang diperlukan agar dapat berfungsi secara offline.
• Semua sumber daya untuk diterbitkan ke direktori aplikasi wwwroot , seperti gambar, lembar gaya, dan file JavaScript, termasuk aset web statis yang disediakan oleh proyek eksternal dan paket NuGet.

Anda dapat mengontrol sumber daya mana yang diambil dan di-cache oleh pekerja layanan dengan mengedit logika di onInstallservice-worker.published.js. Pekerja layanan mengambil dan menyimpan file yang cocok dengan ekstensi nama file web umum seperti .html, , .css, .jsdan .wasm, ditambah jenis file khusus untuk Blazor WebAssembly, seperti .pdb file (semua versi) dan .dll file (ASP.NET Core di .NET 7 atau yang lebih lama).

Untuk menyertakan sumber daya tambahan yang tidak ada di direktori aplikasi wwwroot , tentukan entri MSBuild ItemGroup tambahan, seperti yang ditunjukkan dalam contoh berikut:

<ItemGroup>
  <ServiceWorkerAssetsManifestItem Include="MyDirectory\AnotherFile.json"
    RelativePath="MyDirectory\AnotherFile.json" AssetUrl="files/AnotherFile.json" />
</ItemGroup>

AssetUrl Metadata menentukan URL relatif dasar yang harus digunakan browser saat mengambil sumber daya ke cache. Ini dapat tidak tergantung pada nama file sumber aslinya di disk.

Penting

Menambah ServiceWorkerAssetsManifestItem tidak menyebabkan file diterbitkan di direktori wwwroot aplikasi. Output penerbitan harus dikontrol secara terpisah. Satu-satunya alasan ServiceWorkerAssetsManifestItem menyebabkan munculnya entri tambahan dalam manifes aset pekerja layanan.

Pemberitahuan push

Seperti PWA lainnya, Blazor WebAssembly PWA dapat menerima pemberitahuan push dari server backend. Server dapat mengirim pemberitahuan push kapan saja, bahkan ketika pengguna tidak secara aktif menggunakan aplikasi. Misalnya, pemberitahuan push dapat dikirim ketika pengguna yang berbeda melakukan tindakan yang relevan.

Peringatan untuk PWAs offline

Tidak semua aplikasi harus mencoba mendukung penggunaan offline. Dukungan offline menambahkan kompleksitas yang signifikan, meskipun tidak selalu relevan untuk kasus penggunaan yang diperlukan.

Dukungan offline biasanya hanya relevan:

• Jika penyimpanan data utama bersifat lokal ke browser. Misalnya, pendekatan ini relevan dalam aplikasi dengan UI untuk perangkat IoT yang menyimpan data di localStorage atau IndexedDB.
• Apabila aplikasi melakukan banyak pekerjaan untuk mengambil dan menyimpan data API backend yang relevan dengan setiap pengguna sehingga mereka dapat menavigasi data secara offline. Jika aplikasi harus mendukung pengeditan, sistem untuk melacak perubahan dan menyinkronkan data dengan backend harus dibuat.
• Jika tujuannya adalah untuk menjamin bahwa aplikasi segera dimuat terlepas dari kondisi jaringan. Terapkan pengalaman pengguna yang sesuai di sekitar permintaan API backend untuk menunjukkan kemajuan permintaan dan berperilaku anggun ketika permintaan gagal karena tidak tersedianya jaringan.

Selain itu, PWA berkemampuan offline harus berurusan dengan berbagai komplikasi tambahan. Pengembang harus dengan hati-hati membiasakan diri dengan peringatan di bagian berikut.

Dukungan offline hanya ketika diterbitkan

Selama pengembangan, Anda biasanya ingin melihat setiap perubahan tercermin segera di browser tanpa melalui proses pembaruan latar belakang. Oleh karena itu, Blazortemplat PWA memungkinkan dukungan offline hanya saat diterbitkan.

Saat membangun aplikasi berkemampuan offline, tidak cukup untuk menguji aplikasi di Development lingkungan. Anda harus menguji aplikasi dalam status diterbitkan untuk memahami bagaimana aplikasi merespons kondisi jaringan yang berbeda.

Penyelesaian pembaruan setelah pengguna keluar dari aplikasi

Pembaruan tidak selesai sampai pengguna keluar dari aplikasi di semua tab. Seperti yang dijelaskan di bagian Pembaruan Latar Belakang, setelah Anda menyebarkan pembaruan ke aplikasi, browser mengunduh file pekerja layanan (service worker) yang diperbarui untuk memulai proses pembaruan.

Yang mengejutkan banyak pengembang adalah, bahkan ketika pembaruan ini selesai, itu tidak berpengaruh sampai pengguna telah berpindah dari semua tab. Tidak cukup untuk me-refresh tab yang menampilkan aplikasi, meskipun itu adalah satu-satunya tab yang menampilkan aplikasi. Hingga aplikasi Anda benar-benar ditutup, pekerja layanan baru akan tetap berstatus menunggu untuk diaktifkan. Ini tidak spesifik untuk Blazor, melainkan merupakan perilaku platform web standar.

Ini biasanya merepotkan pengembang yang mencoba menguji pembaruan untuk pekerja layanan mereka atau sumber daya cache offline. Jika Anda memeriksa alat pengembang browser, Anda mungkin melihat sesuatu seperti berikut:

Selama daftar "klien", yang merupakan tab atau jendela yang menampilkan aplikasi Anda, tidak kosong, pekerja akan terus menunggu. Alasan pekerja layanan melakukan ini adalah untuk menjamin konsistensi. Konsistensi berarti bahwa semua sumber daya diambil dari cache atom yang sama.

Saat menguji perubahan, Anda mungkin merasa nyaman untuk memilih tautan "skipWaiting" seperti yang ditunjukkan pada cuplikan layar sebelumnya, lalu muat ulang halaman. Anda dapat mengotomatiskan ini untuk semua pengguna dengan mengkoding pekerja layanan Anda untuk melewati fase "menunggu" dan segera mengaktifkan pembaruan. Jika Anda melewati fase tunggu, Anda menyerahkan jaminan bahwa sumber daya selalu diambil secara konsisten dari instans cache yang sama.

Pengguna dapat menjalankan versi historis aplikasi apa pun

Pengembang web biasanya mengharapkan bahwa pengguna hanya menjalankan versi terbaru aplikasi web mereka yang disebarkan, karena itu normal dalam model distribusi web tradisional. Namun, PWA offline-first lebih mirip dengan aplikasi seluler asli, di mana pengguna belum tentu menjalankan versi terbaru.

Seperti yang dijelaskan di bagian Pembaruan Latar Belakang, setelah Anda menyebarkan pembaruan ke aplikasi Anda, setiap pengguna yang ada akan tetap menggunakan versi sebelumnya setidaknya untuk satu kunjungan lagi karena pembaruan terjadi di latar belakang dan tidak diaktifkan sampai pengguna menavigasi ke bagian lain. Plus, versi sebelumnya yang digunakan belum tentu versi sebelumnya yang Anda sebarkan. Versi sebelumnya dapat berupa versi historis apa pun , tergantung pada kapan pengguna terakhir kali menyelesaikan pembaruan.

Ini bisa menjadi masalah jika bagian frontend dan backend aplikasi Anda memerlukan perjanjian tentang skema untuk permintaan API. Anda tidak boleh menyebarkan perubahan skema API yang tidak kompatibel dengan versi sebelumnya hingga Anda dapat yakin bahwa semua pengguna telah memperbarui. Atau, blokir pengguna agar tidak menggunakan versi aplikasi lama yang tidak kompatibel. Persyaratan skenario ini sama dengan untuk aplikasi seluler asli. Jika Anda menyebarkan perubahan yang mengganggu fungsi di API server, aplikasi klien akan rusak untuk pengguna yang belum melakukan pembaruan.

Jika memungkinkan, jangan sebarkan perubahan yang melanggar ke API backend Anda. Jika Anda harus melakukannya, pertimbangkan untuk menggunakan API Pekerja Layanan standar seperti ServiceWorkerRegistration untuk menentukan apakah aplikasi sudah diperbarui, dan jika tidak, untuk mencegah penggunaan.

Gangguan pada halaman yang dirender oleh server

Seperti yang dijelaskan di bagian Dukung halaman yang dirender oleh server, jika Anda ingin melewati perilaku service worker mengembalikan /index.html konten untuk semua permintaan navigasi, edit logika di service worker Anda.

Semua konten manifes aset pekerja layanan di-cache

Seperti yang dijelaskan di bagian Pengelolaan cache aset Kontrol, file service-worker-assets.js yang dihasilkan selama build dan mencantumkan semua aset yang harus diambil dan disimpan dalam cache oleh service worker.

Karena daftar ini mencakup semua yang dipancarkan ke wwwroot, termasuk konten yang disediakan oleh paket dan proyek eksternal, Anda harus berhati-hati untuk tidak menempatkan terlalu banyak konten di sana. wwwroot Jika direktori berisi jutaan gambar, pekerja layanan mencoba mengambil dan menyimpan semuanya, mengonsumsi bandwidth yang berlebihan dan kemungkinan besar tidak berhasil diselesaikan.

Terapkan logika arbitrer untuk mengontrol subset konten manifes mana yang harus diambil dan di-cache dengan mengedit onInstall fungsi di service-worker.published.js.

Interaksi dengan autentikasi

Templat PWA dapat digunakan bersama dengan autentikasi. PWA berkemampuan offline juga dapat mendukung autentikasi ketika pengguna memiliki konektivitas jaringan awal.

Saat pengguna tidak memiliki konektivitas jaringan, mereka tidak dapat mengautentikasi atau mendapatkan token akses. Mencoba mengunjungi halaman masuk tanpa akses jaringan menghasilkan pesan "kesalahan jaringan". Anda harus merancang alur UI yang memungkinkan pengguna melakukan tugas yang berguna saat offline tanpa mencoba mengautentikasi pengguna atau mendapatkan token akses. Atau, Anda dapat merancang aplikasi agar gagal dengan lancar saat jaringan tidak tersedia. Jika aplikasi tidak dapat dirancang untuk menangani skenario ini, Anda mungkin tidak ingin mengaktifkan dukungan offline.

Ketika aplikasi yang dirancang untuk penggunaan online dan offline kembali online:

• Aplikasi mungkin perlu menyediakan token akses baru.
• Aplikasi harus mendeteksi apakah pengguna yang berbeda masuk ke layanan sehingga dapat menerapkan operasi ke akun pengguna yang dibuat saat offline.

Untuk membuat aplikasi PWA offline yang berinteraksi dengan autentikasi:

• Ganti AccountClaimsPrincipalFactory<TAccount> dengan sebuah eksekutor yang menyimpan pengguna terakhir yang masuk dan menggunakan pengguna yang disimpan ketika aplikasi sedang offline.
• Mengantrekan operasi ketika aplikasi offline dan menerapkannya ketika aplikasi kembali online.
• Saat keluar, hapus pengguna yang disimpan.

Aplikasi CarChecker sampel menunjukkan pendekatan yang telah dijelaskan. Lihat bagian aplikasi berikut:

• OfflineAccountClaimsPrincipalFactory(Client/Data/OfflineAccountClaimsPrincipalFactory.cs)
• LocalVehiclesStore(Client/Data/LocalVehiclesStore.cs)
• LoginStatus komponen (Client/Shared/LoginStatus.razor)

Sumber daya tambahan

Negosiasi lintas sumber di SignalR sisi klien untuk autentikasi