Browser-хранилище, offline и PWA¶

Требования этого документа применяются к прикладным данным в browser storage, заявленным offline-сценариям, service worker и устанавливаемым Progressive Web App (PWA). Кэширование HTTP-представлений дополнительно регулируется INT-CACHE. Уровни обязательности определены в корневом README.md.

FE-OFF-001. Жизненный цикл данных browser storage¶

Уровень: MUST

Применяется к: прикладным данным в localStorage, sessionStorage, IndexedDB, Cache Storage или эквивалентном browser-хранилище, переживающим владельца страницы либо доступным нескольким browser-контекстам

Каждый набор данных должен иметь владельца, классификацию, authoritative источник, срок хранения и условие удаления. Если данные может прочитать другой release приложения, формат должен иметь версию и миграцию либо определённое удаление. Данные разных субъектов должны быть изолированы; выход, отзыв прав и смена субъекта должны удалять либо делать недоступными защищённые данные по FE-API-008.

Приложение должно иметь определённый результат при запрете storage, исчерпании quota, очистке браузером, частичной записи и несовместимой версии. Пустое хранилище не должно интерпретироваться как подтверждённое отсутствие данных в authoritative источнике. Credentials дополнительно регулируются FE-SEC-004.

Обоснование¶

Browser может очистить или частично сохранить локальные данные, а общее хранилище переживает страницу и иногда пользовательскую сессию.

Проверка¶

тест смены субъекта, выхода и отзыва прав;
тест запрета storage, исчерпания quota и очистки;
миграционный тест предыдущей и неизвестной версии формата.

Исключения¶

Неизменяемый публичный ресурс с content hash MAY не иметь отдельной версии формата сверх имени и HTTP-контракта кэширования.

FE-OFF-002. Объявленный offline-результат¶

Уровень: MUST

Применяется к: приложению, заявляющему пользовательскую работу без сети

Проект должен определить закрытый перечень доступных offline-операций, источник показываемых данных, максимальную допустимую давность и результат каждой операции без связи. Интерфейс должен отличать локальные данные от подтверждённых актуальных данных и ожидающую синхронизации операцию от завершённой.

Операция, которую нельзя безопасно выполнить offline, должна быть недоступна либо завершаться явным результатом без фиктивного успеха. Появление сетевого интерфейса не должно считаться подтверждением доступности authoritative сервиса.

Обоснование¶

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

Проверка¶

e2e-тест запуска и каждой операции из объявленного offline-перечня;
тест устаревших данных и недоступного authoritative сервиса;
проверка различия pending, confirmed и failed результата.

Исключения¶

Приложение без заявленного offline-сценария MAY показывать только сообщение о недоступности; это не считается offline-работой.

FE-OFF-003. Повторная синхронизация и конфликт¶

Уровень: MUST

Применяется к: изменению, сохранённому для последующей синхронизации

Изменение должно сохранять стабильный идентификатор операции, исходную версию данных и payload, необходимый для безопасного повтора. Retry должны быть ограничены, использовать один идентификатор и не создавать новый бизнес-эффект. Порядок независимых операций не должен подразумеваться без контрактной гарантии.

Конфликт с более новой серверной или локальной версией должен приводить к объявленному merge, выбору пользователя либо отклонению; молчаливый last-write-wins запрещён без явной семантики. Терминальный отказ должен оставаться наблюдаемым и позволять удалить, исправить или повторить операцию без потери её результата.

Обоснование¶

После длительного offline-периода серверное и локальное состояния изменяются независимо, а повтор доставки создаёт дубликаты без стабильной identity.

Проверка¶

тест reconnect, повторной доставки и перестановки операций;
конкурентный тест локальной и серверной версии;
тест исчерпания retry и восстановления после restart браузера.

Исключения¶

Last-write-wins MAY использоваться для явно объявленного поля, если версия и потерянное значение остаются доступными для проверки.

FE-OFF-004. Release lifecycle service worker и PWA¶

Уровень: MUST

Применяется к: приложению с service worker или устанавливаемым PWA

Service worker должен иметь версию release, определённые правила install, activation и удаления старых caches. Обновление не должно одновременно использовать несовместимые application shell, schema локальных данных и API. Неуспешная установка или миграция должна сохранять последний работоспособный release либо показывать восстановимый отказ.

Устанавливаемое PWA должно публиковать валидный web app manifest со стабильными id, start_url и scope, пользовательским именем и ресурсами текущего release. Offline fallback не должен маскировать отсутствие прав, несуществующий маршрут или неподтверждённую операцию.

Обоснование¶

Service worker переживает deployment и способен продолжать отдавать старый код, а нестабильная identity manifest создаёт отдельные установки одного приложения.

Проверка¶

e2e-тест первого install и обновления с предыдущего release;
тест отказа install, activation и миграции schema;
проверка manifest и запуска установленного приложения;
тест offline fallback для отсутствия прав и неизвестного маршрута.

Исключения¶

Приложение без service worker не выполняет его lifecycle. Приложение, не заявленное устанавливаемым, не обязано публиковать web app manifest.