Next.js: Primer soporte sin conexión

Creado en 23 ene. 2017  ·  47Comentarios  ·  Fuente: vercel/next.js

El soporte sin conexión es muy útil y crucial para crear una PWA moderna. Junto con los manifiestos HTML, ayuda a cerrar la brecha entre un sitio web y una aplicación nativa.

Esta característica tiene dos sabores diferentes:

  • Soporte sin conexión: esta es la capacidad de navegar por el sitio incluso sin conexión, si el sitio se ha cargado mientras estaba en línea. Esta debería ser la característica más fácil de implementar.

  • Primera asistencia sin conexión: esta es la capacidad de abrir el sitio incluso sin conexión, incluso si el sitio no se ha cargado en el navegador.

Ambos deberían ser factibles gracias al complemento webpack-offline . De todos modos, desde que estoy aprendiendo React y Next.js a la vez, todavía no he podido hacer que funcione.

Pasos para que funcione:

  • Instalar webpack-offline

npm install offline-plugin --save-dev

  • Cree un next.config.js en su carpeta raíz
const OfflinePlugin = require('offline-plugin');

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

  • Inicializar webpack-offline

Este es el paso con el que tengo problemas. Creo que deberías hacerlo en un componente, dentro de componentDidMount , dentro del nivel superior.

Este problema es tanto un recordatorio para seguir trabajando en esto como una solicitud de ayuda de alguien más informado.

feature request

Comentario más útil

Hey gente. Mi equipo en Google trabaja en algunas bibliotecas de Service Worker (con complementos de Webpack) como https://github.com/GoogleChrome/sw-precache y https://github.com/GoogleChrome/sw-toolbox utilizadas en React / Webpack heavy sitios como Lyft, Housing.com, Flipkart, etc.

Si Next decide explorar el soporte sin conexión, estaremos encantados de compartir algunos consejos. Creo que hay una gran oportunidad para prescribir patrones como PRPL listos para

Además de brindarle cargas repetidas instantáneas para esas páginas, también lo optaría desde el principio en el almacenamiento en caché de código de V8, por lo que sus tiempos de análisis / compilación para visitas repetidas serían más bajos que en la actualidad.

Siéntete libre de gritar si algo de esto es interesante @rauchg :)

Todos 47 comentarios

Me encantaría ver que esto funcione también, junto con explicaciones / documentación / ejemplo al respecto.

Tenga en cuenta que next / prefetch todavía no permite el comportamiento fuera de línea, porque no prefetch datos: https://github.com/zeit/next.js/issues/740

No está directamente relacionado con Next.js, pero también me pregunto cuántos datos se pueden mantener sin conexión (por ejemplo, si una aplicación web tiene videos, etc., ¿hay algún límite estricto en el navegador? ¿Y qué pasa con los dispositivos móviles?), ¿Cómo podría el usuario específicamente pida que se descargue previamente una cosa para más tarde, etc. También mencioné cosas anteriormente aquí: https://github.com/zeit/next.js/issues/24#issuecomment -258804529 (antes de next / prefetch era una cosa ).

Existen límites de datos variables en diferentes plataformas, navegadores y versiones. Puede probar los límites en el "abusador del almacenamiento del navegador": https://demo.agektmr.com/storage/

El método estandarizado que está destinado al almacenamiento y almacenamiento en caché fuera de línea es IndexedDB. Ahora es compatible incluso con iOS Safari (v10), pero tiene problemas de rendimiento. De lo contrario, ahora tiene un amplio soporte: http://caniuse.com/#feat = indexeddb

Por ejemplo, PouchDB todavía usa WebSQL en lugar de IndexedDB en Safari. https://github.com/pouchdb/pouchdb/issues/5572
Lo mismo con localForage: https://github.com/localForage/localForage/issues/604

PouchDB tiene un buen resumen de los límites de datos: https://pouchdb.com/faq.html#data_limits (ligeramente desactualizado)
Y este artículo aún más antiguo también menciona cómo manejar algunos errores de almacenamiento y otros aspectos relacionados con los navegadores móviles https://www.html5rocks.com/en/tutorials/offline/quota-research/

También puede consultar su cuota actual y solicitar un almacenamiento más persistente en algunos navegadores: https://jakearchibald.com/2014/offline-cookbook/#cache -persistence

Otra forma sería utilizar valores de caducidad de caché largos y control de caché inmutable junto con los trabajadores del servicio. Esto permitiría fácilmente el almacenamiento en caché especificado por el usuario, simplemente haciendo una solicitud http para cada recurso seleccionado. Esto también funcionaría bastante bien en navegadores antiguos. Pero poder mantener y eliminar manualmente varios cachés para evitar límites solo sería posible en los navegadores que admitan a los trabajadores del servicio.
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

Solo recuerde, cuando se queda sin espacio, el navegador puede desalojar un origen completo a la vez hasta que esté dentro de los límites:
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

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

Aparentemente, también se está trabajando en una API de almacenamiento: https://storage.spec.whatwg.org/

Esto permite un almacenamiento realmente persistente:
"Tradicionalmente, cuando el usuario se queda sin espacio de almacenamiento en su dispositivo, los datos almacenados con estas API se pierden sin que el usuario pueda intervenir. Sin embargo, las casillas persistentes no se pueden borrar sin el consentimiento del usuario. Por lo tanto, los datos garantizan a los usuarios han disfrutado en plataformas nativas de la web ".

En mi opinión, hacer que un sitio / aplicación funcione sin conexión implica muchas decisiones que un marco no debería tomar por sí solo. Trabajaré en un ejemplo en un sitio que trabaja sin conexión con un trabajador del servicio, pero existen diferentes técnicas para diferentes tipos de aplicaciones.

gracias @impronunciable . ¿Planea usar webpack-offline u otra cosa?

¿De qué tipo de decisiones estás hablando? Creo que podemos dividir el problema en dos cuestiones principales:

1) Almacenamiento en caché de activos estáticos: como js, ​​HTML, imágenes, ... esto casi ya está implementado, al menos en el estilo fuera de línea y con la exclusión de /static , y dado que estamos usando react, debería tener una implementación preferida, a través de webpack-offline y service workers.

2) Almacenamiento en caché de datos: estado, consultas, datos volátiles, .... plantean más preocupaciones, ya que al menos requiere presumir cómo los usuarios cargarán los datos. Tal vez podríamos mostrar cómo preservar el estado con redux, y luego la gente pondrá los datos en redux como prefieran. O tal vez podríamos usar GraphQL / Apollo, que debería cubrir tal caso almacenando en caché consultas y mutaciones.

@servermeta realmente depende de tu caso. Estoy terminando de implementar una estrategia de almacenamiento en caché agresiva sin usar complementos, solo un servidor personalizado y una estrategia de https://serviceworke.rs/

Lo tengo funcionando aquí . Luché mucho con Offline-Plugin, tuve algunos problemas con el directorio .next, luego cambié a sw-precache-webpack-plugin, ignoré el directorio .next y entregué todos los activos al sw

gracias @ooade , bien hecho, me

De todos modos, veo que el estado no persiste entre actualizaciones y recargas. Intentaré pensar en cómo agregar esta función.

gracias @ooade . ¿Por localhost te refieres a una base de datos local, como mongodb, o localstorage?

Creo que deberíamos dividir el problema: la recuperación de datos fuera de línea debería dejarse al desarrollador, mientras que podríamos preservar el estado redux. Mira esto:

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

con esto podemos almacenar el estado en localstorage, por lo que puede persistir entre actualizaciones, recargas, pestañas y sesiones.

Hey gente. Mi equipo en Google trabaja en algunas bibliotecas de Service Worker (con complementos de Webpack) como https://github.com/GoogleChrome/sw-precache y https://github.com/GoogleChrome/sw-toolbox utilizadas en React / Webpack heavy sitios como Lyft, Housing.com, Flipkart, etc.

Si Next decide explorar el soporte sin conexión, estaremos encantados de compartir algunos consejos. Creo que hay una gran oportunidad para prescribir patrones como PRPL listos para

Además de brindarle cargas repetidas instantáneas para esas páginas, también lo optaría desde el principio en el almacenamiento en caché de código de V8, por lo que sus tiempos de análisis / compilación para visitas repetidas serían más bajos que en la actualidad.

Siéntete libre de gritar si algo de esto es interesante @rauchg :)

@addyosmani El soporte sin conexión es una de nuestras principales prioridades después de 2.0 estable

@rauchg ¿ alguna estimación con respecto a la fecha de lanzamiento estable 2.0?
Estamos a punto de iniciar una producción completa y nos encantaría usar Next.js
Agradeceré cualquier tipo de estimación, días / semanas / meses ...
¡Muchas gracias!

@ Ajar-Ajar 2.0.0 fue lanzado hoy.

@rauchg, ¿ se va a rastrear el soporte sin conexión primero aquí o va a crear otro problema para él?

Consulte también el nuevo redux-offline de código abierto de @jevakallio. Sería genial tener un siguiente ejemplo + redux-offline.

Entonces, ¿tenemos alguna información sobre cómo lograr esto? He intentado hacerlo en next.config.js e instalando el complemento sin conexión, pero no pude hacerlo funcionar. El siguiente es un proyecto increíble, pero sería súper completo (y más genial) si tuviera esta función (sin conexión primero) lista para usar.

@ saulflores95 Usar el método de @ooade funcionó para mí :)

@AugustinLF NextSimpleStarter no ofrece capacidades sin conexión. https://github.com/ooade/NextSimpleStarter/issues/23#issuecomment -294310240

@sedubois Para cualquiera que entre y lea esto, es un poco exagerado. Para ser justos, tiene algunas capacidades fuera de línea con el uso de sw-precache y sw-toolbox. Mi aplicación funciona sin conexión únicamente con esas dos herramientas, pero el estado inicial de mi aplicación no cambia. Si estuviera tratando de ser específico, podría decir que no ofrece soluciones fuera de línea para construir estados más allá de lo que se envió inicialmente por el cable.

@timmywil , ¿tienes un repositorio de GitHub de tu aplicación con capacidad nextjs sin conexión? Gracias.

Acabo de crear una versión (beta) de la próxima compatibilidad sin conexión usando appcache , que es necesaria para Safari. Eche un vistazo a http://github.com/ssured/nownextmicro

Hola a todos, agregué soporte sin conexión a mi plantilla.
https://github.com/Sly777/ran

Tiene un poco de errores. Por eso se llama "experimental" 😄 De todos modos, espero que ayude.

@rauchg ¿Esta función sigue siendo una prioridad?

@rauchg Con la versión beta de next.js 4.0 lanzada, ¿hay alguna posibilidad de que el primer soporte fuera de línea esté en la hoja de ruta para esa versión?

Pediría noticias de la función ^^

Next.js 5.0 ha sido lanzado (¡felicitaciones!) Pero no se menciona el soporte fuera de línea, ¿hay una nueva hoja de ruta que le gustaría compartir? gracias por el increíble trabajo realizado hasta ahora

@idhard en realidad, es posible que no
(Pero las cosas pueden cambiar)

Pero estamos en el proceso de asegurarnos de que Next.js no haga ninguna magia. Por lo tanto, podrá usar cargadores y complementos de paquetes web directos tal como están.
El siguiente 5 es el paso uno.

@idhard Creo que sería contrario a la intuición para el soporte general sin conexión, algunas aplicaciones definitivamente no querrán que esa función esté habilitada.

En mi sitio web personal, estoy usando este https://github.com/zeit/next.js/tree/canary/examples/with-sw-precache y también usaremos ^ en producción en

@hanford sí, se ha realizado una discusión similar sobre CRA y terminan eliminando el soporte de webworkers de forma predeterminada (https://github.com/facebook/create-react-app/issues/2554#event-1431558318), sin embargo, todavía creo que webworkers y PWA serán la solución de facto para el soporte fuera de línea, por lo que sería bueno saber si el equipo de Next tiene algún plan para agregar un soporte oficial, como páginas precargadas.

@idhard sí, una especie de dilema interesante para el equipo central. Estoy muy contento con el complemento sw-precache que mencioné anteriormente.

mi sitio web personal está usando el complemento sw-precache webpack, además de servir un manifest.json desde el directorio estático. Si tiene curiosidad, el código está aquí ... las confirmaciones son un poco descuidadas, pero agregué soporte sin conexión y el manifiesto json durante la última semana.

@hanford, ¿qué sucede en iOS 11.3, tendrá trabajadores de servicio? ¿Tiene alguna referencia con más información?

@hanford @idhard probamos a los trabajadores de servicio mucho antes que la CRA y tuvimos muchos problemas.
Es por eso que decidimos construir una solución de búsqueda previa puramente con la tecnología tradicional de almacenamiento en caché web.
Funciona increíblemente bien. Pronto habrá un nuevo conjunto de mejoras.

Sí, por supuesto, sin conexión es un lugar donde necesitamos SW.
Pero es muy inestable y difícil de usar API. Las cosas podrían salir mal y estropear su sitio.

Por lo tanto, es posible que no queramos hacerlo nosotros mismos.
Pero queremos permitir que los usuarios usen cosas como sw-precache través del complemento Next.js (o simplemente agregando un conjunto de cargadores y complementos de paquetes web)

@sedubiois consulte https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html para conocer los planes de Apples en iOS Safari. Se anuncian los trabajadores de servicios

Sí, @ssured @sedubois, los trabajadores del servicio están aterrizando en Mobile Safari en iOS 11.3, ¡lo cual es bastante emocionante! Estoy en iOS 11.3 Beta 2 y hay numerosos errores (los trabajadores del servicio no son reconocidos correctamente cuando se agrega el sitio web a la pantalla de inicio, pero estoy seguro de que Apple los solucionará antes del lanzamiento público)

Creo que lo que sugiere @arunoda es que la estrategia de almacenamiento en caché actual de Next.js (encabezados de control de caché, etags, etc.) es mucho más estable que los trabajadores de servicio. Sin embargo, los trabajadores de servicios habilitan algunas funcionalidades nuevas realmente interesantes, especialmente para obtener un control más fino sobre las solicitudes de red (devolviendo el contenido en caché temprano). Pero lo que Next.js funciona en todas partes y considerablemente menos gastos generales ...

@ssured @sedubois Hice un pequeño complemento que funciona de la misma manera que los complementos que Zeit lanzó el otro día ... debería aliviar las próximas aplicaciones fuera de línea y ser bastante sencillo conectarse a sus aplicaciones existentes

¡Avísame si tienes algún comentario! https://github.com/hanford/next-offline

@hanford gracias por
@arunoda Si bien el soporte de complementos en next.js 5 es increíble, ¿no sería mucho más beneficioso para la comunidad si todos los complementos estuvieran alojados en las carpetas principales de complementos del repositorio next.js, tal como lo son todos los ejemplos, en lugar de un auxiliar? repo? La mayoría de los desarrolladores visitan el repositorio principal y, por lo tanto, los desarrolladores de complementos potenciales tendrían muchos más incentivos para crear solicitudes de extracción, lo que ahorra tiempo a la comunidad debido a la repetición y la inevitable fragmentación del ecosistema de complementos que surge como resultado de repositorios separados.

Para cualquier otra persona que todavía esté decidiendo qué hacer en el futuro, también hice uso del complemento de paquete web sw-precache con relativa facilidad ( ejemplo, nuevamente ).

Estaba usando mi propia solución, pero cambié a la solución proporcionada por Hanford. Tuve que hacer algunas modificaciones en next.config.js para detener el registro automático del complemento al trabajador del servicio, pero parece que funciona bien.

Ahora solo necesito averiguar cómo puedo hacer que esto funcione con mi servidor personalizado. Por ejemplo, tengo una configuración de ruta como artículo /: slug. Cuando visito una de estas URL, el trabajador del servicio intenta enviar un documento para esa URL. ¿Alguien sabe cómo puedo detener eso y hacer que sirva el artículo en su lugar? Esto está relacionado con la configuración de Workbox, supongo.

¿Deberíamos seguir esperando alguna integración de trabajadores de servicio o soporte fuera de línea en futuras versiones de NextJS? Parece que algunas personas decían anteriormente que era una característica prioritaria, pero este problema ha estado abierto durante más de un año y medio ...

@ caribou-code No puedo hablar por el equipo de Zeit sobre sus planes para Next.js, pero escribí esto hace un tiempo: https://github.com/hanford/next-offline que le permite generar automáticamente un trabajador de servicio que funcionará sin conexión.

Lo he usado en varias aplicaciones y ha funcionado bastante bien. Bajo el capó, está utilizando la caja de trabajo de Google, que es un proyecto muy emocionante: https://developers.google.com/web/tools/workbox/

Algunos ejemplos en los que uso next-offline :

@hanford ¡Estaba usando next-offline antes de publicar aquí y es bastante bueno! De hecho, es la única solución que he logrado implementar hasta ahora que realmente funciona. ¡Buen trabajo!

Sin embargo, realmente quería obtener una solución que funcionara con sw-precache-webpack-plugin porque hay un ejemplo de esto en el repositorio de NextJS, aunque no puedo averiguar cómo configurarlo para almacenar en caché y entregar todos mis archivos Next a través de el trabajador del servicio. Ese complemento también parece ser bastante popular.

Creé NextSimpleStarter hace un año para ayudar a resolver este problema . Pero, me di cuenta de que sw-precache por sí solo no podrá cumplir con la mayoría de los requisitos fuera de línea, por lo que recientemente pasamos a usar Workbox, que resuelve la mayoría de ellos.

Aunque todavía tengo que actualizarlo a los estándares actuales (tamaños de íconos, etc.), lo que solucionaré en unos días. No dude en probarlo. Suelta un problema si no lo encuentras satisfactorio.

@hanford Esto se ve muy bien. Se ejecuta para mí en modo de desarrollo, pero no hay ningún trabajador de servicio en ese modo. No puedo decir por su archivo Léame cómo hacer que funcione en modo de producción y con un trabajador de servicio y sin un servidor de nodo. También implemento mi aplicación en Netlify y he estado usando next export . Mi aplicación es totalmente estática. No tengo ningún problema en no usar next export si eso es un problema . Haré lo que sea más eficaz y no cuesta nada. Es una aplicación de hobby, así que soy flexible.

@ooade Esto también se ve muy bien, pero recibí un error al iniciarlo. Cambiar "sin servidor" a "servidor" según sus instrucciones solucionó ese error, pero luego recibí el siguiente error

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

@dancancro definitivamente deberías poder usar next-offline mientras también usas next-export

¿Le importaría abrir un problema en next-offline con algunos pasos para reproducir para que pueda echar un vistazo más profundo?

@hanford , puedo hacer eso si quieres, pero no hice nada especial y no estoy sugiriendo que no haya nada malo en el arranque. Los pasos para reproducir el problema son simplemente sus instrucciones . El único problema es que no sé cómo ejecutarlo en modo de producción. A juzgar por esta condición , no se supone que un trabajador de servicio esté registrado en modo de desarrollo, por lo que lo que me sucedió es el comportamiento esperado. Solo necesito algunas instrucciones: cómo ejecutarlo en modo de producción, y si next export es posible, entonces cómo ejecutar código estático renderizado por el servidor en modo de producción con next export .

@dancancro Lo entiendo, pero esa discusión no debería estar ocurriendo aquí, esto ciertamente no es un problema con Next.js en sí.

Abra un problema aquí y con gusto echaré un vistazo / responderé las preguntas que pueda tener.

La comunidad no se beneficia si tenemos una discusión en un problema / repositorio no relacionado

Recientemente creé un complemento PWA de configuración cero fácil de usar para Next.js: next-pwa

Mira el ejemplo aquí

¿Fue útil esta página
0 / 5 - 0 calificaciones