Ручная реализация оптимистичных обновлений

Ручные оптимистичные обновления начинаются с локального состояния компонента, инициализированного данными сервера: const [items, setItems] = useState(serverItems). Именно это локальное состояние вы отображаете и оптимистично изменяете. Данные, полученные с сервера, NOT следует изменять напрямую — храните управляемую локальную копию.

Когда пользователь запускает операцию изменения данных (нажимает «Добавить», «Нравится» или «Удалить»), немедленно обновите состояние до вызова API: setItems(prev => [...prev, newItem]). Интерфейс сразу отражает изменение. Только после этого отправьте фактический сетевой запрос.

Перед оптимистичным обновлением сохраните текущее состояние: const previousItems = items. Этот снимок является целью отката. Если вызов API завершится ошибкой, восстановите это значение. Храните его в переменной, а не в состоянии, поскольку оно нужно только на время ожидания завершения операции изменения данных.

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

В блоке обработки ошибки операции изменения данных вызовите: setItems(previousItems). Это восстановит состояние, существовавшее до оптимистичного обновления. После отката покажите уведомление об ошибке. Пользователи понимают, что редкие ошибки случаются, — но они не могут мириться с незаметным несоответствием.

После отката покажите сообщение об ошибке: «Не удалось сохранить изменения. Повторите попытку.» — и добавьте кнопку «Повторить», которая снова запускает ту же операцию изменения данных. Это даёт пользователям возможность управлять ситуацией. Сочетание отката, уведомления об ошибке и повторной попытки позволяет корректно обработать сбой, не блокируя весь интерфейс.

При оптимистичном добавлении нового элемента сервер ещё не назначил ему настоящий идентификатор. Создайте для оптимистичного элемента временный идентификатор: const tempId = crypto.randomUUID(). Используйте его как ключ элемента в списке. После успешного ответа API замените временный идентификатор настоящим идентификатором, назначенным сервером.

После успешного создания элемента сервер возвращает настоящий идентификатор. Обновите состояние, заменив временный элемент: setItems(prev => prev.map(item => item.id === tempId ? { ...item, id: serverResponse.id } : item)). Это согласование гарантирует, что последующие операции используют правильный идентификатор сервера.

Если пользователь запускает две операции изменения данных с очень маленьким интервалом, ответы могут прийти не по порядку. Ответ второй операции может прийти раньше первого, а откат первой операции — перезаписать корректное состояние, полученное от второй. Это состояние гонки, характерное для оптимистичного интерфейса.

Один из способов решить проблему состояний гонки — сериализовать мутации с помощью очереди. Пока мутация выполняется, отключайте кнопку запуска (устанавливая состояние isSubmitting в true). Разрешайте следующую мутацию только после завершения предыдущей. Это снижает отзывчивость, но гарантирует правильный порядок обновления состояния.

Для операций удаления: сохраните предыдущие элементы, отфильтруйте удаляемый элемент из состояния, вызовите API удаления и при ошибке выполните откат. Удаление проще создания (не требуется согласовывать ID), но принципы те же. Перед вызовом API можно добавить небольшую задержку и показать вариант «отменить», чтобы пользователь мог отменить удаление.

Почему добавленным оптимистично элементам нужен временный ID?

Ручной подход: сохраните previousItems, установите новое состояние с помощью setItems, вызовите API, а при ошибке выполните откат с помощью setItems(previousItems) и покажите ошибку. При добавлении используйте crypto.randomUUID() как временный ID, а после успешного выполнения согласуйте его с ID сервера. Предотвращайте состояния гонки, отключая кнопку запуска на время выполнения мутаций. Откат, уведомление и повторная попытка — стандартный пользовательский сценарий при ошибке.