Next.js: Оффлайн первая поддержка

Мне бы очень хотелось, чтобы это работало, вместе с пояснениями / документацией / примерами по этому поводу.

Обратите внимание, что next / prefetch еще не позволяет работать в автономном режиме, потому что он не выполняет предварительную выборку данных: https://github.com/zeit/next.js/issues/740

Не имеет прямого отношения к Next.js, но мне также интересно, сколько данных на самом деле можно хранить в автономном режиме (например, если в веб-приложении есть видео и т. Д. - есть ли какие-то жесткие ограничения в браузере? А как насчет мобильных устройств?), Как пользователь может конкретно попросить одну вещь , чтобы быть предварительно загружены для последующего использования , и т.д. Я также ранее упомянутые вещи здесь: https://github.com/zeit/next.js/issues/24#issuecomment -258804529 (до следующего / предвыборкой была вещь ).

Существуют разные ограничения данных в разных платформах, браузерах и версиях. Вы можете проверить лимиты в разделе «Злоумышленник в хранилище браузера»: https://demo.agektmr.com/storage/

Стандартным методом, предназначенным для автономного хранения и кеширования, является IndexedDB. Теперь он поддерживается даже в iOS Safari (v10), но там есть проблемы с производительностью. В противном случае сейчас он имеет широкую поддержку: http://caniuse.com/#feat = indexeddb

Например, PouchDB по-прежнему использует WebSQL вместо IndexedDB в Safari. https://github.com/pouchdb/pouchdb/issues/5572
То же самое с localForage: https://github.com/localForage/localForage/issues/604

PouchDB имеет хороший обзор ограничений данных: https://pouchdb.com/faq.html#data_limits (немного устарел)
И в этой еще более старой статье также упоминается, как обрабатывать некоторые ошибки из-за нехватки памяти и другие аспекты, касающиеся мобильных браузеров https://www.html5rocks.com/en/tutorials/offline/quota-research/

Вы также можете запросить текущую квоту и запросить дополнительное постоянное хранилище в некоторых браузерах: https://jakearchibald.com/2014/offline-cookbook/#cache -persistence

Другой способ - использовать длинные значения срока действия кеша и неизменяемое управление кешем вместе с сервисными воркерами. Это легко разрешило бы кэширование, указанное пользователем, просто сделав HTTP-запрос для каждого выбранного ресурса. Это также неплохо работает в старых браузерах. Но иметь возможность поддерживать и вручную удалять различные кеши, чтобы избежать ограничений, возможно только в браузерах, поддерживающих сервис-воркеров.
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

Просто помните, когда у вас заканчивается пространство, браузер может удалить весь источник за раз, пока он не окажется в установленных пределах:
https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

Еще одна полезная статья Адди Османи: https://medium.com/dev-channel/offline-storage-for-progressive-web-apps-70d52695513c#.9vja3t8gp

По-видимому, также разрабатывается Storage api: https://storage.spec.whatwg.org/

Это позволяет действительно постоянное хранилище:
«Традиционно, когда у пользователя заканчивается место для хранения на своем устройстве, данные, хранящиеся с этими API-интерфейсами, теряются без возможности вмешательства пользователя. Однако постоянные ящики не могут быть очищены без согласия пользователя. Это дает пользователям гарантии данных пользовались на нативных платформах в Интернете ".

ИМО, заставляющая сайт / приложение работать в автономном режиме, включает в себя множество решений, которые фреймворк не должен принимать сам по себе. Я буду работать над примером сайта, работающего в автономном режиме с сервисным работником, но для разных типов приложений существуют разные методы.

спасибо @impronunciable . Планируете ли вы использовать webpack-offline или что-то еще?

о каких решениях ты говоришь? Я думаю, что мы можем разделить проблему на два основных вопроса:

1) Кэширование статических ресурсов: например, js, HTML, изображения, ... это почти уже реализовано, по крайней мере, в автономном варианте и за исключением /static , и, учитывая, что мы используем реакцию, оно должно иметь одна предпочтительная реализация через webpack-offline и service worker.

2) Кэширование данных: состояние, запросы, изменчивые данные, .... вызывают больше опасений, поскольку по крайней мере требуется предположить, как пользователи будут загружать данные. Может быть, мы могли бы показать, как сохранить состояние с помощью redux, и тогда люди будут помещать данные в redux по своему усмотрению. Или, может быть, мы могли бы использовать GraphQL / Apollo, который должен покрыть такой случай путем кеширования запросов и мутаций.

@servermeta это действительно зависит от вашего случая. Я заканчиваю реализацию агрессивной стратегии кеширования без использования плагинов, просто настраиваемый сервер и стратегию из https://serviceworke.rs/

У меня здесь работает. Много сражался с Offline-Plugin, имел некоторые проблемы с каталогом .next, затем я переключился на sw-precache-webpack-plugin, проигнорировал каталог .next и отправил все ресурсы в sw

спасибо @ooade , молодец, ты сэкономил мне много времени.

Во всяком случае, я вижу, что это состояние не сохраняется между обновлениями и перезагрузками. Попробую подумать, как добавить эту фичу.

спасибо @ooade . Под localhost вы имеете в виду локальную базу данных, например mongodb или localstorage?

Я думаю, мы должны разделить проблему: автономное извлечение данных должно быть оставлено на усмотрение разработчика, а мы могли бы сохранить состояние редукции. Проверь это:

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

с этим мы можем хранить состояние в localstorage, чтобы оно могло сохраняться между обновлениями, перезагрузками, вкладками и сеансами.

Эй, ребята. Моя команда в Google работает над несколькими библиотеками Service Worker (с плагинами Webpack), такими как https://github.com/GoogleChrome/sw-precache и https://github.com/GoogleChrome/sw-toolbox, используемыми в React / Webpack Heavy такие сайты, как Lyft, Housing.com, Flipkart и т. д.

Если Next решит изучить офлайн-поддержку, мы будем рады поделиться некоторыми советами. Я думаю, что есть отличная возможность прописывать шаблоны, такие как PRPL , из коробки, учитывая, что разделение кода уже выполняется. Кэширование Service Worker только в производственной среде было бы изящным дополнением.

Помимо мгновенной повторной загрузки этих страниц, он также позволит вам на раннем этапе кэширования кода V8, поэтому время синтаксического анализа / компиляции для повторных посещений будет меньше, чем сегодня.

Не стесняйтесь кричать, если это интересно, @rauchg :)

Офлайн- поддержка

@rauchg есть
Мы собираемся начать полноценное производство и хотели бы использовать Next.js.
Буду признателен за любую оценку, дни / недели / месяцы ...
Большое спасибо!

@ Ajar-Ajar 2.0.0 был выпущен сегодня.

@rauchg, здесь будет отслеживаться поддержка в автономном режиме, или вы собираетесь создать для нее еще одну проблему?

Также ознакомьтесь с недавно выпущенным redux -offline с открытым исходным кодом от @jevakallio. Было бы здорово иметь следующий пример + redux-offline.

Итак, есть ли у нас какая-либо информация о том, как этого добиться, я пытался сделать это в next.config.js и устанавливал автономный плагин, но не мог заставить его работать. Следующий - отличный проект, но он был бы супер полным (и круче), если бы в нем была эта функция (сначала автономно) из коробки!

@ saulflores95 Использование метода @ooade NextSimpleStarter сработало для меня :)

@AugustinLF NextSimpleStarter не предлагает офлайн-возможности. https://github.com/ooade/NextSimpleStarter/issues/23#issuecomment -294310240

@sedubois Для всех, кто

@timmywil , у вас есть

Я только что создал (бета) версию следующей поддержки в автономном режиме, используя appcache , что необходимо для Safari. Пожалуйста, посмотрите http://github.com/ssured/nownextmicro

Привет всем, я добавил поддержку офлайн в свой шаблон.
https://github.com/Sly777/ran

Немного глючит. Вот почему он назван «экспериментальным» 😄 В любом случае, я надеюсь, что это поможет.

@rauchg Эта функция по-прежнему в приоритете?

@rauchg С выпуском бета-версии next.js 4.0 есть ли шансы, что первая офлайн-поддержка будет включена в дорожную карту для этой версии?

Я хотел бы узнать новости об этой функции ^^

Выпущен Next.js 5.0 (поздравляем!), Но об автономной поддержке нет упоминания. Есть ли новый план действий, которым вы хотели бы поделиться? спасибо за отличную работу, проделанную до сих пор

На самом деле
(Но все может измениться)

Но мы пытаемся убедиться, что Next.js не творит чудеса. Таким образом, вы сможете использовать прямые плагины и загрузчики веб-пакетов как есть.
Следующие 5 - это первый шаг.

@idhard Я думаю, что это было бы

На моем личном веб-сайте я использую https://github.com/zeit/next.js/tree/canary/examples/with-sw-precache, и мы также собираемся использовать ^ в производстве в Eaze, как только iOS Выпущена версия 11.3.

@hanford, да, подобное обсуждение было проведено по CRA, и в конечном итоге поддержка веб-работников по умолчанию была прекращена (https://github.com/facebook/create-react-app/issues/2554#event-1431558318), однако я все еще думаю, что веб-работники и PWA станут де-факто решением для офлайн-поддержки, поэтому было бы неплохо узнать, есть ли у команды Next план по добавлению официальной поддержки, такой как предварительно загруженные страницы.

@idhard: Да, интересная дилемма для основной команды. Я был очень доволен плагином sw-precache, о котором я упоминал выше.

мой личный веб-сайт использует плагин sw-precache webpack, а также обслуживает manifest.json из статического каталога. Если вам интересно, код здесь ... коммиты немного небрежны, но на прошлой неделе я добавил автономную поддержку и манифест json.

@hanford, что происходит в iOS 11.3, будут ли там сервис-

@hanford @idhard мы пробовали сервис-работников задолго до CRA, и у нас было много проблем.
Вот почему мы решили создать решение для предварительной выборки исключительно с использованием традиционной технологии веб-кэширования.
Он отлично работает. Скоро появится новый набор улучшений.

Да конечно офлайн - это то место, где нам нужен SW.
Но это очень нестабильный и сложный в использовании API. Что-то может пойти не так и сломать ваш сайт.

Так что мы можем не захотеть делать это сами.
Но мы хотим разрешить пользователям использовать такие вещи, как sw-precache через плагин Next.js (или просто добавляя набор загрузчиков и плагинов webpack).

@sedubiois см. https://developer.apple.com/library/content/releasenotes/General/WhatsNewInSafari/Articles/Safari_11_1.html, чтобы узнать о тарифных планах Apple для iOS Safari. Объявлены сервисные работники

Да, @ssured @sedubois сервис- воркеры переходят на Mobile Safari в iOS 11.3, и это очень интересно! Я использую iOS 11.3 Beta 2, и есть множество ошибок (сервисные работники не распознаются должным образом, когда веб-сайт добавляется на домашний экран, но я уверен, что Apple исправит их до публичного выпуска)

Я думаю, что @arunoda предлагает то, что текущая стратегия кеширования Next.js (заголовки управления кешем, etags и т. Д.) Намного более стабильна, чем сервис-воркеры. Сервис-воркеры действительно включают некоторые действительно изящные новые функции, особенно получение более тонкого контроля над сетевыми запросами (ранний возврат кэшированного контента) .. Но то, что Next.js работает везде и значительно меньше накладных расходов ... (отмена регистрации сервис-воркеров - это настоящая боль)

@ssured @sedubois Я сделал небольшой плагин, который работает так же, как плагины, которые Zeit запустил на днях ... он должен облегчить работу следующих офлайн-приложений и быть довольно простым при подключении к вашим существующим приложениям

Дайте мне знать, если у вас есть отзывы! https://github.com/hanford/next-offline

@hanford, спасибо, что сделали нашу жизнь немного проще
@arunoda Хотя поддержка плагинов в next.js 5 прекрасна, не было бы намного выгоднее для сообщества, если бы все плагины размещались в основных папках плагинов репозитория next.js, как и все примеры, вместо вспомогательных репо? Большинство разработчиков посещают основное репо, и, таким образом, у потенциальных разработчиков плагинов будет гораздо больше стимулов для создания запроса на вытягивание, что позволит сэкономить время сообщества из-за повторения и неизбежной фрагментации экосистемы плагинов, возникающей в результате отдельных репозиториев.

Для тех, кто еще решает, что делать в дальнейшем, я также относительно легко использовал плагин sw-preache webpack ( снова пример ).

Я использовал собственное решение, но перешел на решение, предоставленное Хэнфордом. Мне пришлось внести несколько изменений в next.config.js, чтобы плагин остановил автоматическую регистрацию сервис-воркера, но, похоже, он работает хорошо.

Теперь мне просто нужно выяснить, как я могу заставить это работать с моим настраиваемым сервером. Например, у меня есть настройка маршрута как article /: slug. Когда я посещаю один из этих URL-адресов, работник службы пытается отправить документ для этого URL-адреса. Кто-нибудь знает, как я могу остановить это и заставить вместо этого служить статьей? Думаю, это связано с настройками в Workbox.

Стоит ли ожидать интеграции сервис-воркеров или офлайн-поддержки в будущих выпусках NextJS? Похоже, некоторые раньше говорили, что это приоритетная функция, но этот вопрос открыт уже более полутора лет ...

@ caribou-code Я не могу говорить от имени команды Zeit об их планах относительно Next.js, но я написал это некоторое время назад: https://github.com/hanford/next-offline, что позволяет автоматически создавать сервис-воркера. это будет работать в автономном режиме.

Я использовал его в нескольких приложениях, и он работал очень хорошо. Под капотом он использует рабочую панель googles, что является очень интересным проектом: https://developers.google.com/web/tools/workbox/

Некоторые примеры, в которых я использую next-offline :

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

@hanford Я просто использовал next-offline, прежде чем опубликовать здесь, и это очень хорошо! Фактически, это единственное решение, которое мне удалось реализовать до сих пор, которое действительно работает. Хорошая работа!

Однако я действительно хотел получить решение, работающее с sw-precache-webpack-plugin, потому что пример этого есть в репозитории NextJS, хотя я не могу понять, как настроить его для кеширования и обслуживания всех моих файлов Next через сервисный работник. Этот плагин тоже кажется довольно популярным.

Я создал NextSimpleStarter год назад, чтобы помочь решить эту проблему . Но я обратил внимание на то, что только sw-Precache не сможет удовлетворить большинство требований офлайн, поэтому недавно мы перешли на использование workbox, который решает большинство из них.

Хотя мне еще предстоит обновить его до текущих стандартов (размеры значков и т. Д.), Которые я исправлю через несколько дней. Не стесняйтесь попробовать. Отпустите вопрос, если он вас не устраивает.

@hanford Выглядит отлично. Он работает для меня в режиме разработки, но в этом режиме нет обслуживающего работника. Я не могу сказать из вашего readme, как заставить его работать в производственном режиме, с сервис-воркером и без сервера узла. Я также развертываю свое приложение в Netlify и использую next export . Мое приложение полностью статично. У меня нет проблем с тем, чтобы не использовать next export если это проблема . Я сделаю то, что наиболее эффективно и ничего не будет стоить. Это приложение для хобби, поэтому я гибкий.

@ooade Это тоже выглядит отлично, но при запуске у меня

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

@dancancro, вы определенно должны иметь возможность использовать next-offline а также использовать next-export

Не могли бы вы открыть проблему в next-offline с некоторыми шагами для воспроизведения, чтобы я мог глубже изучить?

@hanford Я могу это сделать, если хочешь, но я ничего особенного не сделал и не предлагаю, чтобы в стартере что-то сломалось. Действия по воспроизведению проблемы - это просто ваши инструкции . Единственная проблема в том, что я не знаю, как запустить его в производственном режиме. Судя по этому условию, сервис-воркер не должен регистрироваться в режиме разработки, поэтому то, что произошло для меня, является ожидаемым поведением. Мне просто нужны некоторые инструкции - как запустить его в производственном режиме, и если возможно next export , то как запустить статический, отрендеренный сервером код в производственном режиме с помощью next export .

@dancancro Я понимаю, но здесь не должно быть этого обсуждения, это определенно не проблема самого Next.js.

Пожалуйста, откройте проблему здесь, и я буду рад посмотреть / ответить на ваши вопросы.

Сообщество не выиграет, если у нас будет обсуждение несвязанного вопроса / репо.

Недавно я создал простой в использовании плагин PWA с нулевой конфигурацией для Next.js: next-pwa

Посмотрите пример здесь