ASP.NET Core Blazor progresivní webová aplikace (PWA)

Blazor Progresivní webová aplikace (PWA) je jednostránkové aplikace (SPA), která používá moderní rozhraní API a možnosti prohlížeče, které se chovají jako desktopová aplikace.

Blazor WebAssembly je platforma webové aplikace založená na standardech, takže může používat libovolné rozhraní API prohlížeče, včetně rozhraní API PWA vyžadovaných pro následující funkce:

• Práce offline a načítání okamžitě nezávisle na rychlosti sítě.
• Běží ve vlastním okně aplikace, nejen v okně prohlížeče.
• Spouští se z nabídky Start operačního systému hostitele, docku nebo domovské obrazovky.
• Příjem nabízených oznámení z back-endového serveru, i když uživatel aplikaci nepoužívá.
• Automatická aktualizace na pozadí

Slovo progresivní se používá k popisu těchto aplikací, protože:

• Uživatel může aplikaci nejprve objevit a používat ve webovém prohlížeči, stejně jako jakoukoli jinou SPA.
• Později uživatel pokračuje v instalaci do operačního systému a povolení nabízených oznámení.

Vytvoření projektu ze šablony PWA

Visual Studio

Při vytváření nové Blazor WebAssembly aplikace vyberte zaškrtávací políčko Progresivní webová aplikace.

Visual Studio Code / .NET CLI

Pomocí následujícího příkazu vytvořte projekt PWA v příkazovém prostředí s přepínačem --pwa :

dotnet new blazorwasm -o MyBlazorPwa --pwa

V předchozím příkazu vytvoří -o|--output možnost novou složku pro aplikaci s názvem MyBlazorPwa.

Převod existující Blazor WebAssembly aplikace na PWA

Podle pokynů v této části převeďte existující Blazor WebAssembly aplikaci na PWA.

V souboru projektu aplikace:

• Přidejte následující ServiceWorkerAssetsManifest vlastnost do PropertyGroup:

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

• Přidejte následující ServiceWorker položku do ItemGroup:

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

Pokud chcete získat statické zdroje, použijte jeden z následujících přístupů:

• Vytvořte samostatný nový projekt PWA pomocí dotnet new příkazu v příkazovém prostředí:

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  V předchozím příkazu vytvoří -o|--output možnost novou složku pro aplikaci s názvem MyBlazorPwa.

  Pokud nepřevádíte aplikaci pro nejnovější verzi, použijte možnost -f|--framework. Následující příklad vytvoří aplikaci pro .NET 5:

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

• Přejděte na GitHub úložiště ASP.NET Core na následující adrese URL, která odkazuje na zdrojový kód a prostředky pro větev main. V rozevíracím seznamu Přepnout větve nebo značky vyberte verzi, se kterou pracujete.

  Blazor WebAssembly složka šablony wwwroot projektu (dotnet/aspnetcore větev úložiště main GitHub)

  Poznámka:

  Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní vydání, použijte rozevírací seznam pro přepínání větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

  Ze zdrojové wwwroot složky buď v aplikaci, kterou jste vytvořili, nebo z referenčních prostředků v dotnet/aspnetcore úložišti GitHub zkopírujte do složky aplikace wwwroot následující soubory:

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

V souboru aplikace wwwroot/index.html :

• Přidání <link> elementů pro manifest a ikonu aplikace:

  <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" />
  

• Přidejte následující <script> značku do uzavírací </body> značky hned za blazor.webassembly.js značku skriptu:

      ...
      <script>navigator.serviceWorker.register('service-worker.js');</script>
  </body>
  

Manifest instalace a aplikace

Při návštěvě aplikace vytvořené pomocí šablony PWA mají uživatelé možnost nainstalovat aplikaci do nabídky Start, docku nebo domovské obrazovky operačního systému. Způsob zobrazení této možnosti závisí na prohlížeči uživatele. Pokud používáte desktopové prohlížeče založené na Chromiu, jako je Edge nebo Chrome, zobrazí se na panelu URL tlačítko Přidat . Jakmile uživatel vybere tlačítko Přidat , zobrazí se potvrzovací dialogové okno:

V iOSu si návštěvníci můžou aplikaci PWA nainstalovat pomocí tlačítka Sdílet v Safari a možnosti Přidat na domovskou obrazovku. V Chromu pro Android by uživatelé měli vybrat tlačítko Menu v pravém horním rohu a pak Přidat na Home plochu.

Po instalaci se aplikace zobrazí ve vlastním okně bez adresního řádku:

Pokud chcete přizpůsobit název okna, barevné schéma, ikonu nebo další podrobnosti, podívejte se na manifest.json soubor v adresáři projektu wwwroot . Schéma tohoto souboru je definováno webovými standardy. Další informace najdete ve webové dokumentaci MDN: Manifest webové aplikace.

Offline podpora

Aplikace vytvořené pomocí možnosti šablony PWA mají podporu pro spuštění offline. Uživatel musí nejprve navštívit aplikaci, když je online. Prohlížeč automaticky stáhne a ukládá všechny prostředky potřebné k provozu offline.

Důležité

Podpora vývoje by ovlivnila obvyklý vývojový cyklus provádění změn a jejich testování. Proto je offline podpora povolená jenom pro publikované aplikace.

Varování

Pokud máte v úmyslu distribuovat PWA s povoleným offline režimem, existuje několik důležitých upozornění a výzev. Tyto scénáře jsou nedílnou součástí offline PWA a nejsou specifické pro Blazor. Než si uděláte předpoklady o tom, jak vaše aplikace s podporou offline funguje, nezapomeňte si je přečíst a porozumět těmto upozorněním.

Pokud chcete zjistit, jak funguje podpora offline:

1. Publikujte aplikaci. Další informace najdete v tématu Hostitel a nasazení ASP.NET Core Blazor.

2. Nasaďte aplikaci na server, který podporuje PROTOKOL HTTPS, a přejděte k aplikaci v prohlížeči na jeho zabezpečené adrese HTTPS.

3. Otevřete vývojářské nástroje prohlížeče a ověřte, že je pro hostitele zaregistrován Service Worker v kartě Aplikace

   

4. Znovu načtěte stránku a prozkoumejte kartu Síť. Service Worker nebo vyrovnávací paměť jsou uvedeny jako zdroje pro všechny prostředky stránky.

   

5. Pokud chcete ověřit, že prohlížeč není závislý na síťovém přístupu k načtení aplikace, proveďte následující:

   • Vypněte webový server a podívejte se, jak aplikace funguje normálně, včetně opětovného načtení stránky. Stejně tak aplikace dál funguje normálně, když je pomalé síťové připojení.
   • Řekněte prohlížeči, aby na kartě Síť simuloval offline režim:

   

Podpora offline pomocí služebního pracovníka je webový standard, nikoli specifický pro Blazor. Další informace o servisních pracovnících najdete v dokumentaci MDN webových stránek: API servisních pracovníků. Další informace o běžných vzorech použití pracovních procesů služeb najdete v tématu Google Web: Životní cyklus pracovního procesu služby.

BlazorŠablona PWA vytvoří dva soubory servisních pracovníků:

• wwwroot/service-worker.js, který se používá při vývoji.
• wwwroot/service-worker.published.js, který se použije po publikování aplikace.

Pokud chcete sdílet logiku mezi těmito dvěma soubory pracovních procesů služby, zvažte následující přístup:

• Přidejte třetí javascriptový soubor, který bude obsahovat společnou logiku.
• Použijte self.importScripts k načtení obecné logiky do obou souborů servisních pracovníků.

Strategie načítání s prioritou mezipaměti

Integrovaný pracovník služby vyřeší požadavky pomocí strategie cache-first. To znamená, že pracovní proces služby dává přednost vrácení obsahu uloženého v mezipaměti bez ohledu na to, jestli má uživatel přístup k síti nebo je na serveru dostupný novější obsah.

Strategie první mezipaměti je cenná, protože:

• Zajišťuje spolehlivost. Přístup k síti není binární stav. Uživatel není jednoduše online ani offline:

  • Zařízení uživatele může předpokládat, že je online, ale síť může být tak pomalá, jako by bylo nepraktické čekat.
  • cs-CZ: Síť může vracet neplatné výsledky pro určité adresy URL, například pokud existuje captive wifi portál, který aktuálně blokuje nebo přesměrovává určité požadavky.

  Proto rozhraní API prohlížeče navigator.onLine není spolehlivé a nemělo by na něm záviset.

• Zajišťuje správnost. Při vytváření mezipaměti offline prostředků používá service worker hashování obsahu, aby zajistil, že načetl kompletní a soběstačný snímek prostředků v jediném okamžiku. Tato mezipaměť se pak použije jako atomická jednotka. Není potřeba žádat síť o novější prostředky, protože jediné požadované verze jsou ty, které už jsou uložené v mezipaměti. Cokoli jiného riskuje nekonzistence a nekompatibilitu (například při pokusu o použití verzí sestavení .NET, která nebyla kompilována společně).

Pokud musíte prohlížeči zabránit v načtení service-worker-assets.js z mezipaměti HTTP, například k vyřešení dočasných selhání kontroly integrity při nasazování nové verze pracovního procesu služby, aktualizujte registraci wwwroot/index.html pracovního procesu služby nastavenou updateViaCache na hodnotu None:

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

Aktualizace na pozadí

Jako mentální model si můžete představit offline aplikaci PWA jako mobilní aplikaci, která se dá nainstalovat. Aplikace se spustí okamžitě bez ohledu na připojení k síti, ale nainstalovaná logika aplikace pochází ze snímku k určitému bodu v čase, který nemusí být nejnovější verzí.

Šablona Blazor PWA vytvoří aplikace, které se automaticky pokusí aktualizovat na pozadí, kdykoli uživatel navštíví a má funkční síťové připojení. Způsob, jakým to funguje, je následující:

• Během kompilace projekt vygeneruje manifest prostředků pracovního procesu služby, který má název service-worker-assets.js. Manifest obsahuje seznam všech statických prostředků, které aplikace vyžaduje, aby fungovala offline, jako jsou sestavení .NET, soubory JavaScriptu a šablony stylů CSS, včetně jejich hodnot hash obsahu. Seznam prostředků načítá service worker, aby věděl, které prostředky má ukládat do mezipaměti.
• Pokaždé, když uživatel navštíví aplikaci, prohlížeč si znovu vyžádá service-worker.js a service-worker-assets.js na pozadí. Soubory se porovnávají bajt po bajtu s existujícím nainstalovaným service workerem. Pokud server vrátí změněný obsah pro některý z těchto souborů, pracovní proces služby se pokusí nainstalovat novou verzi sebe sama.
• Při instalaci nové verze sama o sobě pracovní proces služby vytvoří novou, samostatnou mezipaměť pro offline prostředky a spustí naplnění mezipaměti prostředky uvedenými v service-worker-assets.js. Tato logika je implementována ve funkci onInstall uvnitř service-worker.published.js.
• Proces se úspěšně dokončí, když se všechny prostředky načtou bez chyb a všechny hodnoty hash obsahu se shodují. Pokud je to úspěšné, nový servisní pracovník přejde do stavu čekání na aktivaci. Jakmile uživatel aplikaci zavře (žádné zbývající karty nebo okna aplikace), nový pracovník služby se aktivuje a použije se pro následné návštěvy aplikace. Starý pracovník služby a jeho mezipaměť jsou odstraněni.
• Pokud se proces úspěšně nedokončí, nová instance service workeru se zahodí. Proces aktualizace bude znovu proveden při příští návštěvě uživatele, pokud bude mít klient lepší síťové připojení, které může dokončit požadavky.

Upravte tento proces úpravou logiky pracovního procesu služby. Žádné z předchozích chování není specifické pro Blazor, ale je pouze výchozí zkušeností, kterou poskytuje možnost šablony PWA. Další informace najdete v dokumentaci webu MDN: Rozhraní Service Worker API.

Způsob řešení požadavků

Jak je popsáno v části Cache-first strategického načítání, výchozí servisní pracovník používá strategii cache-first, což znamená, že se pokusí poskytnout obsah z mezipaměti, pokud je k dispozici. Pokud pro určitou adresu URL neexistuje žádný obsah uložený v mezipaměti, například při vyžádání dat z back-endového rozhraní API, pracovní proces služby se vrátí k běžnému síťovému požadavku. Síťový požadavek bude úspěšný, pokud je server dostupný. Tato logika se implementuje uvnitř onFetch funkce v rámci service-worker.published.js.

Pokud komponenty aplikace Razor spoléhají na vyžádání dat z back-endových rozhraní API a chcete poskytnout přívětivé uživatelské prostředí pro neúspěšné požadavky kvůli nedostupnosti sítě, implementujte logiku v rámci komponent aplikace. Například použijte try/catch kolem žádostí HttpClient.

Podpora stránek vykreslených serverem

Zamyslete se nad tím, co se stane, když uživatel poprvé přejde na adresu URL, například /counter na jakýkoli jiný přímý odkaz v aplikaci. V těchto případech nechcete vracet obsah uložený v mezipaměti /counter, ale potřebujete, aby prohlížeč načetl obsah uložený jako /index.html, aby se spustila vaše aplikace Blazor WebAssembly. Tyto počáteční požadavky se označují jako navigační požadavky, na rozdíl od těchto požadavků:

• subresource požadavky na obrázky, šablony stylů nebo jiné soubory.
• fetch/XHR požadavky na data rozhraní API.

Výchozí pracovní proces služby obsahuje pro požadavky navigace zvláštní logiku. Servisní pracovník vyřeší požadavky vrácením obsahu uloženého v mezipaměti pro /index.html, bez ohledu na požadovanou URL. Tato logika je implementována ve funkci onFetch uvnitř service-worker.published.js.

Pokud má vaše aplikace určité adresy URL, které musí vracet kód HTML vykreslený serverem, a nikoli /index.html z mezipaměti, musíte upravit logiku pracovního procesu služby. Pokud všechny adresy URL obsahující /Identity/ je potřeba zpracovat jako běžné online požadavky pouze na server, upravte service-worker.published.jsonFetch logiku. Vyhledejte následující kód:

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

Změňte kód na následující:

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

Pokud to neuděláte, pak bez ohledu na síťové připojení zachytí pracovník služby požadavky na tyto adresy URL a vyřeší je pomocí /index.html.

Přidejte do kontroly další koncové body externích zprostředkovatelů ověřování. V následujícím příkladu se do kontroly přidá /signin-google pro ověřování Google:

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

Pro Development prostředí není nutná žádná akce, kde se obsah vždy načte ze sítě.

Řízení ukládání aktiv do mezipaměti

Pokud váš projekt definuje ServiceWorkerAssetsManifest vlastnost MSBuild, Blazornástroj sestavení generuje manifest prostředků pracovního procesu služby se zadaným názvem. Výchozí šablona PWA vytvoří soubor projektu obsahující následující vlastnost:

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

Soubor je umístěn ve výstupním wwwroot adresáři, takže prohlížeč může tento soubor načíst vyžádáním /service-worker-assets.js. Pokud chcete zobrazit obsah tohoto souboru, otevřete /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js ho v textovém editoru. Soubor ale neupravujte, protože se v každém sestavení znovu vygeneruje.

Seznam manifestů:

• Veškeré Blazor-spravované prostředky, jako jsou .NET sestavení a soubory modulu runtime .NET WebAssembly potřebné k fungování offline.
• Všechny prostředky pro publikování do adresáře aplikace wwwroot , jako jsou obrázky, šablony stylů a soubory JavaScriptu, včetně statických webových prostředků poskytovaných externími projekty a balíčky NuGet.

Můžete řídit, které z těchto prostředků se načítají a ukládají do mezipaměti servisním pracovníkem, úpravou logiky v onInstall a service-worker.published.js. Servisní pracovník načte a ukládá do mezipaměti soubory, které odpovídají typickým příponám webových souborů, jako jsou například .html, .css, .js a .wasm, a dále typy souborů specifické pro Blazor WebAssembly, jako například soubory .pdb (všechny verze) a .dll soubory (ASP.NET Core v .NET 7 nebo starší).

Pokud chcete zahrnout další prostředky, které nejsou přítomné v adresáři aplikace wwwroot, definujte další položky ItemGroup MSBuild, jak je znázorněno v následujícím příkladu:

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

Metadata AssetUrl určuje základní relativní adresu URL, kterou má prohlížeč použít při načítání prostředku do mezipaměti. To může být nezávislé na původním názvu zdrojového souboru na disku.

Důležité

Přidání ServiceWorkerAssetsManifestItem nezpůsobí publikování souboru v adresáři wwwroot aplikace. Výstup publikování musí být řízen samostatně. Jediné, co ServiceWorkerAssetsManifestItem způsobí, že do manifestu souborů service worker přibude další položka.

Push oznámení

Stejně jako jakékoli jiné PWA může i PWA Blazor WebAssembly přijímat push oznámení z backend serveru. Server může odesílat nabízená oznámení kdykoli, i když uživatel aplikaci aktivně nepoužívá. Push oznámení lze například odeslat, když jiný uživatel provede příslušnou akci.

Upozornění pro offline PWA

Ne všechny aplikace by se měly pokoušet podporovat offline použití. Podpora offline zvyšuje značnou složitost, ale nemusí být vždy relevantní pro požadované případy použití.

Offline podpora je obvykle relevantní pouze:

• Pokud je primární úložiště dat místní v prohlížeči. Přístup je například relevantní v aplikaci s uživatelským rozhraním pro zařízení IoT , které ukládá data do localStorage nebo IndexedDB.
• Pokud aplikace provádí značné množství práce při načítání a ukládání dat back-endového rozhraní API do mezipaměti relevantních pro každého uživatele, aby mohl procházet data offline. Pokud aplikace musí podporovat úpravy, musí být sestaven systém pro sledování změn a synchronizaci dat s back-endem.
• Pokud je cílem zaručit, že se aplikace načte okamžitě bez ohledu na síťové podmínky. Implementujte vhodné uživatelské prostředí kolem požadavků rozhraní API back-endu, aby bylo možné zobrazit průběh požadavků a chovat se elegantně, když požadavky selžou kvůli nedostupnosti sítě.

Kromě toho musí PWA schopné pracovat offline řešit řadu dalších komplikací. Vývojáři by se měli pečlivě seznámit s upozorněními v následujících částech.

Offline podpora pouze po publikování

Během vývoje se obvykle každá změna projeví okamžitě v prohlížeči, aniž byste museli procházet procesem aktualizace na pozadí. BlazorŠablona PWA proto umožňuje offline podporu pouze při publikování.

Při vytváření aplikace s offline schopnostmi nestačí ji pouze testovat v Development prostředí. Aplikaci musíte otestovat v publikovaném stavu, abyste pochopili, jak reaguje na různé síťové podmínky.

Dokončení aktualizace po odchodu uživatele z aplikace

Aktualizace neproběhnou úplně, dokud uživatel neopustí aplikaci na všech kartách. Jak je vysvětleno v části Aktualizace na pozadí, po nasazení aktualizace do aplikace prohlížeč načte aktualizované soubory pracovních procesů služby, aby zahájil proces aktualizace.

Překvapením mnoha vývojářů je, že i když se tato aktualizace dokončí, neprojeví se, dokud uživatel neopustí všechny karty. Nestačí aktualizovat záložku, která zobrazuje aplikaci, i když je to jediná záložka, na které se aplikace zobrazuje. Dokud svou aplikaci zcela neukončíte, zůstane nový pracovní proces služby ve stavu čekání na aktivaci. To není specifické pro Blazor, ale spíše jde o standardní chování webové platformy.

To často způsobuje potíže vývojářům, kteří se pokoušejí otestovat aktualizace svého service workeru nebo prostředků uložených offline v mezipaměti. Pokud zkontrolujete vývojářské nástroje prohlížeče, může se zobrazit něco podobného:

Dokud seznam "klientů", což jsou karty nebo okna zobrazující vaši aplikaci, není prázdný, pracovník pokračuje v čekání. Důvodem, proč to pracovníci služeb dělají, je zaručit konzistenci. Konzistence znamená, že všechny prostředky se získávají ze stejné atomové mezipaměti.

Při testování změn může být vhodné vybrat odkaz "skipWaiting", jak je znázorněno na předchozím snímku obrazovky, a pak stránku znovu načíst. Můžete to automatizovat pro všechny uživatele tím, že zakódujete pracovní proces služby, abyste přeskočí fázi čekání a okamžitě aktivovali aktualizaci. Pokud fázi čekání přeskočíte, vzdáváte se záruky, že prostředky se vždy načítají konzistentně ze stejné instance mezipaměti.

Uživatelé můžou spouštět jakoukoli historickou verzi aplikace.

Vývojáři webu obvykle očekávají, že uživatelé spouštějí jenom nejnovější nasazenou verzi své webové aplikace, protože to je normální v rámci tradičního modelu distribuce webu. Offline-první PWA je spíše podobná nativní mobilní aplikaci, kde uživatelé nemusí nutně používat nejnovější verzi.

Jak je vysvětleno v části Aktualizace na pozadí, po nasazení aktualizace do aplikace bude každý existující uživatel nadále používat předchozí verzi pro alespoň jednu další návštěvu, protože aktualizace se vyskytuje na pozadí a není aktivovaná, dokud uživatel poté nepřejde pryč. Navíc použitá předchozí verze nemusí být nutně předchozí, kterou jste nasadili. Předchozí verze může být libovolná historická verze v závislosti na tom, kdy uživatel naposledy dokončil aktualizaci.

To může být problém, pokud front-endové a back-endové části vaší aplikace vyžadují smlouvu o schématu požadavků rozhraní API. Dokud nebudete mít jistotu, že všichni uživatelé upgradovali, nesmíte nasadit zpětně nekompatibilní změny schématu rozhraní API. Případně můžete uživatelům zablokovat používání nekompatibilních starších verzí aplikace. Tento požadavek na scénář je stejný jako u nativních mobilních aplikací. Pokud nasadíte zásadní změnu v serverových rozhraních API, klientská aplikace se přeruší pro uživatele, kteří ještě neaktualizovali.

Pokud je to možné, nenasazujte do back-endových rozhraní API zásadní změny. Pokud to musíte udělat, zvažte použití standardních rozhraní API service workerů, jako je ServiceWorkerRegistration , abyste zjistili, jestli je aplikace aktuální, a pokud ne, aby se zabránilo použití.

Narušení se stránkami vykreslenými serverem

Jak je popsáno v části Podpora serverem vykreslených stránek, pokud chcete obejít chování vašeho service workeru týkající se vracení /index.html obsahu pro všechny navigační požadavky, upravte logiku vašeho service workeru.

Veškerý obsah manifestu prostředků obslužného pracovníka je uložen do mezipaměti.

Jak je popsáno v části Ukládání prostředků řízení do mezipaměti , soubor service-worker-assets.js se vygeneruje během sestavování a vypíše všechny prostředky, které by měl pracovní proces služby načíst a uložit do mezipaměti.

Vzhledem k tomu, že tento seznam obsahuje vše, co je generováno na wwwroot, včetně obsahu dodaného externími balíčky a projekty, je třeba být opatrní, abyste tam nevložili příliš mnoho obsahu. wwwroot Pokud adresář obsahuje miliony obrázků, pracovní proces služby se pokusí načíst a uložit je do mezipaměti, spotřebovávat nadměrnou šířku pásma a s největší pravděpodobností se úspěšně nedokončí.

Implementujte libovolnou logiku pro řízení, která podmnožina obsahu manifestu by se měla načíst a uložit do mezipaměti úpravou onInstall funkce v service-worker.published.js.

Interakce s autentizací

Šablonu PWA lze použít ve spojení s ověřováním. PwA s podporou offline může také podporovat ověřování, pokud má uživatel počáteční síťové připojení.

Pokud uživatel nemá síťové připojení, nemůže se ověřit ani získat přístupové tokeny. Při pokusu o návštěvu přihlašovací stránky bez přístupu k síti se zobrazí zpráva "chyba sítě". Je nutné navrhnout tok uživatelského rozhraní, který uživateli umožňuje provádět užitečné úlohy v offline režimu, aniž by se pokusil uživatele ověřit nebo získat přístupové tokeny. Alternativně můžete navrhnout aplikaci tak, aby řádně selhala, když síť není dostupná. Pokud aplikace nemůže být navržená tak, aby tyto scénáře zpracovávala, možná nebudete chtít povolit offline podporu.

Když je aplikace navržená pro online a offline použití znovu online:

• Aplikace může potřebovat zřídit nový přístupový token.
• Aplikace musí zjistit, jestli je k této službě přihlášen jiný uživatel, aby mohl použít operace na účet uživatele, který byl proveden, když byl offline.

Vytvoření offline aplikace PWA, která komunikuje s ověřováním:

• Nahraďte AccountClaimsPrincipalFactory<TAccount> továrnou, která ukládá posledního přihlášeného uživatele a používá uloženého uživatele, když je aplikace offline.
• Zařadit operace do fronty, když je aplikace offline, a použít je, když se aplikace vrátí online.
• Během odhlášení vymažte uloženého uživatele.

Ukázková CarChecker aplikace ukazuje předchozí přístupy. Podívejte se na následující části aplikace:

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

Další materiály

• Řešení potíží se skriptem PowerShellu pro integritu
• Vyjednávání pro ověřování mezi zdroji na straně SignalR klienta