Оптимістичні оновлення в React без пошкодження даних

Користувач натискає «Зберегти» в React-застосунку й очікує, що інтерфейс зміниться одразу. Мережевий запит триває 800 мілісекунд, тому інтерфейс або здається повільним, або показує спінер, поки користувач чекає. Очевидне рішення — оптимістичне оновлення: спочатку змінити екран, а запит виконати у фоновому режимі.

Це працює, доки запит не завершиться помилкою, користувач не натисне кнопку двічі, інша вкладка не змінить той самий запис або сервер не нормалізує передане значення. Після цього інтерфейс може показувати дані, яких на сервері ніколи не існувало. Оптимістичний UI — це не просто прийом рендерингу. Це невеликий протокол узгодженості між тимчасовим станом клієнта та авторитетним станом сервера.

Що насправді обіцяє оптимістичне оновлення

Оптимістичне оновлення робить припущення: «Якщо мутація завершиться успішно, наступний стан сервера виглядатиме так». Клієнт одразу показує передбачений стан, але має бути готовим прийняти інший, авторитетний результат.

• Інтерфейс змінюється до завершення запиту.
• Поки мутація очікує результату, її можна однозначно ідентифікувати.
• Після помилки система відновлює або повторно завантажує надійний стан.
• Успішна відповідь може замінити припущення даними із сервера.
• Паралельні мутації не можуть непомітно перезаписати новіший намір користувача.

Саме останній пункт найчастіше створює проблеми. Одного булевого значення на кшталт isSaving недостатньо, щоб описати дві мутації, їхній порядок або визначити, яку відповідь безпечно застосувати.

Починайте з моделі мутації, а не з boolean

Для простого перемикача налаштування очікувану мутацію можна описати явно. Клієнт зберігає ID мутації, значення, яке потрібно застосувати, і попереднє значення для можливого відкату.

type PendingMutation<T> = {
  id: string;
  previous: T;
  next: T;
  startedAt: number;
};

type PreferenceState = {
  value: boolean;
  pending: PendingMutation<boolean>[];
  error?: string;
};

Така структура робить життєвий цикл видимим. Мутація створюється, оптимістично застосовується, завершується успішно або відхиляється, а потім видаляється. Стан стає докладнішим, ніж isSaving, але саме ці додаткові дані роблять обробку помилок детермінованою.

Відкат не завжди є правильним відновленням

Для ізольованого boolean-значення відновити previous цілком логічно. Для списку, форми або спільного запису це може бути небезпечно. Поки запит очікував відповіді, сервер міг прийняти іншу зміну, а користувач — виконати ще одне локальне редагування. Механічне відновлення старого знімка може стерти коректні новіші дані.

Вибирайте одну з трьох стратегій відновлення залежно від типу мутації:

Повторне завантаження часто виглядає менш елегантно, ніж відкат, але воно безпечніше, коли клієнт не може довести, що його знімок досі актуальний. Коректність важливіша за збереження оптимістичної анімації.

Не дозволяйте застарілим відповідям перемагати

Уявімо два швидкі редагування: користувач змінює заголовок на «Чернетка», а одразу після цього — на «Опубліковано». Другий запит може завершитися першим. Якщо пізнішу відповідь від першого запиту застосувати без перевірки, інтерфейс повернеться назад.

Є два поширені способи цього уникнути:

1. Серіалізувати мутації, якщо порядок має значення. Надсилати наступний запит лише після завершення попереднього.
2. Відстежувати клієнтську ревізію й застосовувати відповідь лише тоді, коли вона все ще відповідає поточній ревізії.

let revision = 0;

async function updateTitle(title: string) {
  const requestRevision = ++revision;
  applyOptimistically(title);

  const result = await saveTitle(title);

  if (requestRevision === revision) {
    replaceWithServerValue(result.title);
  }
}

Ревізія захищає представлення від застарілих відповідей, але не змушує сервер обробляти запити в потрібному порядку. Якщо бекенд сприймає мутації як залежні від порядку, додатково використовуйте чергу або модель ідемпотентних команд.

Тимчасові ID і дані, нормалізовані сервером

Під час створення елемента виникає інша проблема: клієнту потрібен ID ще до того, як сервер його поверне. Згенеруйте тимчасовий ID, який неможливо сплутати зі справжнім ID бази даних, одразу покажіть елемент, а після успіху замініть його серверним об’єктом.

Не припускайте, що сервер поверне точно те, що надіслав клієнт. Він може обрізати текст, призначити права, обчислити похідні поля, додати часові мітки або відхилити дубль. Після успішної відповіді зазвичай варто замінити оптимістичний об’єкт серверним, а не необережно об’єднувати їх.

Розділяйте стан сервера та стан інтерфейсу

Очікувана мутація — не те саме, що дані сервера. Якщо змішати їх в одному неструктурованому об’єкті, стає складно відповісти на базові питання: це значення підтверджене? Воно тимчасове? Який запит його створив? Чи потрібно показати помилку поруч із цим рядком?

Корисна межа виглядає так:

• Стан сервера містить останні відомі авторитетні дані.
• Стан мутацій містить операції, що очікують завершення, та їхні статуси.
• Похідний стан UI визначає, що саме бачить користувач, коли ці шари відрізняються.

Таке розділення також спрощує тестування. Можна перевіряти логіку reducer або переходів стану без рендерингу всієї сторінки, а потім окремо перевірити, чи правильно компонент показує очікування, успіх і помилку.

Практичний чекліст реалізації

• Надавайте кожній мутації унікальний клієнтський ID.
• Зберігайте достатньо даних, щоб пояснити помилку або відновитися після неї.
• Блокуйте дубльовані дії лише тоді, коли повторний намір недійсний; в інших випадках моделюйте операції.
• Захищайтеся від застарілих відповідей, якщо мутації виконуються паралельно.
• Після успіху замінюйте оптимістичні сутності відповідями сервера.
• Для спільних або складних записів обирайте повторне завантаження, якщо відкат неоднозначний.
• Показуйте помилку поруч із відповідним контролом, а не ховайте її лише в глобальному toast.
• Тестуйте повільні відповіді, відхилені запити, подвійні кліки, відповіді не за порядком і unmount компонента.

Бібліотеки на кшталт TanStack Query можуть взяти на себе значну частину життєвого циклу мутації кешу, але не можуть вирішити, чи є конкретний відкат семантично безпечним. Складна частина все одно залишається предметним моделюванням: потрібно розуміти, чи є операція комутативною, оборотною, ідемпотентною або залежною від порядку на сервері.

Головне правило

Оптимістичні оновлення надійні тоді, коли клієнт сприймає їх як попередні й задає кожній мутації чіткий життєвий цикл. Мета не в тому, щоб зробити мережу невидимою. Мета — скоротити відчуття затримки, не вдаючи, ніби сервер не може заперечити клієнту.

Коли застосунок має багато взаємопов’язаних мутацій, складні форми або кілька джерел спільних даних, якість цих меж стає архітектурним питанням. Розробка складних вебзастосунків WebMriya допомагає вибудувати передбачувані потоки між клієнтським і серверним станом, не перетворюючи кожен компонент на власну систему синхронізації.