Next.js: Primeiro Suporte Off-line

Eu adoraria ver isso funcionando também, junto com explicações / documentação / exemplo sobre isso.

Observe que next / prefetch ainda não permite o comportamento off-line, porque não faz a pré-busca de dados: https://github.com/zeit/next.js/issues/740

Não está diretamente relacionado ao Next.js, mas também me pergunto quantos dados podem realmente ser mantidos off-line (por exemplo, se um aplicativo da web tem vídeos etc. - há algum limite rígido no navegador? E o celular?), Como o usuário poderia especificamente peça para fazer o pré-download de uma coisa para mais tarde, etc. Eu também mencionei coisas anteriormente aqui: https://github.com/zeit/next.js/issues/24#issuecomment -258804529 (antes da próxima / pré-busca era uma coisa )

Existem vários limites de dados em diferentes plataformas, navegadores e versões. Você pode testar os limites em "Abusador de armazenamento do navegador": https://demo.agektmr.com/storage/

O método padronizado que se destina ao armazenamento offline e cache é IndexedDB. Agora é compatível até mesmo com iOS Safari (v10), mas tem problemas de desempenho. Caso contrário, agora tem amplo suporte: http://caniuse.com/#feat = indexeddb

Por exemplo, PouchDB ainda usa WebSQL em vez de IndexedDB no Safari. https://github.com/pouchdb/pouchdb/issues/5572
O mesmo com localForage: https://github.com/localForage/localForage/issues/604

PouchDB tem um bom resumo dos limites de dados: https://pouchdb.com/faq.html#data_limits (um pouco desatualizado)
E este artigo ainda mais antigo também menciona como lidar com alguns erros de falta de armazenamento e outros aspectos relacionados aos navegadores móveis https://www.html5rocks.com/en/tutorials/offline/quota-research/

Você também pode consultar sua cota atual e solicitar mais armazenamento persistente em alguns navegadores: https://jakearchibald.com/2014/offline-cookbook/#cache -persistence

Outra maneira seria usar valores de expiração de cache longos e controle de cache imutável junto com service workers. Isso permitiria facilmente o armazenamento em cache especificado pelo usuário, apenas fazendo uma solicitação http para cada recurso selecionado. Isso também funcionaria muito bem em navegadores antigos. Mas ser capaz de manter e excluir manualmente vários caches para evitar limites só seria possível em navegadores que suportam service workers.
https://developer.mozilla.org/en-US/docs/Web/API/Cache
https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers

Lembre-se de que, quando você ficar sem espaço, o navegador pode despejar uma origem inteira de uma vez até que esteja dentro dos limites:
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

Outro artigo útil de Addy Osmani: https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c#.9vja3t8gp

Aparentemente, também há uma API de armazenamento sendo trabalhada: https://storage.spec.whatwg.org/

Isso permite o armazenamento realmente persistente:
“Tradicionalmente, à medida que o usuário fica sem espaço de armazenamento em seu dispositivo, os dados armazenados com essas APIs se perdem sem que o usuário possa intervir. No entanto, as caixas persistentes não podem ser limpas sem o consentimento do usuário. Isso, portanto, traz garantias de dados aos usuários desfrutaram em plataformas nativas para a web. "

IMO fazer um site / aplicativo funcionar offline envolve muitas decisões que um framework não deve tomar sozinho. Vou trabalhar em um exemplo em um site trabalhando offline com um service worker, mas existem diferentes técnicas para diferentes tipos de aplicativos.

obrigado @impronunciable . Você planeja usar webpack-offline ou outra coisa?

de que tipo de decisão você está falando? Acho que podemos dividir o problema em duas questões principais:

1) Cache de ativos estáticos: como js, ​​HTML, imagens, ... quase já está implementado, pelo menos no modo offline e com a exclusão de /static , e dado que estamos usando o react, deveria ter uma implementação preferencial, via webpack-offline e service workers.

2) Cache de dados: estado, consultas, dados voláteis, .... apresentam mais preocupações, pois pelo menos requer presumir como os usuários irão carregar os dados. Talvez pudéssemos mostrar como preservar o estado com redux, e então as pessoas colocarão os dados em redux como preferirem. Ou talvez pudéssemos usar GraphQL / Apollo, que deve cobrir esse caso, armazenando consultas e mutações em cache.

@servermeta realmente depende do seu caso. Estou terminando de implementar uma estratégia de cache agressiva sem usar plug-ins, apenas um servidor personalizado e uma estratégia de https://serviceworke.rs/

Eu tenho isso funcionando aqui . Lutei muito com o plugin offline, tive alguns problemas com o diretório .next, então mudei para sw-precache-webpack-plugin, ignorei o diretório .next e entreguei todos os recursos ao sw

obrigado @ooade , muito bem, você me economizou muito tempo.

De qualquer forma, vejo que o estado não persiste entre as atualizações, recarregamentos. Vou tentar pensar em como adicionar esse recurso.

obrigado @ooade . Por localhost você quer dizer um banco de dados local, como mongodb ou localstorage?

Acho que devemos dividir o problema: a recuperação de dados offline deve ser deixada para o dev, enquanto podemos preservar o estado de redux. Verifique isto:

https://github.com/rt2zz/redux-persist

com isso, podemos armazenar o estado no armazenamento local, para que ele possa persistir entre atualizações, recarregamentos, guias e sessões.

Ei pessoal. Minha equipe no Google trabalha em algumas bibliotecas de Service Worker (com plug-ins Webpack) como https://github.com/GoogleChrome/sw-precache e https://github.com/GoogleChrome/sw-toolbox usadas no React / Webpack heavy sites como Lyft, Housing.com, Flipkart etc.

Se a Next decidir explorar o suporte offline, ficaremos felizes em compartilhar algumas dicas. Acho que há uma grande oportunidade para prescrever padrões como PRPL fora da caixa, uma vez que a divisão de código já está sendo feita. O armazenamento em cache do Service Worker somente de produção seria uma adição interessante.

Além de fornecer carregamentos repetidos instantâneos para essas páginas, ele também incluiria você no cache de código do V8, para que seus tempos de análise / compilação para visitas repetidas fossem menores do que hoje.

Sinta-se à vontade para gritar se alguma dessas coisas for interessante @rauchg :)

@addyosmani o suporte off-line é uma de nossas principais prioridades pós-2.0 estável

@rauchg alguma estimativa sobre a data de lançamento estável do 2.0?
Estamos prestes a iniciar uma produção completa e adoraríamos usar Next.js
Agradeço qualquer tipo de estimativa, dias / semanas / meses ...
Muito obrigado!

@ Ajar-Ajar 2.0.0 foi lançado hoje.

@rauchg o suporte off-line primeiro será rastreado aqui ou você criará outro problema para ele?

Por favor, veja também o redux-offline de código-fonte aberto recentemente por @jevakallio. Seria incrível ter um próximo exemplo + redux-offline.

Então, temos alguma informação sobre como fazer isso? Estou tentando fazer o next.config.js e instalando o plugin offline, mas não consigo fazê-lo funcionar. O próximo é um projeto incrível, mas seria supercompleto (e mais legal) se tivesse esse recurso (off-line primeiro) pronto para uso!

@ saulflores95 Usar o método NextSimpleStarter de @ooade funcionou para mim :)

@AugustinLF NextSimpleStarter não oferece recursos offline. https://github.com/ooade/NextSimpleStarter/issues/23#issuecomment -294310240

@sedubois Para qualquer um que entre e leia isso, isso é um pouco exagero. Para ser justo, ele possui alguns recursos off-line com o uso de sw-precache e sw-toolbox. Meu aplicativo funciona offline apenas com essas duas ferramentas, mas o estado inicial do meu aplicativo não muda. Se eu estivesse tentando ser específico, poderia dizer que ele não oferece soluções off-line para construir um estado além do que foi inicialmente enviado pela rede.

@timmywil , você tem um repositório GitHub do seu app nextjs offline? Obrigado.

Acabei de criar uma versão (beta) do próximo suporte offline usando appcache , que é necessário para o Safari. Por favor, dê uma olhada em http://github.com/ssured/nownextmicro

Olá a todos, adicionei suporte offline ao meu boilerplate.
https://github.com/Sly777/ran

É um pouco bugado. É por isso que é chamado de "experimental" 😄 De qualquer forma, espero que ajude.

@rauchg Este recurso ainda é uma prioridade?

@rauchg Com next.js 4.0 beta lançado, há alguma chance de o primeiro suporte off-line estar no roteiro para essa versão?

Gostaria de pedir novidades sobre o recurso ^^

Next.js 5.0 foi lançado (parabéns!), Mas não há menção ao suporte offline. Existe um novo roteiro que você gostaria de compartilhar? obrigado pelo excelente trabalho feito até agora

@idhard na verdade, podemos não oferecer suporte off-line por padrão.
(Mas as coisas podem mudar)

Mas estamos em processo de garantir que Next.js não faça mágica. Assim, você poderá usar plug-ins e carregadores webpack diretos como estão.
O próximo 5 é o primeiro passo.

@idhard Acho que seria contra-intuitivo para suporte off-line geral, alguns aplicativos definitivamente não vão querer que esse recurso seja habilitado.

No meu site pessoal, estou usando https://github.com/zeit/next.js/tree/canary/examples/with-sw-precache e também usaremos ^ em produção no Eaze uma vez no iOS 11.3 é lançado.

@hanford sim, uma discussão semelhante foi feita no CRA e acabou removendo o suporte de webworkers por padrão (https://github.com/facebook/create-react-app/issues/2554#event-1431558318), no entanto, ainda acho que os webworkers e o PWA será a solução definitiva para suporte offline, então seria bom saber se a equipe do Next tem algum plano de adicionar um suporte oficial, como páginas pré-buscadas.

@idhard sim, meio que um dilema interessante para a equipe principal. Estou muito feliz com o plugin sw-pré-cache que mencionei acima.

meu site pessoal está usando o plugin sw-precache webpack, junto com um manifest.json do diretório estático. Se você está curioso, o código está aqui .. os commits são um pouco desleixados, mas adicionei suporte offline e o manifesto json na semana passada.

@hanford o que acontece no iOS 11.3, ele terá service workers? Você teria alguma referência com mais informações?

@hanford @idhard testamos os prestadores de serviço muito antes do CRA e tínhamos muitos problemas.
É por isso que decidimos construir uma solução de pré-busca puramente com a tecnologia tradicional de cache da web.
Funciona muito bem. Um novo conjunto de melhorias virá em breve.

Sim, claro que offline é um lugar que precisamos do SW.
Mas é muito instável e difícil de usar a API. As coisas podem dar errado e corromper seu site.

Portanto, podemos não querer fazer isso nós mesmos.
Mas queremos permitir que os usuários usem coisas como sw-precache por meio do plugin Next.js (ou simplesmente adicionando um conjunto de carregadores e plug-ins de pacotes da web)

@sedubiois consulte https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html para planos da Apple no iOS Safari. Trabalhadores de serviço são anunciados

Sim, os service workers @ssured @sedubois estão chegando ao Mobile Safari no iOS 11.3, que é muito empolgante! Estou no iOS 11.3 Beta 2 e há vários bugs (os service workers não são reconhecidos corretamente quando o site é adicionado à tela inicial, mas tenho certeza de que a apple corrigirá esses erros antes do lançamento ao público)

Acho que o que @arunoda está sugerindo é que Next.js a estratégia de cache atual (cabeçalhos de controle de cache, etags, etc.) é muito mais estável do que os service workers. Os service workers permitem algumas novas funcionalidades realmente interessantes, especialmente obtendo um controle mais preciso sobre as solicitações de rede (retornando o conteúdo em cache mais cedo). Mas o Next.js funciona em qualquer lugar e consideravelmente menos sobrecarga .. (cancelar o registro dos service workers é uma dor total)

@ssured @sedubois Eu fiz um pequeno plug-in que funciona da mesma maneira que os plug-ins que o Zeit lançou outro dia ... ele deve aliviar os próximos aplicativos off-line e ser bastante simples conectar-se aos aplicativos existentes

Deixe-me saber se você tem algum feedback! https://github.com/hanford/next-offline

@hanford obrigado por tornar nossa vida um pouco mais fácil
@arunoda Embora o suporte a plug-ins no next.js 5 seja incrível, não seria muito mais benéfico para a comunidade se todos os plug-ins estivessem hospedados nas pastas principais de plug-ins do repo next.js, assim como todos os exemplos, em vez de um auxiliar repo? A maioria dos desenvolvedores visita o repositório principal e, portanto, os desenvolvedores de plug-ins em potencial teriam muito mais incentivos para criar solicitação de pull, economizando tempo da comunidade devido à repetição e à fragmentação inevitável do ecossistema do plug-in como resultado de repositórios separados.

Para qualquer outra pessoa que ainda esteja decidindo o que fazer no futuro, também usei o plugin sw-precache webpack com relativa facilidade (por exemplo, novamente ).

Eu estava usando minha própria solução, mas mudei para a solução fornecida por Hanford. Tive que fazer algumas modificações em next.config.js para interromper o registro automático do plugin do service worker, mas parece estar funcionando bem.

Agora só preciso descobrir como posso fazer isso funcionar com meu servidor personalizado. Por exemplo, eu tenho uma configuração de rota como artigo /: slug. Quando visito um desses urls, o service worker está tentando despachar um documento para esse url. Alguém sabe como posso parar com isso e fazer com que sirva de artigo em vez disso? Isso está relacionado às configurações do Workbox, eu acho.

Ainda devemos esperar qualquer integração de service workers ou suporte offline em versões futuras do NextJS? Parece que algumas pessoas disseram que era um recurso prioritário, mas esse problema está aberto há mais de um ano e meio ...

@ caribou-code Não posso falar pela equipe Zeit sobre seus planos para Next.js, mas escrevi isso há algum tempo: https://github.com/hanford/next-offline que permite que você gere automaticamente um service worker que funcionará offline.

Usei em vários aplicativos e funcionou muito bem. Por baixo do capô, ele está utilizando a caixa de trabalho do Google, que é um projeto muito interessante: https://developers.google.com/web/tools/workbox/

Alguns exemplos onde uso next-offline :

• https://github.com/hanford/trends
• https://github.com/hanford/personal-website

@hanford Eu estava usando o next-offline antes de postar aqui e é muito bom! Na verdade, é a única solução que consegui implementar até agora que realmente funciona. Bom trabalho!

No entanto, eu realmente queria uma solução que funcionasse com sw-precache-webpack-plugin porque há um exemplo disso no repositório NextJS, embora eu não consiga descobrir como configurá-lo para armazenar em cache e servir todos os meus arquivos Next por meio o trabalhador de serviço. Esse plugin também parece ser bastante popular.

Criei o NextSimpleStarter há um ano para ajudar a resolver esse problema . Mas, percebi que o pré-cache sw sozinho não será capaz de atender à maioria dos requisitos off-line, então recentemente passamos a usar o workbox, que resolve a maioria deles.

Embora eu ainda esteja para atualizá-lo para os padrões atuais (tamanhos de ícones e assim por diante), que irei consertar em alguns dias. Sinta-se à vontade para fazer um teste. Abandone um problema se não o achar satisfatório.

@hanford Isso parece ótimo. Ele é executado para mim no modo de desenvolvimento, mas não há service worker nesse modo. Não posso dizer pelo seu leia-me como fazê-lo funcionar no modo de produção e com um service worker e sem um servidor de nó. Também implanto meu aplicativo no Netlify e estou usando next export . Meu aplicativo é totalmente estático. Não tenho nenhum problema em não usar next export se isso for um problema . Farei o que tiver melhor desempenho e não custar nada. É um aplicativo de hobby, então sou flexível.

@ooade Isso também parece ótimo, mas recebi um erro ao iniciá-lo. Alterar "sem servidor" para "servidor" de acordo com sua instrução corrigiu esse erro, mas recebi o seguinte erro

A bad HTTP response code (404) was received when fetching the script.

@dancancro você definitivamente deve ser capaz de usar next-offline enquanto também usa next-export

Importa-se de abrir um problema em next-offline com algumas etapas para reproduzir para que eu possa dar uma olhada mais detalhada?

@hanford , posso fazer isso se você quiser, mas não fiz nada de especial e não estou sugerindo que suas instruções . O único problema é que não sei como executá-lo em modo de produção. A julgar por esta condição, um service worker não deve estar registrado no modo dev, então o que aconteceu para mim é o comportamento esperado. Só preciso de algumas instruções - como executá-lo no modo de produção e, se next export for possível, como executar o código estático renderizado pelo servidor no modo de produção com next export .

@dancancro eu entendo, mas essa discussão não deveria estar acontecendo aqui, certamente não é um problema com o Next.js em si.

Abra um problema aqui e terei todo o gosto em ver / responder às suas perguntas.

A comunidade não se beneficia se tivermos uma discussão em um problema / repositório não relacionado

Recentemente criei um plugin PWA de configuração zero fácil de usar para Next.js: next-pwa

Confira o exemplo aqui