Загрузка веб-модулей в хост-приложениях
Источник:
ds-docs/reference/guidelines/web-module-loading.md
Состояние загрузки продуктового веб-модуля. Не «просто скелетон» — задача понять, какую часть экрана можно быстрее всего отобразить пользователю (скелетон + анимированные переходы). Связано: preloader-screen, skeleton, README.
Контекст
Микрофронты (React) встраиваются как окошки (iframe) в хост-приложения (Flutter, Cordova).
- Проблема 1. Микросостояние при загрузке отображения микрофронта в хосте занимает ~1.5 сек — всё это время висит Preloader Screen («яблочко&монетка»), пока не загрузится весь контент.
- Проблема 2. При переходе между микрофронтами Preloader Screen показывается долго — каждый раз ждёт полной загрузки.
Цель — показывать Preloader Screen только до первой статичной части интерфейса, сокращая время его отображения при переходах.
Статические vs динамические данные
Дизайн делится на статические (не меняются) и динамические (приходят с бэка, дольше всего). Динамику отображаем позже всего.
3–4 состояния загрузки (для ускорения)
- Полный скелетон — лёгкая фейк-вёрстка, быстро качается и показывается.
- Статичные данные — микрофронт загрузился, показывает часть данных; блоки с динамикой ещё в загрузке.
- Динамические данные — части интерфейса, приходящие позже всего.
- Загруженная страница — всё готово.
Если этапов 2/3 нет — можно не показывать (выясняется с разработчиком). Экраны загрузки проектировать с учётом UX: при слабом интернете/отвале сервиса пользователь может застрять на них. Задача ускоряет отображение микрофронтов (~на 1 сек раньше).