Начинать с модели страницы, а не с набора конечных точек
Спортивный web-продукт одновременно держит контекст матча, live-счёт, статистику, навигацию и персональные действия. Если каждый блок проектируется отдельно, пользователь получает рассинхрон: счёт уже новый, рынок ещё старый, а выбранный элемент исчез после сортировки. Поэтому архитектурная единица здесь — не API-ответ, а согласованное состояние экрана.
Какие пользовательский опыт-состояния нужно зафиксировать до разработки
Для event page и live-center полезно описать минимум: initial loading, ready snapshot, live updating, stale-but-readable, partially unavailable и terminal. Для интерактивных элементов добавляются selected, pending, confirmed, rejected и disabled/suspended. Это не декоративные статусы: они определяют текст интерфейса, aria-состояния, допустимые действия и требования к данным.
| Вопрос команды | Что фиксируем | Что считаем ошибкой |
|---|---|---|
| Что видит пользователь? | Явные состояния и переходы | Необъяснимый скачок или «вечный loading» |
| Кто источник истины? | Контракт клиента, API и внешнего источника | Два слоя считают себя финальными |
| Как деградируем? | Fallback, stale policy, retry и stop condition | Скрытый partial сбой |
Контракт клиентской части: точечные подписки вместо глобальной перерисовки
Поток обновлений стоит отделить от частоты visual commit. Нормализованный store, подписки по entity id и стабильные keys уменьшают радиус обновления. Для областей вне viewport допустима более низкая частота paint, но при возврате компонент должен читать актуальный snapshot, а не проигрывать очередь устаревших анимаций.
Публичный кэш и персональный контекст должны быть разведены
Страница события хорошо подходит для CDN-кэша, пока ответ одинаков для всех. Account state, персональные selections и разрешения пользователя относятся к другому классу данных. BFF или отдельные приватные запросы позволяют сохранить быстрый публичный shell и не смешивать пользовательские ответы в edge-cache.
Что измерять после релиза
Кроме LCP и INP, важны product-specific метрики: время от получения stream message до paint, доля stale-состояний, количество лишних render на delta, успешность восстановления выбранного контекста после refresh и время до первого полезного live snapshot.
Проверка перед объединением
До merge команда должна уметь пройти экран как state chart. Для каждой динамической области фиксируется событие, которое меняет состояние, источник новой версии и визуальная реакция. Если один и тот же provider delta приводит к полному rerender страницы, это повод пересмотреть granularity подписок, а не добавлять очередной memo.
| Проверка | Практический критерий |
|---|---|
| Context stability | Счёт, выбранная вкладка и selection не «прыгают» из-за сортировки соседних сущностей. |
| Freshness | Пользователь отличает live от stale; интерактивное действие не выглядит доступным при сомнительной версии данных. |
| Render scope | Один market delta не инвалидирует весь event tree без необходимости. |
| Keyboard/focus | Обновление списка не перемещает focus и не меняет accessible name неожиданно. |
Отдельно проверяется first meaningful state на слабом мобильном соединении: shell должен объяснять, что загружается, и не превращать задержку API в пустой экран.
Артефакты, которые стоит вынести из исследовательского этапа
Минимальный комплект для web track: карта event page с владельцами данных, таблица UX states, список entity subscriptions и короткий performance budget. Для интерактивных блоков отдельно фиксируются keyboard/focus правила и поведение при partial suspend.
- State table: событие → новое состояние → видимый текст → доступное действие.
- Data ownership map: публичный shell, live snapshot, персональный account state.
- Render граница ответственности: какие entity changes имеют право инвалидировать каждый блок.
- Release probe: synthetic live-session, которая ловит рассинхрон счёта, market version и UI paint.
Эти артефакты компактнее большой «архитектурной схемы», но ближе к реальным решениям команды и удобнее для code review.
Перед версткой полезно собрать живой страница события на одном матче
Статичный макет почти всегда скрывает главную сложность: данные приходят с разной скоростью. Возьмите матч с активным счётом, десятками рынков и персональным действием пользователя. Прогоните его от первого snapshot до завершения и отметьте, какие блоки меняются независимо. Так быстро видно, где нужен отдельный state owner, а где достаточно обычного server render.
Следующий проход делается уже не глазами дизайнера, а глазами пользователя: что останется на месте при обновлении коэффициента, куда вернётся focus после закрытия группы, не исчезнет ли выбранный market после сортировки. Для этого удобно сверить границы EventPage и путь данных к event page.
Как этот экран проверяют в рабочем спринте
Хороший признак живой продуктовой разработки — команда смотрит на event page не только как на макет, но и как на экран, который должен пережить реальный поток обновлений. Поэтому мы обычно берём один насыщенный матч, раскладываем страницу на отдельные зоны ответственности и проверяем, где можно удержать публичный shell быстрым, а где уже нужен приватный контекст пользователя. После такого прогона гораздо проще уточнить границы компонента EventPage и не переусложнять его лишней бизнес-логикой.
Второй шаг — вручную пройти состояния пользователя: открытие матча, переключение вкладок, возврат после refresh, live-обновление и частичную недоступность данных. На этом этапе особенно полезно сверить страницу с разбором точечных обновлений live-center, чтобы не раздувать перерисовку там, где продукту нужен спокойный и предсказуемый экран.
Поддерживающие материалы
Ниже — подробные разборы отдельных решений: от состояния интерфейса и границ компонента до интеграции и поведения при отказе.