Матрица сценариев офлайн-приложения
Основная часть серии уже объяснила manifest, worker, сохранение и обновление. Но программа становится понятной только тогда, когда мы способны описать её поведение при разных условиях. Одна проверка «открылось без сети» пропускает первый запуск, несохранённые ссылки и новую версию в соседней вкладке. Составим матрицу, которая показывает эти различия.
В таблице ниже находятся ожидаемые результаты учебного offline-lab. Это план будущих наблюдений, а не журнал проведённых испытаний. У каждой строки есть исходное состояние, действие и критерий. Реальный протокол позднее добавит браузер, версию, устройство и фактически наблюдённое поведение. Без такого разделения предположение быстро начинает выглядеть как подтверждённый результат.
Фиксируем исходное состояние
Сначала запишите origin и набор файлов. Изменение порта создаёт другой origin и может дать пустое хранилище даже на той же машине. Разные профили браузера тоже не обязаны иметь общие данные. Отсутствие копии в новом профиле не является доказательством того, что приложение удалило её в старом.
Затем фиксируется управляющий worker. Страница без controller, вкладка под v2 и вкладка под v3 — разные состояния. Открытый DevTools или включённые настройки обхода worker способны изменить путь запроса, поэтому они тоже входят в условия. Не переносите вывод из специального режима браузера на обычный пользовательский запуск без повторной проверки.
Наконец, перечислите сохранённые документы. Для базового состояния обязательны главная, запасная страница, XML, реестр и модули. Markdown находится в кеше только после явного успешного выбора. Список проверяется по текущему именованному кешу, а не по воспоминанию о нажатой кнопке. Браузерное хранилище имеет ограничения и может быть очищено. Хранение и вытеснение.
Основные строки
| Исходное состояние | Действие | Ожидаемый критерий |
|---|---|---|
| Новый профиль, сеть недоступна | Первый запуск | Приложение не обещает ранее не полученный HTML |
| Подготовленный v2, controller есть | Открыть точный XML без сети | Возвращается сохранённая XML-глава |
| Подготовленный v2, Markdown не выбран | Открыть Markdown без сети | Запасное объяснение503, не ложный404 |
| Markdown записан в текущий кеш | Открыть его без сети | Доступна копия, оформление в базовом состоянии встроено |
| Сервер доступен и ответил404 | Открыть известный удалённый путь | Сохраняется смысл сетевого404 |
| Новый worker ждёт | Продолжить старую вкладку | Старый controller не объявляется новым |
| Кандидат не получил модуль | Завершить установку | Новая установка не считается успешной |
| Кеш главы очищен | Пересчитать список | Надпись сохранения не остаётся ложной |
Таблица отделяет отсутствие первоначальной загрузки от потери уже подготовленной копии. Установленное приложение не может получить неизвестный материал из ничего. Поэтому автономность оценивается относительно конкретного набора и выполненной подготовки. Слово PWA само по себе не меняет это физическое ограничение.
Для XML используйте его постоянный путь с .php. Отдельно добавьте вариант с ?print=1, который пока не нормализован. Для якоря внутри сохранённого XML ожидается та же HTML-копия и переход к существующему устойчивому разделу. Эти случаи помогают увидеть различие между документом, его представлением и местом внутри документа.
Не сводим сеть к переключателю
У браузера может быть подключение, но нужный origin не отвечает. Запрос способен завершиться поздно, получить500 или вернуть неправильный тип. Эти варианты не совпадают с быстрым отклонением Promise. Наша стратегия network-first сначала ждёт сетевой результат; введение ограничения времени потребует отдельного решения, которое не содержится в текущем worker.
HTTP500 тоже является ответом fetch. Минимальный обработчик возвращает его как есть. Если позже редакция захочет показывать сохранённую копию при некоторых серверных ошибках, нужно явно перечислить статусы и объяснить пользователю, что открыт прежний материал. Такая политика отличается от подмены любого неуспешного ответа одинаковым успешным HTML.
Проверка через обычный офлайн-режим браузера полезна, но не покрывает все реальные сбои. Для будущей практики нужны и запрос, который начался до потери подключения, и медленный ответ, и отказ одного обязательного ресурса. Мы описываем критерии заранее, чтобы позже наблюдение не подгонялось под желаемый исход.
Обновление и несколько вкладок
Подготовьте отдельные строки для одного и двух открытых окон. Пока v2 управляет страницами, v3 может оставаться waiting. Закрытие одной вкладки не обязательно освобождает старый экземпляр, если другая продолжает работать. Отсутствие активации в этой ситуации не доказывает ошибку нового файла. Жизненный цикл service worker.
Новый HTML также может быть получен по сети раньше перехода controller. Запрос имени кеша из седьмого урока должен обращаться к текущему управляющему worker. Если старый экземпляр ещё не поддерживает протокол, интерфейс сообщает недоступность сохранения. Он не выбирает v3 только потому, что свежая разметка знает такое имя.
Не включайте принудительный reload в критерий успешного обновления без условия. Читатель может заполнять форму или держать несохранённую заметку. Наш учебник пока не содержит такой формы, но будущая функция не должна потерять данные из-за скрытого допущения. Явное решение пользователя и сохранение локального состояния будут темой четырнадцатого урока.
Запись наблюдений
Удобная строка протокола содержит scenario_id, browser_version, origin, worker_version, saved_ids, network_condition, expected, observed и conclusion. Поле observed остаётся пустым до наблюдения. Если критерий не удалось проверить, записывается причина, а не слово «пройдено». Для учебного материала это особенно важно: повторяемость объясняется условиями, а не авторитетом автора.
Сохраняйте и отрицательные результаты. Например, в определённом браузере нет ожидаемой кнопки установки, хотя обычное офлайн-чтение работает. Возможности установки различаются, и отсутствие одного интерфейса не равняется отказу всех автономных функций. Проверка делится на установку, управление запросами и фактическую доступность материалов. Установка PWA.
Матрица завершает основной блок серии. Мы знаем, что приложение умеет, каких данных требует и как должно сообщать об ограничениях. В углублённых уроках изменится состав пакета и появятся локальные закладки. Новые случаи будут добавляться к этой же системе, а не заменять её одним общим утверждением «офлайн работает».