Это продолжение моего предыдущего сообщения о создании PWA с помощью create-react-app (CRA). В сообщении я обсуждал, как мы можем создать специальный Service Worker (SW), оставаясь в пределах оболочки create-react-app.

Если бы вы следили за публикацией (и надеюсь, заставили ее работать), вы бы заметили один критический недостаток. Все еще очень трудно разработать программное обеспечение в среде разработчиков. По сути вам придется изменить свой код программного обеспечения, запустить процесс сборки, протестировать его, исправить любые ошибки, обновить и повторить. Если говорить по опыту, то это изнурительный процесс.

Давайте подумаем, как устранить эту проблему.

Работа в режиме разработчика

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

Сначала давайте разберемся, почему он не работает в режиме разработчика. Создайте новый проект CRA и откройте файл registerServiceWorker.js под src каталог.

В приведенной выше сущности у меня есть только соответствующий фрагмент кода. Вы заметите условную проверку process.env.NODE_ENV === 'production'. Это проверяет, выполняете ли вы производственную сборку. Если вы не используете сборку, программное обеспечение будет заменено файлом без операций.

Обоснование этого решения предоставлено в этом выпуске GitHub.

Во-первых, попробуйте бежать yarn start в вашем приложении и проверьте наличие файла программного обеспечения в окне панели инструментов. Если нажать на service-worker.js ссылку на панели инструментов, вам будет показан следующий файл:

К счастью, для этого есть простое решение. Это легкий двухэтапный процесс.

Во-первых, внутри registerServiceWorker.js файл, ищите window.addEventListener('load') вызов функции. Первая строка – это декларация для swUrl говорящий:

const swUrl = `${process.env.PUBLIC_URL}/service-worker.js`;

Переименуйте service-worker часть его с чем-нибудь другим. Я собираюсь назвать свое service-worker-custom.js.

Во-вторых, создайте файл в общедоступном каталоге с помощью файла точное название как собственное имя, которое вы только что придумали. Итак, я бы создал файл под названием service-worker-custom.js внутри общедоступного каталога

Теперь внутри service-worker-custom.js , разместить простой оператор журнала Что-то вроде: console.log('My custom service worker').

Теперь снова запустите программу с помощью yarn start и вы увидите, что оператор журнала появится на консоли вашего браузера. Возможно, вам придется отменить регистрацию предыдущего сервисного работника, если вы когда-нибудь запускали yarn start до этого.

Итак вот оно. Специальный сервисный работник, который можно безопасно запускать в режиме разработчика.

Примечание. Глупо тестировать Service Worker в среде разработчика вне режима приватного просмотра в вашем браузере. Кроме того, во время тестирования в режиме разработчика всегда убедитесь, что в окне инструментов разработчика указан параметр Обновления при перезагрузке.

Сочетание Dev и Prod

Теперь мы поняли, как протестировать программное обеспечение в режиме разработчика. Однако нам также нужно найти способ ввести наш пользовательский код в программное обеспечение, созданное CRA в производственной сборке.

Если вы сохраните все как есть с конфигурациями, которые мы сделали, и запустите процесс сборки и проверьте сборку в своем браузере, вы заметите, что созданный файл программного обеспечения является пользовательским, который мы создали. Это проблема, потому что мы хотим иметь возможность объединить преимущества того, что может предложить нам CRA с нашим собственным кодом.

Мы можем сделать это с помощьюsw-precache библиотека. Я представил эту библиотеку в своей предыдущей публикации. Вот ссылка на GitHub на sw-precache библиотека.

Установите библиотеку с помощью yarn add sw-precache . Сделав это, создайте файл a sw-precache-config.js файл в вашем корневом каталоге. Вот мой файл:

Большую часть этого файла я представил в предыдущей публикации. Единственный новый бит – это importScripts вариант. Это достаточно понятно, оно просто импортирует файл, указанный путём, и мы пытаемся импортировать наш пользовательский файл программного обеспечения.

Вы заметите, что путь к файлу отсутствует ./public префикс, несмотря на то, что файл присутствует в нашем public каталог. Немного объясню это.

Теперь обновите свой package.json файл с изменениями в build команда. Сделайте свой build командовать следующим образом:

react-scripts build && sw-precache --config=sw-precache-config.js

Теперь вернемся к пути к файлу, который мы предоставили параметру importScripts. Если вы заметили, то sw-precache по существу, выполняется как процесс после сборки. Теперь, если вы просто запустите процесс сборки и откроете созданный каталог сборки, вы заметите файл пользователя службы Worker в папке сборки. Когда мы обеспечиваем путь к importScripts параметр, мы предоставляем его в отношении каталога сборки!

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

Ну вот и все! Теперь вы можете ввести пользовательский код программного обеспечения в программное обеспечение по умолчанию, созданное CRA!