Как реализовать сервисную программу в SFCC (Demandware)

Question

Мне было интересно, есть ли у кого-нибудь здесь опыт внедрения сервисного работника в SFCC / Demandware.

Я создаю работника сервиса с Webpack с помощью sw-precache-webpack-plugin

Проблема в том, что сервисный работник должен быть доступен в корне домена. так что site.com/sw.js. Файлы JS будут нормально приходить в папку static/. Кто-нибудь знает, как обслуживать этот файл JS из корня проекта в Demandware / SFCC?

Answer 1

К сожалению, регистрация работника службы в области, которая находится в верхнем пути, чем сам файл работника службы, не работает (как указано в MDN):

• Сервисный работник будет перехватывать запросы только от клиентов в рамках сервисного работника.
• Максимальная область действия для работника службы - это местоположение работника.

(Источник: https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers)

Решение

Вот предложение о рабочем подходе для обслуживания "/sw.js" в Demandware (Sales Force):

• Создать новый контроллер (или конвейер), например "ServiceWorker-GetFile"; ответ должен быть содержимым файла, который можно прочитать из любого источника:
  • Актив содержимого (dw.content.ContentMgr.getContent ());
  • Файл библиотеки (dw.content.ContentMgr.getContent () или прямое чтение файла с помощью dw.io.File / dw.io.FileReader);
  • даже предпочтения сайта (хотя я бы не рекомендовал его);
• Создайте запись в Business Manager / Merchant Tools / SEO / Aliases для маршрутизации "/sw.js" в "ServiceWorker-GetFile", т. Е. Используйте что-то вместе:

{
  ...
  "your-host" : [
    ...,
    {
      "if-site-path": "/sw.js",
      "pipeline": "ServiceWorker-GetFile"
    }
  ]
}

Это может показаться ненужными накладными расходами, но это был единственный способ найти файлы для обслуживания с корневым путем в URI.

Обслуживание других корневых файлов

Расширяя контроллер (переименовывая его, скажем, в «Content-GetFile» и добавляя параметры GET / POST, такие как «name» и / или «source»), это удобно использовать и для других файлов («/ manifest» .json "," /.well-known/assetlinks.json "и т. д.). В следующем примере Business Manager / ... / Aliases, пусть Content-GetFile принимает два параметра: «имя» (которое будет именем файла в библиотеке контента или идентификатором ресурса контента) и «источник» (который будет "файл" или "актив"):

...
{
  "if-site-path": "/sw.js",
  "pipeline": "Content-GetFile",
  "params": {
    "name": "/ServiceWorker/sw.js",
    "source": "file"
  }
},
{
  "if-site-path": "/manifest.json",
  "pipeline": "Content-GetFile",
  "params": {
    "name": "MANIFEST_JSON",
    "source": "asset"
  }
}

Обратите внимание, что ваш код должен надлежащим образом обрабатывать базовые пути ресурсов (например, "/ServiceWorker/sw.js" из приведенного выше примера мало говорит; вы должны знать, является ли это путь в библиотеке содержимого или путь относительно "картриджей" // static / default / js /").

Динамический контент

Поскольку в предлагаемом подходе используется контроллер, вы можете динамически обрабатывать контент перед его передачей пользователю (например, если вам нужно добавить / удалить часть "/ v12435145145 /" из ссылок DMW). Небо это ваши пределы. :)

Answer 2

В настоящее время я также работаю с сервисными работниками на DW. В моем случае я непосредственно добавил скрипт в файл footer.isml, например:

<script>
  //init service worker
  if ('serviceWorker' in navigator) {
    window.addEventListener('load', () => {     
      navigator.serviceWorker
        .register("${URLUtils.staticURL('/lib/sw/sw.js')}")
        .then(registration => {
          console.log(
            `Service Worker registered! Scope: ${registration.scope}`
          );
        })
        .catch(err => {
          console.log(`Service Worker registration failed: ${err}`);
        });
    });
  }
</script>

Это работает для меня, по крайней мере, я вижу сообщение Service Worker registered.

У меня также были некоторые проблемы из-за SSL-сертификата, так как в моей среде разработки нет надлежащего SSL, но он использует маршруты HTTP, поэтому chrome жаловался на это, мне нужно было запустить chrome через терминал с помощью этой команды:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --user-data-dir=/tmp/foo --ignore-certificate-errors --unsafely-treat-insecure-origin-as-secure=[YOUR DOMAIN]

К сожалению, я не могу заставить работать какую-либо строку кода внутри этого файла сервисного работника, даже я пробовал в Safari, так как в меню разработки есть опция Service Workers, но он не показывает работающий сервисный работник.

Надеюсь, это поможет вам.