Центр событий
Рендерит плотный набор live-сущностей без глобальной перерисовки на каждый provider tick.
Сценарные состояния
Иллюстрация по теме
Визуальный ориентир помогает быстрее считать сценарий страницы и не оставлять компонент абстрактным.
Данные и ответственность
| Inputs | normalized entities + granular subscriptions |
|---|---|
| Outputs | visible cards, status badges, interaction intents |
| Failure mode | render storm, wrong list key, client lag |
| Ownership | UI владеет представлением и recoverable context; финальное бизнес-состояние подтверждает серверный контракт. |
Как не размыть ответственность
Компонент считается самостоятельной границей только если команда может назвать его входы, выходы и невозможные состояния. Если он требует читать provider-specific поля напрямую или хранит финальный статус операции только локально, граница выбрана слишком поздно.
При изменении контракта сначала обновляется state model и совместимость, затем визуальный слой. Это уменьшает риск ситуации, когда новый UI уже ожидает поле или статус, которого старая версия API не гарантирует.
Связанные разборы
Приёмочные сценарии
- Обновление одной selection не вызывает render всех карточек события.
- Сортировка списка сохраняет identity карточек через entity key, а не array index.
- Карточка вне viewport при возвращении читает текущий snapshot, а не replay старых анимаций.
- Состояние reconnect отличается от stale и от полного offline.
- Client lag измеряется отдельно от provider/server lag.
- Финальный статус события прекращает бессмысленные live-анимации и подписки.
Почему поток не равен списку компонентов
Оптимизация начинается с структуры состояния и подписок. Memoization применяется после того, как entity identity и область обновления определены корректно.
При review команда проверяет не название компонента, а его инварианты: какие данные он имеет право считать финальными, что обязан показать при деградации и как возвращается в согласованное состояние после сбоя.
Проверка под горячим матчем
Запустите поток, где один матч обновляется несколько раз в секунду, а остальные почти статичны. LiveCenter должен перерисовывать только подписанные сущности и не превращать каждую delta в полный render списка. Карточка вне viewport может снизить частоту paint, но при возвращении обязана сразу прочитать актуальный snapshot.
После краткого disconnect компонент получает новую точку синхронизации и не воспроизводит вслепую все пропущенные сообщения.
Для маршрута данных см. поток → отображение на клиенте.
Что проверять в горячий момент матча
Когда одновременно меняются счёт, таймер, карточки и коэффициенты, слабая компонентная граница становится видна сразу: экран начинает дёргаться, теряет focus или слишком шумно анимирует второстепенные изменения. Поэтому live-center проверяют не на спокойном списке, а в разгар матча с большим количеством delta. Хорошее сопровождение к этому компоненту — статья про точечные обновления без лишних перерисовок.