Service worker: посредник, который живёт без страницы

Service worker — это скрипт, который браузер запускает отдельно от страницы. У него нет ни document, ни доступа к вашим переменным, зато он стоит между страницей и сетью и видит её запросы раньше сервера. Поэтому им и открывают сайт без сети: на запрос отвечает не сервер, а посредник, у которого всё нужное уже лежит в кеше.

Регистрируют его одной строкой — navigator.serviceWorker.register(…). Прежде чем нажимать «Запустить», предскажите, что напечатает этот код здесь, в песочнице учебника. Ничего нового в нём нет: async-функция и try/catch вокруг await — из статьи «async/await» части I.

console.log("serviceWorker" in navigator);

async function main() {
  try {
    const registration = await navigator.serviceWorker.register("https://board.example/sw.js");
    console.log("зарегистрировали, область:", registration.scope);
  } catch (error) {
    console.log("регистрация не вышла:", error.name);
  }

  try {
    await caches.open("board-v1");
    console.log("кеш открыт");
  } catch (error) {
    console.log("кеш не открылся:", error.name);
  }
}

main();

Первая строка — чистая правда: имя serviceWorker у navigator есть. А дальше отказ, и настоящий. Примеры учебника выполняются в <iframe> с атрибутом sandbox без флага allow-same-origin, и происхождение у такого документа уникальное, «непрозрачное»: ни домена, ни порта, ни своего места на диске. Service worker и Cache API привязаны к происхождению — привязывать нечего и не к чему.

Отказ выглядит одинаково, а устроен по-разному, и для кода это важно. В Chrome бросает уже сам геттер navigator.serviceWorker — синхронно, до всякого register. Значит, привычная форма navigator.serviceWorker.register(…).catch(…) ошибку не поймает: до .catch дело не дойдёт, выполнение оборвётся на обращении к свойству. В Firefox геттер отдаёт объект, а отказ приезжает отклонённым промисом — там .catch сработал бы. Форма, которая ловит оба случая, одна: try/catch вокруг await, как в примере.

Проверка вида 'serviceWorker' in navigator отвечает на вопрос «знает ли браузер такое имя», а не «разрешено ли им пользоваться здесь и сейчас». Разрешение выясняется только попыткой — и попытку надо обернуть в try/catch.

Отсюда устройство всей главы. Механику мы собираем миниатюрами в памяти: обычные функции, которые печатают в консоль, — их можно предсказать и запустить прямо на странице. А настоящий воркер, настоящий кеш и настоящий манифест запускаем по-честному, на своём сервере. Этим и займёмся прямо сейчас.

За две части мы ни разу не поднимали сервер: всё жило в песочнице. Дальше так не выйдет. Service worker работает только в безопасном контексте — это https:// или localhost, который браузеры считают безопасным по особому правилу, чтобы разработке не требовался сертификат.

Соблазнительный путь — сложить файлы доски в папку и открыть index.html двойным щелчком. Адрес получится file:///…, и вот что скажет на это браузер:

// страница открыта двойным щелчком, адрес начинается с file:///
navigator.serviceWorker.register("./sw.js");

Слово null в скобках — то самое непрозрачное происхождение, что и в песочнице: у файла на диске нет ни схемы с доменом, ни порта, значит, нет и области, к которой можно привязать воркера. Настройками это не лечится, нужен настоящий адрес.

Разложим доску по файлам. Разметка — из статьи «Проект: доска задач — разметка и план», состояние и сохранение — из «Сохранение и восстановление доски», а стили в board.css — любые: в проекте мы их не писали. Новый здесь только sw.js, и до конца статьи он останется почти пустым.

$ ls -1 board

Статический сервер на вашей машине уже есть — встроенный в Python. Запускаем его из папки с доской и окно не закрываем: он печатает каждый запрос, и этот журнал нам ещё пригодится.

$ python3 -m http.server 8000 --directory board

Что тут видно. Браузер попросил страницу, стили и код; favicon.ico он спрашивает сам, и 404 на него — обычное дело. А sw.js запрошен последним, уже после app.js: это наша регистрация, а не разбор разметки. ::1 в начале строк — адрес localhost по IPv6, так его записал Python.

Порт 8000 может быть занят — берите любой другой, хоть 8080. Важно одно: адрес начинается с http://localhost или http://127.0.0.1. А вот по адресу вашей машины в локальной сети (что-нибудь вроде 192.168.1.5) воркер уже не зарегистрируется: безопасным контекстом без сертификата считается только петля.

Слово worker здесь не метафора. Браузерный воркер — отдельный поток со своей глобальной областью, и document в ней просто нет. Ни дотянуться до страницы, ни поменять её он не может; единственный способ общения — сообщения. Проверим на обычном Worker: он в песочнице настоящий.

const source = `
  self.onmessage = (event) => {
    self.postMessage({ dom: typeof document, doubled: event.data * 2 });
  };
`;

const worker = new Worker(URL.createObjectURL(new Blob([source], { type: "text/javascript" })));

worker.onmessage = (event) => {
  console.log("поток ответил, document там:", event.data.dom);
  console.log("посчитал:", event.data.doubled);
  worker.terminate();
};

console.log("отправили в поток:", 21);
worker.postMessage(21);
console.log("страница ответа не ждёт");

Здесь два урока сразу. Первый: typeof document внутри потока — undefined, и это не сбой, а устройство. Второй: строки напечатались не в том порядке, в каком написаны. Отправка в поток страницу не останавливает — ответ придёт позже, ровно как результат промиса из части I.

Service worker — воркер того же рода, но с двумя отличиями. Он переживает страницу: продолжает существовать, когда все вкладки сайта закрыты. И он не работает постоянно — браузер будит его событием, а когда дело сделано, гасит. Отсюда правило, о которое спотыкаются все: держать состояние в переменной воркера бессмысленно, между двумя событиями его может не быть вовсе.

Воркер — не сервер, который «запущен». Это обработчик, которого зовут. Всё, что нужно помнить между вызовами, кладут в кеш или в IndexedDB, а не в переменную.

register принимает адрес скрипта, и этим адресом решено почти всё. Область действия (scope) по умолчанию — папка, в которой скрипт лежит. /sw.js накрывает весь сайт, /js/sw.js — только /js/ и то, что ниже. Поэтому воркер кладут в корень: из подпапки он не увидит ни главной страницы, ни запросов к API.

Совпадение адреса с областью — это совпадение префикса строки, буква в букву. Никаких «папок» при сравнении не разбирается, и на этом ловятся:

function inScope(scope, url) {
  return new URL(url).href.startsWith(new URL(scope).href);
}

const scope = "https://board.example/app/";

console.log(inScope(scope, "https://board.example/app/index.html"));
console.log(inScope(scope, "https://board.example/app/data/tasks.json"));
console.log(inScope(scope, "https://board.example/about.html"));

console.log(inScope("https://board.example/app", "https://board.example/application/main.js"));

Последняя строка — не выдумка ради примера. Мы зарегистрировали воркер с областью /app, без слэша на конце, и открыли три страницы подряд:

// на одной странице:
navigator.serviceWorker.register("/sw2.js", { scope: "/app" });

// и потом на каждой из трёх других:
const c = navigator.serviceWorker.controller;
console.log(location.pathname, "controller:", c ? c.scriptURL : null);

Страница /application/ попала под управление воркера, которому её никто не отдавал: её адрес начинается с /app. Отсюда привычка всегда заканчивать область слэшем — /app/.

try {
  console.log(new URL("/app/sw.js").href);
} catch (error) {
  console.log("относительный адрес здесь не разбирается:", error.name);
}

console.log(new URL("/app/sw.js", "https://board.example/page.html").href);
console.log(new URL("sw.js", "https://board.example/app/page.html").href);

У зарегистрированного воркера есть состояние, и меняется оно по строгой лестнице. installing — скрипт скачан, идёт обработчик install. installed — установка удалась, воркер готов, но ещё не у руля (в этом состоянии его называют ожидающим, waiting). activating — идёт обработчик activate. activated — воркер отвечает на запросы. И redundant — тупик: сюда попадает и сорвавшаяся установка, и старая версия, вытесненная новой.

Соберём эту лестницу миниатюрой. Она пригодится и дальше в главе, поэтому пусть будет отдельной функцией, а не парой переменных.

const NEXT = {
  installing: ["installed", "redundant"],
  installed: ["activating", "redundant"],
  activating: ["activated", "redundant"],
  activated: ["redundant"],
  redundant: []
};

function createRegistration(name) {
  let state = "installing";
  console.log(name + ": " + state);
  return {
    name,
    get state() { return state; },
    to(next) {
      // переход, которого нет в таблице, — это ошибка в нашей модели,
      // а не новое состояние воркера
      if (!NEXT[state].includes(next)) throw new Error("из " + state + " нельзя в " + next);
      state = next;
      console.log(name + ": " + state);
    }
  };
}

const worker = createRegistration("sw.js");
worker.to("installed");
worker.to("activating");
worker.to("activated");

try {
  worker.to("installing");
} catch (error) {
  console.log(error.message);
}

Таблица переходов здесь не ради красоты: она превращает «кажется, я что-то напутал» в явную ошибку. Обратной дороги из activated нет — новая версия скрипта не оживляет старого воркера, а ставится отдельным воркером и проходит лестницу с начала. Как они сменяют друг друга, разберём в статье про обновление воркера.

Теперь самое неочевидное в установке — waitUntil. Обработчик install сам по себе асинхронным быть не умеет: браузеру нужно знать, когда установка кончилась, и узнаёт он это из промиса, переданного в event.waitUntil(…). Пока промис не выполнен, воркер остаётся в installing. Если промис отклонится — установка сорвана, и воркер уходит в redundant.

Классический способ занять установку делом — cache.addAll со списком файлов оболочки. И классическая беда: один неверный адрес в списке роняет всю установку. Автомат из прошлого примера уже лежит на странице; добавим к нему кеш и установку.

const FILES = {
  "https://board.example/index.html": "доска",
  "https://board.example/app.js": "код доски",
  "https://board.example/board.css": "стили"
};

function createCache() {
  const box = new Map();
  return {
    size: () => box.size,
    addAll: async (urls) => {
      const pairs = urls.map((url) => {
        if (!(url in FILES)) throw new Error("404 " + url);
        return [url, FILES[url]];
      });
      for (const [url, body] of pairs) box.set(url, body);
    }
  };
}

async function install(registration, handler) {
  const waiting = [];
  handler({ waitUntil: (promise) => waiting.push(promise) });
  try {
    await Promise.all(waiting);
    registration.to("installed");
  } catch (error) {
    console.log("  установка сорвалась:", error.message);
    registration.to("redundant");
  }
}

async function main() {
  const first = createCache();
  await install(createRegistration("v1"), (event) => {
    event.waitUntil(first.addAll([
      "https://board.example/index.html",
      "https://board.example/app.js",
      "https://board.example/board.css"
    ]));
  });
  console.log("файлов в кеше:", first.size());

  const second = createCache();
  await install(createRegistration("v2"), (event) => {
    event.waitUntil(second.addAll([
      "https://board.example/index.html",
      "https://board.example/board.css",
      "https://board.example/icons/192.png"
    ]));
  });
  console.log("файлов в кеше:", second.size());
}

main();

Второй кеш остался пустым — и это не упрощение модели. Настоящий addAll ведёт себя так же: сначала забирает все ответы и только потом кладёт их в кеш. Вот проверка на живом браузере, где вторым адресом в списке стоит несуществующий файл:

const cache = await caches.open("proba-addall");
try {
  await cache.addAll(["./index.html", "./нет-такого.js"]);
} catch (error) {
  console.log("addAll отказал:", error.name);
}
console.log("в кеше осталось записей:", (await cache.keys()).length);

Ноль записей: index.html, который скачался успешно, в кеш тоже не попал. Обратите внимание и на имя ошибки — TypeError, а не что-нибудь про сеть: для addAll ответ 404 не «плохие данные», а невыполнимое требование.

Половина оболочки в кеше хуже, чем ничего: страница откроется без сети и развалится на первом же недостающем файле. Поэтому «всё или ничего» — правильное поведение, а не придирка.

Осталось главное недоразумение первой встречи. Страница вызвала register, воркер установился и активировался — и этой страницей он не управляет. Проверим на настоящей доске. Вот её sw.js, пока без всяких стратегий кеша:

const VERSION = "board-v1";
const SHELL = ["./", "./app.js", "./board.css"];

self.addEventListener("install", (event) => {
  event.waitUntil(caches.open(VERSION).then((cache) => cache.addAll(SHELL)));
});

self.addEventListener("activate", (event) => {
  event.waitUntil(
    caches.keys().then((names) => Promise.all(names.filter((n) => n !== VERSION).map((n) => caches.delete(n))))
  );
});

self.addEventListener("fetch", (event) => {
  event.respondWith(caches.match(event.request).then((hit) => hit || fetch(event.request)));
});

А вот app.js, который его регистрирует и рассказывает о каждом шаге. Открываем http://localhost:8000/ в чистом профиле браузера:

const controller = navigator.serviceWorker.controller;
console.log("controller при загрузке:", controller ? controller.scriptURL : null);

navigator.serviceWorker.register("./sw.js").then((registration) => {
  console.log("область действия:", registration.scope);

  const worker = registration.installing || registration.waiting || registration.active;
  console.log("состояние сразу после register:", worker.state);

  worker.addEventListener("statechange", () => {
    console.log("statechange:", worker.state);
    if (worker.state === "activated") {
      console.log("воркер активен, а controller страницы:", navigator.serviceWorker.controller);
    }
  });
});

Прочитайте последние две строки ещё раз. Воркер прошёл всю лестницу до activated — а controller у страницы по-прежнему null. Ни одна её картинка, ни один её запрос через воркера не пойдёт.

Причина простая и, если подумать, правильная: браузер не подсовывает посредника посреди жизни документа. Страница уже загрузилась без воркера, часть её запросов ушла в сеть напрямую — и было бы странно, если бы остальные вдруг поехали другой дорогой. Управление достаётся следующей загрузке.

// перезагрузили ту же страницу, в app.js не изменилось ни строчки
const controller = navigator.serviceWorker.controller;
console.log("controller при загрузке:", controller ? controller.scriptURL : null);

В той же второй загрузке register сразу отдал воркера в состоянии activated: устанавливать было нечего, регистрация уже существует. Повторный register с тем же адресом — не ошибка и не вторая копия, а способ получить ссылку на то, что уже есть.

Обойти ожидание можно: self.clients.claim() в обработчике activate забирает под управление уже открытые страницы из области действия — в том числе ту, которая его и зарегистрировала. Страницам, открытым позже, он для этого не нужен: к их загрузке регистрация уже активна, и управление они получают сами — так и вышло в опыте с областью /app. Но в настоящем приложении у claim есть цена: документ, начавший жизнь без воркера, вдруг оказывается под ним, и половина его запросов прошла мимо кеша, а половина — через. На первой установке это обычно безобидно, а при обновлении версии — источник самых неприятных ошибок главы; им и посвящена статья «Обновление воркера: старая версия держит вкладки».

controller — это не «воркер активен», а «этот документ ходит в сеть через воркера». Два разных вопроса, и путают их постоянно.

Автомат жизненного цикла понадобится снова в статье про обновление воркера — там он придёт готовым, собирать его заново не придётся. А следующая статья даст доске маршрутизатор запросов: три стратегии кеша и правило, какую из них применять к какому запросу.