Как построить приложение на React и Redux для обработки данных из веб-сокетов и отображения на UI

Что проверяют

Понимаете ли вы, где должно жить соединение, как поток сообщений попадает в стор и что будет при сотне событий в секунду и обрыве сети. Следом спрашивают про переподключение и производительность рендера.

Как отвечать

Начните со стека: сегодня это Redux Toolkit (configureStore, createSlice), а не ручной createStore, который помечен устаревшим. Create React App тоже официально устарел, проект собирают на Vite или внутри фреймворка.

Каркас архитектуры:

• соединение вне компонентов: отдельный сервис или кастомный middleware открывает WebSocket, слушает сообщения и диспатчит actions. Сам объект сокета в стор не кладут, он несериализуем;
• RTK Query: если данные сначала грузятся запросом, а потом обновляются по сокету, есть готовый паттерн через onCacheEntryAdded и updateCachedData;
• нормализация: createEntityAdapter хранит сущности по id, обновление одной строки не пересоздаёт весь список;
• чтение: useSelector с мемоизированными селекторами из createSelector, компонент подписывается только на свой кусок;
• большой поток: сообщения копятся в буфере и уходят одним action раз в 100 мс или на кадр, длинные списки виртуализируются, например через TanStack Virtual;
• надёжность: переподключение с экспоненциальной задержкой, heartbeat, повторная подписка, снапшот плюс дельты с номером последовательности.

Уточните протокол: socket.io-client работает только с сервером Socket.IO, для обычного WebSocket-сервера нужен нативный WebSocket.

Где спотыкаются

Открывают соединение в useEffect компонента и забывают закрыть его в cleanup. При ремаунте и в StrictMode, где эффекты в разработке запускаются дважды, получаются два соединения и дубли сообщений.

Диспатчат action на каждое сообщение и копят массив без ограничения. Интерфейс тормозит, память растёт, а key={index} при добавлении сообщений в начало списка заставляет перерисовывать все строки.

Не продумывают обрыв. После переподключения данные молча расходятся с сервером, потому что пропущенные события никто не догружает.