ASP.NET Core Blazor Aplicação Web Progressiva (PWA)

Um Blazor aplicativo Web progressivo (PWA) é um aplicativo de página única (SPA) que usa APIs e recursos modernos do navegador para se comportar como um aplicativo de desktop.

Blazor WebAssembly é uma plataforma de aplicativo Web do lado do cliente baseada em padrões, portanto, pode usar qualquer API do navegador, incluindo APIs do PWA necessárias para os seguintes recursos:

• Trabalhando offline e carregando instantaneamente, independentemente da velocidade da rede.
• Executar na sua própria janela de aplicação, não apenas numa janela do navegador.
• Iniciar a partir do menu iniciar, barra de atalhos ou ecrã inicial do sistema operativo do anfitrião.
• Receber notificações por push de um servidor back-end, mesmo enquanto o usuário não está usando o aplicativo.
• Atualização automática em segundo plano.

A palavra progressive é usada para descrever essas aplicações porque:

• Um usuário pode primeiro descobrir e usar o aplicativo em seu navegador da Web como qualquer outro SPA.
• Mais tarde, o usuário progride para instalá-lo em seu sistema operacional e ativar notificações push.

Criar um projeto a partir do modelo PWA

Estúdio Visual

Ao criar um novo Blazor WebAssembly aplicativo, marque a caixa de seleção Aplicativo Web progressivo .

Código do Visual Studio / CLI do .NET

Utilize o seguinte comando para criar um projeto PWA num shell de comando com a opção --pwa:

dotnet new blazorwasm -o MyBlazorPwa --pwa

No comando anterior, a -o|--output opção cria uma nova pasta para o aplicativo chamado MyBlazorPwa.

Converter um aplicativo existente Blazor WebAssembly em um PWA

Converta um aplicativo existente Blazor WebAssembly em um PWA seguindo as orientações desta seção.

No arquivo de projeto do aplicativo:

• Adicione a propriedade ServiceWorkerAssetsManifest seguinte a um PropertyGroup:

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

• Adicione o seguinte item ServiceWorker a um ItemGroup arquivo:

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

Para obter ativos estáticos, use uma das seguintes abordagens:

• Crie um novo projeto PWA separado com o comando dotnet new em um shell de comando.

  dotnet new blazorwasm -o MyBlazorPwa --pwa
  

  No comando anterior, a -o|--output opção cria uma nova pasta para o aplicativo chamado MyBlazorPwa.

  Se você não estiver convertendo um aplicativo para a versão mais recente, passe a -f|--framework opção. O exemplo a seguir cria o aplicativo para .NET 5:

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

• Navegue para o repositório ASP.NET Core GitHub na URL a seguir, que vincula os recursos e a origem de referência do ramo main. Selecione a versão com a qual está a trabalhar na lista suspensa Alternar entre ramos ou etiquetas que se aplica ao seu aplicativo.

  Blazor WebAssembly modelo de pasta de wwwroot projeto (dotnet/aspnetcore ramificação do repositório main GitHub)

  Observação

  Os links de documentação para a fonte de referência do .NET geralmente carregam a ramificação padrão do repositório, que representa o desenvolvimento atual para a próxima versão do .NET. Para selecionar uma tag para uma versão específica, use a lista suspensa Alternar entre ramificações ou tags. Para obter mais informações, consulte Como selecionar uma marca de versão do código-fonte ASP.NET Core (dotnet/AspNetCore.Docs #26205).

  Da pasta de origem wwwroot no aplicativo que você criou ou dos ativos de referência no dotnet/aspnetcore repositório do GitHub, copie os seguintes arquivos para a pasta do wwwroot aplicativo:

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

No ficheiro da wwwroot/index.html aplicação:

• Adicione <link> elementos para o manifesto e o ícone do aplicativo:

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

• Adicione o seguinte JavaScript dentro da tag de fechamento </body> imediatamente após a tag de blazor.webassembly.js script:

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

  A updateViaCache: 'none' opção garante que:

  • O navegador não usa versões em cache do script do service worker.
  • As atualizações do trabalhador de serviço são aplicadas de forma confiável sem serem bloqueadas pelo cache HTTP.
  • Os aplicativos PWA podem atualizar seus trabalhadores de serviço de forma mais previsível.

  Isso resolve problemas de cache que podem impedir que as atualizações do service worker sejam aplicadas corretamente, o que é particularmente importante para PWAs que dependem de service workers para a funcionalidade offline.

Instalação e manifesto do aplicativo

Ao visitar um aplicativo criado usando o modelo PWA, os usuários têm a opção de instalar o aplicativo no menu Iniciar, no dock ou na tela inicial do sistema operacional. A forma como esta opção é apresentada depende do navegador do utilizador. Ao usar navegadores baseados no Chromium para desktop, como Edge ou Chrome, um botão Adicionar aparece na barra de URL. Depois que o usuário seleciona o botão Adicionar , ele recebe uma caixa de diálogo de confirmação:

No iOS, os visitantes podem instalar o PWA usando o botão Compartilhar do Safari e a opção Adicionar à tela inicial . No Chrome para Android, os utilizadores devem selecionar o botão Menu no canto superior direito, seguido de Adicionar ao Home ecrã.

Uma vez instalado, o aplicativo aparece em sua própria janela sem uma barra de endereço:

Para personalizar o título, o esquema de cores, o ícone ou outros detalhes da janela, consulte o manifest.json arquivo no diretório do wwwroot projeto. O esquema deste arquivo é definido por padrões da web. Para obter mais informações, consulte MDN web docs: Web App Manifest.

Suporte offline

Os aplicativos criados usando a opção de modelo do PWA têm suporte para execução offline. Um usuário deve primeiro visitar o aplicativo enquanto estiver online. O navegador transfere e armazena automaticamente em cache todos os recursos necessários para operar offline.

Importante

O apoio ao desenvolvimento interferiria com o ciclo de desenvolvimento habitual de fazer alterações e testá-las. Portanto, o suporte offline só está habilitado para aplicativos publicados .

Advertência

Se você pretende distribuir um PWA habilitado offline, há vários avisos e advertências importantes. Esses cenários são inerentes aos PWAs offline e não específicos do Blazor. Certifique-se de ler e entender essas advertências antes de fazer suposições sobre como seu aplicativo habilitado para offline funciona.

Para ver como funciona o suporte offline:

1. Publique o aplicativo. Para obter mais informações, consulte Hospedar e implantar ASP.NET Core Blazor.

2. Implante o aplicativo em um servidor que suporte HTTPS e acesse o aplicativo em um navegador em seu endereço HTTPS seguro.

3. Abra as ferramentas de desenvolvimento do navegador e verifique se um Service Worker está registrado para o host na guia Aplicativo :

   

4. Recarregue a página e examine a guia Rede. Service Worker ou o cache de memória são listados como as fontes de todos os recursos da página.

   

5. Para verificar se o navegador não depende do acesso à rede para carregar o aplicativo:

   • Desligue o servidor Web e veja como o aplicativo continua funcionando normalmente, o que inclui recarregamentos de página. Da mesma forma, o aplicativo continua a funcionar normalmente quando há uma conexão de rede lenta.
   • Instrua o navegador a simular o modo offline na guia Rede :

   

O suporte off-line usando um service worker é um padrão da Web, não específico do Blazor. Para obter mais informações sobre trabalhadores de serviço, consulte MDN web docs: Service Worker API. Para saber mais sobre padrões de uso comuns para trabalhadores de serviços, consulte Google Web: O ciclo de vida do trabalhador de serviço.

BlazorO modelo PWA do produz dois arquivos de service worker:

• wwwroot/service-worker.js, que é usado durante o desenvolvimento.
• wwwroot/service-worker.published.js, que é utilizado após a publicação da aplicação.

Para partilhar a lógica entre os dois arquivos do service worker, considere a seguinte abordagem:

• Adicione um terceiro arquivo JavaScript para manter a lógica comum.
• Use self.importScripts para carregar a lógica comum em ambos os arquivos do service worker.

Estratégia de obtenção com cache primeiro

O trabalhador de serviço integrado service-worker.published.js resolve solicitações usando uma estratégia cache-first. Isso significa que o operador de serviço prefere retornar o conteúdo armazenado em cache, independentemente de o usuário ter acesso à rede ou de o conteúdo mais recente estar disponível no servidor.

A estratégia cache-first é valiosa porque:

• Garante fiabilidade. O acesso à rede não é um estado booleano. Um utilizador não está simplesmente online ou offline:

  • O dispositivo do usuário pode presumir que está online, mas a rede pode ser tão lenta que é impraticável esperar.
  • A rede pode retornar resultados inválidos para determinados URLs, como quando há um portal WIFI cativo que está bloqueando ou redirecionando determinadas solicitações.

  É por isso que a API do navigator.onLine navegador não é confiável e não deve ser dependida.

• Garante a correção. Ao criar um cache de recursos offline, o service worker usa hashing de conteúdo para garantir que obteve um instantâneo completo e autoconsistente dos recursos num instante específico. Esse cache é então usado como uma unidade atômica. Não vale a pena pedir à rede recursos mais recentes, uma vez que as únicas versões necessárias são as que já estão armazenadas em cache. Qualquer outra coisa corre o risco de inconsistência e incompatibilidade (por exemplo, tentar usar versões de assemblies .NET que não foram compilados juntos).

Para impedir que o navegador busque service-worker-assets.js seu cache HTTP, por exemplo, para resolver falhas temporárias de verificação de integridade ao implantar uma nova versão do service worker, o registro do service worker em wwwroot/index.html usa definido updateViaCache como none:

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

A updateViaCache: 'none' opção garante que:

• O navegador não usa versões em cache do script do service worker.
• As atualizações do trabalhador de serviço são aplicadas de forma confiável sem serem bloqueadas pelo cache HTTP.
• Os aplicativos PWA podem atualizar seus trabalhadores de serviço de forma mais previsível.

Isso resolve problemas de cache que podem impedir que as atualizações do service worker sejam aplicadas corretamente, o que é particularmente importante para PWAs que dependem de service workers para a funcionalidade offline.

Atualizações de fundo

Como um modelo mental, você pode pensar em um PWA offline como se comportando como um aplicativo móvel que pode ser instalado. A aplicação inicia imediatamente, independentemente da conectividade de rede, mas a lógica da aplicação instalada provém de um instantâneo de momento específico que pode não ser a versão mais recente.

O Blazor modelo PWA produz aplicativos que tentam se atualizar automaticamente em segundo plano sempre que o usuário visita e tem uma conexão de rede em funcionamento. A forma como isto funciona é a seguinte:

• Durante a compilação, o projeto gera um manifesto de ativos do trabalhador de serviço, que é chamado service-worker-assets.js. O manifesto lista todos os recursos estáticos que o aplicativo requer para funcionar offline, como assemblies .NET, arquivos JavaScript e CSS, incluindo seus hashes de conteúdo. A lista de recursos é carregada pelo operador de serviço para que ele saiba quais recursos armazenar em cache.
• Cada vez que o usuário visita o aplicativo, o navegador solicita novamente service-worker.js e service-worker-assets.js em segundo plano. Os arquivos são comparados byte por byte com o service worker instalado existente. Se o servidor retornar conteúdo alterado para qualquer um desses arquivos, o service worker tentará instalar uma nova versão de si mesmo.
• Ao instalar uma nova versão de si mesmo, o service worker cria um novo cache separado para recursos offline e começa a preencher o cache com recursos listados em service-worker-assets.js. Esta lógica é implementada na função onInstall dentro do service-worker.published.js.
• O processo é concluído com êxito quando todos os recursos são carregados sem erro e todos os hashes de conteúdo correspondem. Se for bem-sucedido, o novo trabalhador de serviço entrará em um estado de espera para ativação. Assim que o usuário fecha o aplicativo (sem guias ou janelas de aplicativo restantes), o novo operador de serviço fica ativo e é usado para visitas subsequentes ao aplicativo. O service worker antigo e a sua cache são eliminados.
• Se o processo não for concluído com êxito, a nova versão do service worker será eliminada. O processo de atualização é tentado novamente na próxima visita do usuário, quando esperamos que o cliente tenha uma conexão de rede melhor que possa concluir as solicitações.

Personalize esse processo editando a lógica do service worker. Nenhum dos comportamentos anteriores é específico do Blazor, mas é apenas a experiência padrão fornecida pela opção de modelo de PWA. Para obter mais informações, consulte MDN web docs: Service Worker API.

Como as solicitações são resolvidas

Conforme descrito na seção Estratégia de busca Cache-first , o operador de serviço padrão usa uma estratégia cache-first , o que significa que ele tenta fornecer conteúdo armazenado em cache quando disponível. Se não houver conteúdo armazenado em cache para uma determinada URL, por exemplo, ao solicitar dados de uma API de back-end, o operador de serviço recorrerá a uma solicitação de rede regular. A solicitação de rede será bem-sucedida se o servidor estiver acessível. Esta lógica é implementada dentro da função onFetch dentro do service-worker.published.js.

Se os componentes do Razor aplicativo dependem da solicitação de dados de APIs de back-end e você deseja fornecer uma experiência de usuário amigável para solicitações com falha devido à indisponibilidade da rede, implemente a lógica nos componentes do aplicativo. Por exemplo, use try/catch à volta das HttpClient solicitações.

Suporte a páginas renderizadas pelo servidor

Considere o que acontece quando o usuário navega pela primeira vez para uma URL como /counter ou qualquer outro link profundo no aplicativo. Nesses casos, não se deseja retornar o conteúdo armazenado em cache como /counter, mas sim que o navegador carregue o conteúdo armazenado em cache como /index.html para iniciar a sua Blazor WebAssembly aplicação. Essas solicitações iniciais são conhecidas como solicitações de navegação , em oposição a:

• subresource solicitações de imagens, folhas de estilo ou outros arquivos.
• fetch/XHR solicitações de dados de API.

O service worker padrão contém lógica especial para pedidos de navegação. O service worker resolve as solicitações retornando o conteúdo armazenado em cache para /index.html, independentemente da URL solicitada. Esta lógica é implementada na função onFetch dentro do service-worker.published.js.

Se o seu aplicativo tiver determinadas URLs que devem retornar HTML renderizado pelo servidor e não servir /index.html a partir do cache, você precisará editar a lógica no seu service worker. Se todas as URLs que contêm /Identity/ precisarem ser tratadas como solicitações regulares somente on-line para o servidor, modifique service-worker.published.jsonFetch a lógica. Localize o seguinte código:

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

Altere o código para o seguinte:

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

Se não fizeres isto, independentemente da conectividade de rede, o service worker intercetará solicitações para essas URLs e as resolverá usando /index.html.

Adicione pontos de extremidade adicionais para provedores de autenticação externos ao processo de verificação. No exemplo a seguir, a autenticação do Google /signin-google é adicionada à verificação:

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

Não é necessária nenhuma ação para o ambiente Development, onde o conteúdo é sempre obtido da rede.

Controlar o cache de elementos

Se o seu projeto definir a propriedade ServiceWorkerAssetsManifest MSBuild, as ferramentas de compilação do Blazor geram um manifesto de ativos do trabalhador de serviço com o nome especificado. O modelo padrão do PWA produz um arquivo de projeto contendo a seguinte propriedade:

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

O arquivo é colocado no wwwroot diretório de saída, para que o navegador possa recuperar esse arquivo solicitando /service-worker-assets.js. Para ver o conteúdo deste arquivo, abra /bin/Debug/{TARGET FRAMEWORK}/wwwroot/service-worker-assets.js em um editor de texto. No entanto, não edite o arquivo, pois ele é regenerado em cada compilação.

O manifesto enumera:

• Todos os Blazorrecursos gerenciados, como assemblies .NET e os arquivos de tempo de execução do .NET WebAssembly necessários para funcionar offline.
• Todos os recursos para publicação no diretório do aplicativo, como imagens, folhas de estilo e arquivos JavaScript, incluindo ativos da Web estáticos wwwroot fornecidos por projetos externos e pacotes NuGet.

Você pode controlar quais desses recursos são buscados e armazenados em cache pelo operador de serviço editando a lógica em onInstallservice-worker.published.js. O service worker busca e armazena em cache ficheiros que correspondem a extensões típicas de nome de ficheiro da Web, como .html, .css, .js e .wasm, além de tipos de ficheiros específicos para Blazor WebAssembly, como ficheiros .pdb (todas as versões) e ficheiros .dll (ASP.NET Core no .NET 7 ou anterior).

Para incluir recursos adicionais que não estão presentes no diretório do wwwroot aplicativo, defina entradas MSBuild ItemGroup extras, conforme mostrado no exemplo a seguir:

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

Os AssetUrl metadados especificam a URL relativa à base que o navegador deve usar ao buscar o recurso para cache. Isso pode ser independente do nome do arquivo de origem original no disco.

Importante

Adicionar um ServiceWorkerAssetsManifestItem não faz com que o arquivo seja publicado no diretório do wwwroot aplicativo. A saída de publicação deve ser controlada separadamente. Apenas o ServiceWorkerAssetsManifestItem faz com que uma entrada adicional apareça no manifesto de ativos do service worker.

Notificações push

Como qualquer outro PWA, um Blazor WebAssembly PWA pode receber notificações push de um servidor back-end. O servidor pode enviar notificações por push a qualquer momento, mesmo quando o usuário não está usando ativamente o aplicativo. Por exemplo, as notificações push podem ser enviadas quando um usuário diferente executa uma ação relevante.

Advertências para PWAs offline

Nem todas as aplicações devem tentar suportar a utilização offline. O suporte offline adiciona complexidade significativa, embora nem sempre seja relevante para os casos de uso necessários.

Normalmente, o suporte offline só é relevante:

• Se o armazenamento de dados primário for local no navegador. Por exemplo, a abordagem é relevante em um aplicativo com uma interface do usuário para um dispositivo IoT que armazena dados no localStorage ou IndexedDB.
• Se a aplicação realizar um trabalho significativo para buscar e armazenar em cache os dados da API de back-end relevantes para cada utilizador, permitindo-lhes navegar pelos dados offline. Se o aplicativo precisar oferecer suporte à edição, um sistema para rastrear alterações e sincronizar dados com o back-end deverá ser criado.
• Se o objetivo é garantir que o aplicativo seja carregado imediatamente, independentemente das condições da rede. Implemente uma experiência de usuário adequada em torno de solicitações de API de back-end para mostrar o progresso das solicitações e se comportar normalmente quando as solicitações falharem devido à indisponibilidade da rede.

Além disso, as PWAs que suportam modo offline devem lidar com uma série de complicações adicionais. Os desenvolvedores devem se familiarizar cuidadosamente com as advertências nas seções a seguir.

Suporte offline apenas quando publicado

Durante o desenvolvimento, você normalmente deseja ver cada alteração refletida imediatamente no navegador sem passar por um processo de atualização em segundo plano. Portanto, o modelo PWA de Blazor habilita o suporte offline somente quando publicado.

Ao criar um aplicativo com capacidade offline, não é suficiente testar o aplicativo no Development ambiente. Você deve testar o aplicativo em seu estado publicado para entender como ele responde a diferentes condições de rede.

Conclusão da atualização após a navegação do usuário fora do aplicativo

As atualizações não são concluídas até que o utilizador tenha navegado para fora da aplicação em todas as abas. Conforme explicado na seção Atualizações em segundo plano , depois de implantar uma atualização no aplicativo, o navegador busca os arquivos de trabalho de serviço atualizados para iniciar o processo de atualização.

O que surpreende muitos desenvolvedores é que, mesmo quando esta atualização é concluída, ela não se torna efetiva até que o utilizador tenha saído de todas as abas. Não é suficiente atualizar a guia que exibe o aplicativo, mesmo que seja a única guia que exibe o aplicativo. Até que seu aplicativo seja completamente fechado, o novo operador de serviço permanece aguardando para ativar o status. Isso não é específico do Blazor, mas é um comportamento padrão da plataforma da Web.

Isso geralmente incomoda os desenvolvedores que estão tentando testar atualizações para seu operador de serviço ou recursos armazenados em cache offline. Se você verificar as ferramentas de desenvolvedor do navegador, poderá ver algo como o seguinte:

Enquanto a lista de "clientes", que são guias ou janelas exibindo seu aplicativo, não estiver vazia, o trabalhador continuará esperando. A razão pela qual os trabalhadores de serviços fazem isso é para garantir a consistência. Consistência significa que todos os recursos são buscados do mesmo cache atômico.

Ao testar as alterações, você pode achar conveniente selecionar o link "skipWaiting", como mostrado na captura de tela anterior, e recarregar a página. Você pode automatizar isso para todos os utilizadores ao programar o seu "service worker" para ignorar a fase de "espera" e ativar imediatamente quando houver uma atualização. Se você pular a fase de espera, estará abrindo mão da garantia de que os recursos são sempre buscados consistentemente da mesma instância de cache.

Os usuários podem executar qualquer versão histórica do aplicativo

Os desenvolvedores da Web normalmente esperam que os usuários executem apenas a versão implantada mais recente de seu aplicativo Web, já que isso é normal dentro do modelo de distribuição da Web tradicional. No entanto, um PWA offline é mais parecido com um aplicativo móvel nativo, onde os usuários não estão necessariamente executando a versão mais recente.

Conforme explicado na seção Atualizações em segundo plano , depois de implantar uma atualização em seu aplicativo, cada usuário existente continua a usar uma versão anterior por pelo menos mais uma visita, porque a atualização ocorre em segundo plano e não é ativada até que o usuário navegue para longe. Além disso, a versão anterior que está sendo usada não é necessariamente a anterior que você implantou. A versão anterior pode ser qualquer versão histórica, dependendo de quando o usuário concluiu uma atualização pela última vez.

Isso pode ser um problema se as partes de front-end e back-end do seu aplicativo exigirem um acordo sobre o esquema para solicitações de API. Você não deve implantar alterações de esquema de API incompatíveis com versões anteriores até ter certeza de que todos os usuários atualizaram. Como alternativa, impeça os usuários de usar versões mais antigas incompatíveis do aplicativo. Esse requisito de cenário é o mesmo que para aplicativos móveis nativos. Se implantares uma alteração significativa nas APIs do servidor, o aplicativo cliente ficará quebrado para os utilizadores que ainda não tiverem atualizado.

Se possível, não implante alterações significativas em suas APIs de back-end. Se você precisar fazer isso, considere usar APIs padrão do Service Worker, como ServiceWorkerRegistration , para determinar se o aplicativo está up-to-date e, se não, para impedir o uso.

Interferência com páginas renderizadas pelo servidor

Conforme descrito na seção Páginas renderizadas pelo servidor de suporte , se você quiser ignorar o comportamento do trabalhador de serviço de retornar /index.html conteúdo para todas as solicitações de navegação, edite a lógica no trabalhador de serviço.

Todos os conteúdos do manifesto de ativos do trabalhador de serviço são armazenados em cache

Conforme descrito na seção Cache de ativos de controle , o arquivo service-worker-assets.js é gerado durante a compilação e lista todos os ativos que o trabalhador de serviço deve buscar e armazenar em cache.

Como esta lista inclui tudo o que é emitido para wwwroot, incluindo conteúdo fornecido por pacotes e projetos externos, deve-se ter cuidado para não colocar demasiado conteúdo lá. Se o wwwroot diretório contiver milhões de imagens, o service worker tentará buscar e armazenar em cache todas elas, consumindo largura de banda excessiva e, muito provavelmente, não concluindo com êxito.

Implemente lógica arbitrária para controlar qual subconjunto do conteúdo do manifesto deve ser buscado e armazenado em cache editando a onInstall função em service-worker.published.js.

Interação com autenticação

O modelo PWA pode ser usado em conjunto com a autenticação. Um PWA com capacidade offline também pode oferecer suporte à autenticação quando o usuário tem conectividade de rede inicial.

Quando um usuário não tem conectividade de rede, ele não pode autenticar ou obter tokens de acesso. A tentativa de visitar a página de login sem acesso à rede resulta em uma mensagem de "erro de rede". Você deve projetar um fluxo de interface do usuário que permita que o usuário execute tarefas úteis enquanto estiver off-line sem tentar autenticar o usuário ou obter tokens de acesso. Como alternativa, você pode projetar o aplicativo para falhar normalmente quando a rede não estiver disponível. Se o aplicativo não puder ser projetado para lidar com esses cenários, talvez você não queira habilitar o suporte offline.

Quando uma aplicação concebida para utilização online e offline está novamente online:

• O aplicativo pode precisar provisionar um novo token de acesso.
• O aplicativo deve detetar se um usuário diferente está conectado ao serviço para que ele possa aplicar operações à conta do usuário que foram feitas enquanto estavam offline.

Para criar um aplicativo PWA offline que interage com a autenticação:

• Substitua o AccountClaimsPrincipalFactory<TAccount> por uma fábrica que armazena o último usuário conectado e usa o usuário armazenado quando o aplicativo está offline.
• Encaminhe operações enquanto a aplicação estiver offline e aplique-as quando a aplicação voltar a ficar online.
• Durante o logout, limpe o usuário armazenado.

O CarChecker aplicativo de exemplo demonstra as abordagens anteriores. Veja as seguintes partes do aplicativo:

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

Recursos adicionais

SignalR