Next.js: Premier support hors ligne

Créé le 23 janv. 2017  ·  47Commentaires  ·  Source: vercel/next.js

Le support hors ligne est très utile et crucial pour créer une PWA moderne. Avec les manifestes HTML, il aide à combler le fossé entre un site Web et une application native.

Cette fonctionnalité a deux saveurs différentes :

  • Prise en charge hors ligne : il s'agit de la possibilité de naviguer sur le site même hors ligne, si le site a été chargé en ligne. Cela devrait être la fonctionnalité la plus simple à mettre en œuvre.

  • Premier support hors ligne : Il s'agit de la possibilité d'ouvrir le site même hors ligne, même si le site n'a pas été chargé dans le navigateur.

Les deux devraient être faisables grâce au plugin webpack-offline . Quoi qu'il en soit, depuis que j'apprends à la fois React et Next.js, je n'ai pas encore réussi à le faire fonctionner.

Étapes pour le faire fonctionner :

  • Installer webpack-offline

npm install offline-plugin --save-dev

  • Créez un next.config.js dans votre dossier racine
const OfflinePlugin = require('offline-plugin');

module.exports = {
  webpack: (config, { dev }) => {
        config.plugins = [
            new OfflinePlugin()
        ];
    return config
  }
};

  • Initialiser webpack-offline

C'est l'étape qui me pose problème. Je pense que vous devriez le faire dans un composant, à l'intérieur de componentDidMount , à l'intérieur du niveau supérieur.

Ce problème est à la fois un rappel pour moi de continuer à travailler sur ce sujet et une demande d'aide de la part de quelqu'un de plus compétent.

feature request

Commentaire le plus utile

Hé les gens. Mon équipe chez Google travaille sur quelques bibliothèques Service Worker (avec des plugins Webpack) comme https://github.com/GoogleChrome/sw-precache et https://github.com/GoogleChrome/sw-toolbox utilisées sur React/Webpack heavy des sites comme Lyft, Housing.com, Flipkart, etc.

Si Next décide d'explorer le support hors ligne, nous serions heureux de partager quelques conseils. Je pense qu'il existe une excellente opportunité de prescrire des modèles tels que PRPL prêts à l'emploi, étant donné que la division du code est déjà en cours. La mise en cache des Service Worker uniquement pour la production serait un ajout intéressant.

En plus de vous donner des charges répétées instantanées pour ces pages, cela vous permettrait également d'opter très tôt pour la mise en cache du code de V8 afin que vos temps d'analyse/compilation pour les visites répétées soient inférieurs à ceux d'aujourd'hui.

N'hésitez pas à crier si tout cela est intéressant @rauchg :)

Tous les 47 commentaires

J'aimerais vraiment voir cela fonctionner aussi, avec des explications/documentation/exemple à ce sujet.

Notez que next/prefetch n'autorise pas encore vraiment le comportement hors ligne, car il ne précharge pas les données : https://github.com/zeit/next.js/issues/740

Pas directement lié à Next.js, mais je me demande également combien de données peuvent réellement être conservées hors ligne (par exemple, si une application Web contient des vidéos, etc. - y a-t-il une limite stricte dans le navigateur ? Et qu'en est-il du mobile ?), comment l'utilisateur pourrait-il spécifiquement demander qu'une chose soit pré-téléchargée pour plus tard, etc. J'ai également déjà mentionné des choses ici: https://github.com/zeit/next.js/issues/24#issuecomment -258804529 (before next/prefetch was a thing ).

Les limites de données varient selon les plates-formes, les navigateurs et les versions. Vous pouvez tester les limites dans le "Browser storage abuser": https://demo.agektmr.com/storage/

La méthode standardisée destinée au stockage et à la mise en cache hors ligne est IndexedDB. Il est désormais pris en charge même dans iOS Safari (v10), mais il présente des problèmes de performances. Sinon, il bénéficie désormais d'un large support : http://caniuse.com/#feat =indexeddb

Par exemple, PouchDB utilise toujours WebSQL au lieu d'IndexedDB sur Safari. https://github.com/pouchdb/pouchdb/issues/5572
Idem avec localForage : https://github.com/localForage/localForage/issues/604

PouchDB a un bon résumé des limites de données : https://pouchdb.com/faq.html#data_limits (un peu obsolète)
Et cet article encore plus ancien mentionne également comment gérer certaines erreurs de stockage et d'autres aspects concernant les navigateurs mobiles https://www.html5rocks.com/en/tutorials/offline/quota-research/

Vous pouvez également rechercher votre quota actuel et demander un stockage plus persistant dans certains navigateurs : https://jakearchibald.com/2014/offline-cookbook/#cache -persistence

Une autre façon serait d'utiliser des valeurs d'expiration de cache longues et un contrôle de cache immuable avec les techniciens de maintenance. Cela permettrait facilement la mise en cache spécifiée par l'utilisateur, simplement en faisant une requête http pour chaque ressource sélectionnée. Cela fonctionnerait également très bien dans les anciens navigateurs. Mais pouvoir conserver et supprimer manuellement divers caches pour éviter les limites ne serait possible que dans les navigateurs prenant en charge les techniciens de maintenance.
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

N'oubliez pas que lorsque vous manquez d'espace, le navigateur peut supprimer une origine entière à la fois jusqu'à ce qu'elle soit dans les limites :
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

Un autre article utile d'Addy Osmani : https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c#.9vja3t8gp

Apparemment, une API de stockage est également en cours de travail : https://storage.spec.whatwg.org/

Cela permet en fait un stockage persistant :
"Traditionnellement, lorsque l'utilisateur manque d'espace de stockage sur son appareil, les données stockées avec ces API se perdent sans que l'utilisateur puisse intervenir. Cependant, les boîtes persistantes ne peuvent pas être effacées sans le consentement de l'utilisateur. Cela apporte ainsi des garanties de données aux utilisateurs ont apprécié sur les plates-formes natives du Web."

IMO faire fonctionner un site/une application hors ligne implique de nombreuses décisions qu'un framework ne devrait pas prendre par lui-même. Je vais travailler sur un exemple sur un site travaillant hors ligne avec un technicien de maintenance, mais il existe différentes techniques pour différents types d'applications.

merci @impronunciable . Prévoyez-vous d'utiliser webpack-offline ou autre chose ?

de quel genre de décisions parles-tu ? Je pense qu'on peut diviser le problème en deux points principaux :

1) Mise en cache des actifs statiques : comme js, HTML, images, ... c'est presque déjà implémenté, du moins dans la version hors ligne et à l'exclusion de /static , et étant donné que nous utilisons React, cela devrait avoir une implémentation préférée, via webpack-offline et service workers.

2) La mise en cache des données : état, requêtes, données volatiles, .... posent plus de soucis, car cela nécessite au moins de présumer comment les utilisateurs vont charger les données. Peut-être pourrions-nous montrer comment préserver l'état avec le redux, puis les gens mettront les données en redux comme ils le souhaitent. Ou peut-être pourrions-nous utiliser GraphQL/Apollo qui devrait couvrir un tel cas en mettant en cache les requêtes et les mutations.

@servermeta cela dépend vraiment de votre cas. Je termine la mise en œuvre d'une stratégie de mise en cache agressive sans utiliser de plugins, juste un serveur personnalisé et une stratégie de https://serviceworke.rs/

Je l'ai fait fonctionner ici . J'ai beaucoup lutté avec Offline-Plugin, j'ai eu quelques problèmes avec le répertoire .next, puis je suis passé à sw-precache-webpack-plugin, j'ai ignoré le répertoire .next et j'ai servi tous les actifs au sw

merci @ooade , bravo, tu m'as fait gagner beaucoup de temps.

Quoi qu'il en soit, je vois que cet état ne persiste pas entre les actualisations, les rechargements. Je vais essayer de réfléchir à comment ajouter cette fonctionnalité.

merci @ooade . Par localhost, vous entendez une base de données locale, comme mongodb, ou localstorage ?

Je pense que nous devrions diviser le problème : la récupération des données hors ligne devrait être laissée au développeur, tandis que nous pourrions préserver l'état de redux. Vérifie ça:

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

avec cela, nous pouvons stocker l'état dans le stockage local, afin qu'il puisse persister entre les actualisations, les rechargements, les onglets et les sessions.

Hé les gens. Mon équipe chez Google travaille sur quelques bibliothèques Service Worker (avec des plugins Webpack) comme https://github.com/GoogleChrome/sw-precache et https://github.com/GoogleChrome/sw-toolbox utilisées sur React/Webpack heavy des sites comme Lyft, Housing.com, Flipkart, etc.

Si Next décide d'explorer le support hors ligne, nous serions heureux de partager quelques conseils. Je pense qu'il existe une excellente opportunité de prescrire des modèles tels que PRPL prêts à l'emploi, étant donné que la division du code est déjà en cours. La mise en cache des Service Worker uniquement pour la production serait un ajout intéressant.

En plus de vous donner des charges répétées instantanées pour ces pages, cela vous permettrait également d'opter très tôt pour la mise en cache du code de V8 afin que vos temps d'analyse/compilation pour les visites répétées soient inférieurs à ceux d'aujourd'hui.

N'hésitez pas à crier si tout cela est intéressant @rauchg :)

Le support hors ligne de

@rauchg une estimation concernant la date de sortie stable 2.0 ?
Nous sommes sur le point de lancer une production complète et nous aimerions utiliser Next.js
J'apprécierai tout type d'estimation, jours/semaines/mois...
Merci beaucoup!

@Ajar-Ajar 2.0.0 est sorti aujourd'hui.

@rauchg est-ce que le support hors ligne sera suivi ici ou allez-vous créer un autre problème pour lui ?

Veuillez également consulter le nouveau redux-offline open source de @jevakallio. Ce serait génial d'avoir un exemple suivant + redux-offline.

Alors, avons-nous des informations sur la façon d'y parvenir, j'ai essayé de le faire avec next.config.js et d'installer le plugin hors ligne, mais je n'ai pas pu le faire fonctionner. Next est un projet génial mais il serait super complet (et plus cool) s'il avait cette fonctionnalité (hors ligne d'abord) prête à l'emploi !

@saulflores95 L' utilisation de la méthode NextSimpleStarter de @ooade a fonctionné pour moi :)

@AugustinLF NextSimpleStarter n'offre pas de fonctionnalités hors ligne. https://github.com/ooade/NextSimpleStarter/issues/23#issuecomment-294310240

@sedubois Pour tous ceux qui viennent et lisent ceci, c'est un peu exagéré. Pour être juste, il a des capacités hors ligne avec l'utilisation de sw-precache et sw-toolbox. Mon application fonctionne hors ligne uniquement avec ces deux outils, mais l'état initial de mon application ne change pas. Si j'essayais d'être précis, je pourrais dire qu'il n'offre pas de solutions hors ligne pour construire un état au-delà de ce qui a été initialement envoyé sur le fil.

@timmywil , avez-vous un dépôt GitHub de votre application compatible hors ligne nextjs ? Merci.

Je viens de créer une version (bêta) de la prochaine prise en charge hors ligne en utilisant appcache , ce qui est nécessaire pour Safari. Veuillez consulter http://github.com/ssured/nownextmicro

Salut à tous, j'ai ajouté le support hors ligne à mon passe-partout.
https://github.com/Sly777/ran

C'est un peu buggé. C'est pourquoi il est nommé "expérimental" 😄 Quoi qu'il en soit, j'espère que cela vous aidera.

@rauchg Cette fonctionnalité est-elle toujours une priorité ?

@rauchg Avec la version bêta de next.js 4.0, y a-t-il des chances que le premier support hors ligne soit dans la feuille de route pour cette version ?

Je demanderais des nouvelles de la fonctionnalité ^^

Next.js 5.0 est sorti (félicitations !) mais il n'y a aucune mention de support hors ligne, y a-t-il une nouvelle feuille de route que vous aimeriez partager ? merci pour le travail incroyable fait jusqu'à présent

@idhard en fait, nous ne
(Mais les choses pourraient changer)

Mais nous sommes en train de nous assurer que Next.js ne fait pas de magie. Ainsi, vous pourrez utiliser les plugins et les chargeurs Webpack directs tels quels.
Le 5 suivant est la première étape.

@idhard Je pense que ce serait contre-intuitif pour une prise en charge globale hors ligne, certaines applications ne voudront certainement pas que cette fonctionnalité soit activée.

Sur mon site personnel, j'utilise ceci https://github.com/zeit/next.js/tree/canary/examples/with-sw-precache et nous allons également utiliser ^ en production chez Eaze une fois iOS 11.3 est publié.

@hanford ouais une discussion similaire a été faite sur CRA et finit par supprimer la prise en charge des webworkers par défaut (https://github.com/facebook/create-react-app/issues/2554#event-1431558318), mais je pense toujours aux webworkers et PWA vont être la solution de facto pour le support hors ligne, il serait donc bon de savoir si l'équipe de Next a l'intention d'ajouter un support officiel, comme des pages pré-extraites.

@idhard ouais, une sorte de dilemme intéressant pour l'équipe principale. J'ai été très satisfait du plugin sw-precache que j'ai mentionné ci-dessus.

mon site Web personnel utilise le plugin sw-precache webpack, en plus de servir un manifest.json partir du répertoire statique. Si vous êtes curieux, le code est ici .. les commits sont un peu bâclés, mais j'ai ajouté le support hors ligne et le manifeste json au cours de la semaine dernière.

@hanford que se passe-t-il dans iOS 11.3, y aura-t-il des

@hanford @idhard nous avons essayé les travailleurs de service bien avant l'ARC et avons eu beaucoup de problèmes.
C'est pourquoi nous avons décidé de créer une solution de préchargement purement avec la technologie de mise en cache Web traditionnelle.
Cela fonctionne incroyablement bien. Une nouvelle série d'améliorations est à venir.

Oui, bien sûr, hors ligne, nous avons besoin de SW.
Mais c'est une API très instable et difficile à utiliser. Les choses pourraient mal tourner et casser votre site.

Donc, nous ne voulons peut-être pas le faire nous-mêmes.
Mais nous voulons permettre aux utilisateurs d'utiliser des choses comme sw-precache via le plugin Next.js (ou simplement en ajoutant un ensemble de chargeurs et de plugins webpack)

@sedubiois voir https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html pour les plans Apple sur iOS Safari. Les travailleurs de service sont annoncés

Oui, les techniciens de @ssured @sedubois arrivent dans Mobile Safari sous iOS 11.3, ce qui est plutôt excitant ! Je suis sur iOS 11.3 Beta 2 et il y a de nombreux bugs (les techniciens ne sont pas reconnus correctement lorsque le site Web est ajouté à l'écran d'accueil, mais je suis convaincu qu'Apple les corrigera avant la sortie publique)

Je pense que @arunoda suggère que la stratégie de mise en cache actuelle de Next.js (en-têtes de contrôle de cache, etags, etc.) est beaucoup plus stable que les agents de service. Les techniciens de maintenance activent cependant de nouvelles fonctionnalités vraiment intéressantes, en particulier en obtenant un contrôle plus fin des requêtes réseau (retour rapide du contenu mis en cache).

@ssured @sedubois J'ai fait un petit plugin qui fonctionne de la même manière que les plugins que Zeit a lancé l'autre jour .. il devrait alléger les prochaines applications hors ligne et être assez simple à brancher sur vos applications existantes

Faites-moi savoir si vous avez des commentaires! https://github.com/hanford/next-offline

@hanford merci de nous avoir rendu la vie un peu plus facile
@arunoda Bien que la prise en charge des plugins dans next.js 5 soit géniale, ne serait-il pas beaucoup plus bénéfique pour la communauté si tous les plugins sont hébergés dans les principaux dossiers de plugins du référentiel next.js, tout comme tous les exemples, au lieu d'un auxiliaire dépôt ? La plupart des développeurs visitent le référentiel principal et, par conséquent, les développeurs de plugins potentiels seraient beaucoup plus incités à créer une demande d'extraction, économisant ainsi le temps perdu de la communauté en raison de la répétition et de la fragmentation inévitable de l'écosystème des plugins résultant de repos séparés.

Pour tous ceux qui décident encore de ce qu'il faut faire à l'avenir, j'ai également utilisé le plugin webpack sw-precache avec une relative facilité (par exemple, encore une fois ).

J'utilisais ma propre solution mais je suis passé à la solution fournie par hanford. J'ai dû apporter quelques modifications dans next.config.js pour arrêter le plugin d'enregistrer automatiquement le service worker, mais cela semble bien fonctionner.

J'ai maintenant juste besoin de comprendre comment je peux faire fonctionner cela avec mon serveur personnalisé. Par exemple, j'ai une configuration d'itinéraire en tant qu'article/:slug. Lorsque je visite l'une de ces URL, le technicien essaie d'envoyer un document pour cette URL. Est-ce que quelqu'un sait comment je peux arrêter cela et lui faire servir l'article à la place ? Ceci est lié aux paramètres de Workbox, je suppose.

Doit-on toujours s'attendre à une intégration de service workers ou à un support hors ligne dans les futures versions de NextJS ? On dirait que certaines personnes disaient auparavant que c'était une fonctionnalité prioritaire, mais ce problème est ouvert depuis plus d'un an et demi...

@caribou-code Je ne peux pas parler au nom de l'équipe Zeit de leurs plans pour Next.js, mais j'ai écrit ceci il y a quelque temps : https://github.com/hanford/next-offline qui vous permet de générer automatiquement un service worker qui fonctionnera hors ligne.

Je l'ai utilisé dans plusieurs applications et cela a plutôt bien fonctionné. Sous le capot, il utilise googles workbox, qui est un projet très excitant : https://developers.google.com/web/tools/workbox/

Quelques exemples où j'utilise next-offline :

@hanford J'utilisais juste next-offline avant de poster ici et c'est plutôt bien ! En fait, c'est la seule solution que j'ai réussi à mettre en œuvre jusqu'à présent qui fonctionne réellement. Bon travail!

Cependant, je voulais vraiment obtenir une solution fonctionnant avec sw-precache-webpack-plugin car il y a un exemple de cela dans le référentiel NextJS, bien que je ne sache pas comment le configurer pour le mettre en cache et servir tous mes fichiers Next via le travailleur de service. Ce plugin semble également être très populaire.

J'ai créé NextSimpleStarter il y a un an pour aider à résoudre ce problème . Mais j'ai remarqué que sw-precache à lui seul ne sera pas en mesure de répondre à la plupart des exigences hors ligne.

Bien que je ne l'ai pas encore mis à jour selon les normes actuelles (taille des icônes, etc.), ce que je corrigerai dans quelques jours. N'hésitez pas à l'essayer. Abandonnez un problème si vous ne le trouvez pas satisfaisant.

@hanford Cela a l'air génial. Il fonctionne pour moi en mode développement mais il n'y a pas de service worker dans ce mode. Je ne peux pas dire d'après votre fichier readme comment le faire fonctionner en mode production et avec un service worker et sans serveur de nœud. Je déploie également mon application sur Netlify et j'utilise next export . Mon application est totalement statique. Je n'ai aucun problème à ne pas utiliser next export si c'est un problème . Je ferai ce qui est le plus performant et ne coûte rien. C'est une application de passe-temps, donc je suis flexible.

@ooade Cela a l'air bien aussi, mais j'ai eu une erreur lors du démarrage. Changer "sans serveur" en "serveur" selon vos instructions a corrigé cette erreur, mais j'ai ensuite eu l'erreur suivante

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

@dancancro, vous devriez certainement pouvoir utiliser next-offline tout en utilisant next-export

Cela vous dérange d'ouvrir un numéro dans next-offline avec quelques étapes à reproduire afin que je puisse y jeter un œil plus approfondi ?

@hanford, je peux le faire si vous voulez, mais je n'ai rien fait de spécial et je ne suggère pas que le démarreur soit cassé. Les étapes pour reproduire le problème sont simplement vos instructions . Le seul problème est que je ne sais pas comment l'exécuter en mode production. À en juger par cette condition, un service worker n'est pas censé être enregistré en mode dev, donc ce qui s'est passé pour moi est un comportement attendu. J'ai juste besoin de quelques instructions - comment l'exécuter en mode production, et si next export est possible, alors comment exécuter du code statique rendu par le serveur en mode production avec next export .

@dancancro Je comprends, mais cette discussion ne devrait pas avoir lieu ici, ce n'est certainement pas un problème avec Next.js lui-même.

Veuillez ouvrir un problème ici et je serais heureux de jeter un œil / de répondre aux questions que vous pourriez avoir.

La communauté ne bénéficie pas si nous avons une discussion dans un problème/dépôt sans rapport

J'ai récemment créé un plugin PWA sans configuration facile à utiliser pour Next.js : next-pwa

Consultez l'exemple ici

Cette page vous a été utile?
0 / 5 - 0 notes