Use WorkBox com Next.js e
Ativar facilmente funcionalidade offline em seu aplicativo!
$ npm install --save next-offline$ yarn add next-offline Há duas coisas importantes para configurar, primeiro precisamos next-offline para embrulhar sua próxima configuração.
Se você ainda não o fez, crie um next.config.js em seu projeto.
// next.config.js
const withOffline = require ( 'next-offline' )
const nextConfig = {
...
}
module . exports = withOffline ( nextConfig )Em seguida, precisamos garantir que nosso aplicativo esteja atendendo adequadamente ao trabalhador do serviço, essa configuração depende de como você está hospedando seu aplicativo. Há documentação abaixo. Se você não estiver usando agora 2.0, o exemplo agora 1.0 deve funcionar na maioria das circunstâncias.
Como os trabalhadores de serviço são muito poderosos, a API tem algumas restrições incorporadas. Por exemplo, os trabalhadores de serviços devem ser atendidos no domínio em que estão sendo usados - você não pode usar uma CDN.
Você vai querer usar a API do servidor personalizada Next.js. A maneira mais fácil de fazer isso é criar um server.js que se parece com o seguinte:
const { createServer } = require ( 'http' )
const { join } = require ( 'path' )
const { parse } = require ( 'url' )
const next = require ( 'next' )
const app = next ( { dev : process . env . NODE_ENV !== 'production' } )
const handle = app . getRequestHandler ( )
app . prepare ( )
. then ( ( ) => {
createServer ( ( req , res ) => {
const parsedUrl = parse ( req . url , true )
const { pathname } = parsedUrl
// handle GET request to /service-worker.js
if ( pathname === '/service-worker.js' ) {
const filePath = join ( __dirname , '.next' , pathname )
app . serveStatic ( req , res , filePath )
} else {
handle ( req , res , parsedUrl )
}
} )
. listen ( 3000 , ( ) => {
console . log ( `> Ready on http://localhost: ${ 3000 } ` )
} )
} )Você pode ler mais sobre servidores personalizados no próximo.js docs
Se você não está hospedando agora, eu provavelmente seguiria a abordagem agora 1.0 porque a API do servidor personalizada pode ativar muita funcionalidade, simplesmente não funciona bem com agora 2.0? ♂️
Porque agora o 2.0 funciona tão diferente da versão anterior, o mesmo acontece com o funcionário do serviço. Existem algumas maneiras diferentes de fazer isso, mas eu recomendo conferir este aplicativo de exemplo agora2. As mudanças a serem cientes estão no agora.json e next.config.js.
Por padrão next-offline registrará um trabalhador de serviço no script abaixo, ele é adicionado automaticamente ao seu pacote do lado do cliente assim que withOffline for invocado.
if ( 'serviceWorker' in navigator ) {
window . addEventListener ( 'load' , function ( ) {
navigator . serviceWorker . register ( '/service-worker.js' , { scope : '/' } ) . then ( function ( registration ) {
console . log ( 'SW registered: ' , registration )
} ) . catch ( function ( registrationError ) {
console . log ( 'SW registration failed: ' , registrationError )
} )
} )
} Alternativa ao tempo de compilação, você pode assumir o controle do registro/não registro no código do seu aplicativo usando o módulo next-offline/runtime .
import { register , unregister } from 'next-offline/runtime'
class App extends React . Component {
componentDidMount ( ) {
register ( )
}
componentWillUnmount ( ) {
unregister ( )
}
. .
}Você pode optar por passar no caminho e no escopo dos trabalhadores do serviço, se necessário.
import { register , unregister } from 'next-offline/runtime'
class App extends React . Component {
componentDidMount ( ) {
/**
* Default service worker path is '/service-worker.js'
* Refer https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerContainer/register for default scope rules
*
*/
register ( '/sub_folder/service-worker.js' , { scope : '/sub_folder' } )
}
componentWillUnmount ( ) {
unregister ( )
}
. .
} Se você estiver lidando com o registro por conta própria, passe dontAutoRegisterSw para a próxima offline.
// next.config.js
const withOffline = require ( 'next-offline' )
module . exports = withOffline ( { dontAutoRegisterSw : true } ) Se você é novo no Workbox, recomendo ler este guia rápido-qualquer coisa dentro dos workboxOpts será passada para o workbox-webpack-plugin .
Defina um objeto workboxOpts em seu next.config.js e ele será passado para o Workbox-webpack-plugin. O Workbox é o que next-offline usa sob o capô para gerar o funcionário do serviço, você pode aprender mais sobre isso aqui.
// next.config.js
const withOffline = require ( 'next-offline' )
const nextConfig = {
workboxOpts : {
...
}
}
module . exports = withOffline ( nextConfig )Além das opções da caixa de trabalho, o Next-offline possui algumas opções incorporadas para fornecer um controle mais fino de grãos sobre como seu funcionário de serviço é gerado.
| Nome | Tipo | Descrição | Padrão |
|---|---|---|---|
| geraw | Booleano | If false, next-offline will not generate a service worker and will instead try to modify the file found in workboxOpts.swSrc using WorkBox's [Inject Plugin](https://developers.google.com/web/tools/workbox/modules/workbox-webpack-plugin#injectmanifest_plugin) | verdadeiro |
| Dontautoregistersw | Booleano | Se True, a próxima offline não levará automaticamente o script de registro para o código do aplicativo. Isso é necessário se você estiver usando o registro de tempo de execução ou estiver lidando com o registro por conta própria. | falso |
| devSwsrc | Corda | Caminho a ser registrado pela próxima offline durante o desenvolvimento. Por padrão, o próximo offline registrará um Noop durante o desenvolvimento | falso |
| GereateIndevMode | Booleano | Se for verdade, o trabalhador do serviço também será gerado no modo de desenvolvimento. Caso contrário, o trabalhador de serviço definido no devSwsrc será usado. | falso |
| RegisterSwPrefix | Corda | Se o seu funcionário de serviço não estiver no nível raiz do seu aplicativo, isso pode ajudá -lo a prefixar o caminho. Isso é útil se você quiser o seu funcionário de serviço em foobar.com/my/long/path/service-worker.js. Isso afeta o [escopo] (https://developers.google.com/web/ilt/pwa/introduction-to-service-worker#registration_and_scope) do seu trabalhador de serviço. | falso |
| escopo | Corda | Isso é passado para o trabalhador de serviço registrado automaticamente, permitindo aumentar ou diminuir o que o trabalhador do serviço tem controle. | "/" |
Por padrão, next-offline possui a seguinte estratégia de cache de tempo de execução. Se você personalizar next-offline com workboxOpts , o comportamento padrão não será passado para workbox-webpack-plugin . Este artigo é ótimo em quebrar várias receitas diferentes de cache.
{
runtimeCaching : [
{
urlPattern : / ^https?.* / ,
handler : 'NetworkFirst' ,
options : {
cacheName : 'offlineCache' ,
expiration : {
maxEntries : 200
}
}
}
]
} // next.config.js
const withOffline = require ( 'next-offline' )
module . exports = withOffline ( {
workboxOpts : {
runtimeCaching : [
{
urlPattern : / .png$ / ,
handler : 'CacheFirst'
} ,
{
urlPattern : / api / ,
handler : 'NetworkFirst' ,
options : {
cacheableResponse : {
statuses : [ 0 , 200 ] ,
headers : {
'x-test' : 'true'
}
}
}
}
]
}
} ) Se o seu aplicativo não viver na raiz do seu domínio, você poderá usar registerSwPrefix . Isso é útil se o seu aplicativo estiver em domain.com/my/custom/path, porque, por padrão, next-offline assume que seu aplicativo está no domain.com e tentará registrar domain.com/service-worker.js. Não podemos apoiar o uso assetPrefix porque os trabalhadores do serviço devem ser atendidos no domínio raiz. Para uma discriminação técnica nessa limitação, consulte o seguinte link: É possível servir os trabalhadores de serviço de origem CDN/remoto?
Por padrão, next-offline precederá todos os arquivos em emitido em emitido no Next.js Webpack e os estáticos definidos pelo usuário (dentro /static )-essencialmente tudo o que é exportado também.
Se você deseja incluir um pouco mais ou alterar a origem de seus arquivos estáticos, use as opções de caixa de trabalho especificadas:
workboxOpts: {
modifyURLPrefix : {
'app' : assetPrefix ,
} ,
runtimeCaching : { ... }
} Por padrão, next-offline adicionará um trabalhador de serviço sem operação no desenvolvimento. Se você deseja fornecer sua própria aprovação na opção FilePath à devSwSrc . Isso é particularmente útil se você deseja testar as notificações de push web em desenvolvimento, por exemplo.
// next.config.js
const withOffline = require ( 'next-offline' )
module . exports = withOffline ( {
devSwSrc : '/path/to/my/dev/service-worker.js'
} ) Você pode desativar esse comportamento definindo a opção generateInDevMode como true .
Em next [email protected], reescrevemos a funcionalidade de exportação para trabalhar em mais casos, de maneira mais confiável, com menos código graças a algumas das adições nas próximas 7.0.0!
Você pode ler mais sobre a exportação no Next.js Docs, mas o próximo offline deve apenas Work ™ iqu.
Se você estiver atualizando para a versão mais recente do next-offline recomendo olhar para o que foi adicionado/alterado dentro da Workbox em lançamentos 5.x, juntamente com a versão 4.0, que incluiu as mudanças de ruptura. A API do próximo offline não mudou, mas uma dependência central mudou!
Questões? Opinião? por favor, me avise
next-offline é um Lerna Monorepo que usa espaços de trabalho de fio. Depois de clonar o repo, execute o seguinte
$ yarn bootstrapIsso garantirá que sua versão de desenvolvimento da próxima offline seja simplificada nos exemplos e testes que devem permitir que você faça alterações rapidamente!
WWWWWW||WWWWWW
W W W||W W W
||
( OO )__________
/ |
/o o| MIT
___/||_||__||_|| *
|| || || ||
_||_|| _||_||
(__|__|(__|__|
Copyright © 2017-presente Jack Hanford, [email protected]
A permissão é concedida, gratuita, a qualquer pessoa que obtenha uma cópia deste software e arquivos de documentação associados (o 'software'), para lidar com o software sem restrição, inclusive sem limitação os direitos de usar, copiar, modificar, mesclar, publicar, distribuir, mobilizar o software e/ou vender cópias do software e permitir que as pessoas a quem
O aviso de direitos autorais acima e este aviso de permissão devem ser incluídos em todas as cópias ou em partes substanciais do software.
O software é fornecido 'como está', sem garantia de qualquer tipo, expresso ou implícito, incluindo, entre outros, as garantias de comercialização, aptidão para uma finalidade específica e não innoculação. Em nenhum caso os autores ou detentores de direitos autorais serão responsáveis por qualquer reclamação, danos ou outro passivo, seja em uma ação de contrato, delito ou não, decorrente de, fora ou em conexão com o software ou o uso ou outras negociações no software.