Реактивная Архитектура: Пишем надежный Optimistic UI на чистом RxJS (Pattern Compensating Transaction)

[cmyser]

Pessimistic UI

Интерфейс блокируется, пока изменения не синхронизируются.

• Ухудшение отзывчивости пропорционально задержке сети и времени обработки запроса сервером.

• Пользователь не теряет контекст внесения изменений.

• Пользователь всегда понимает когда и как завершился каждый эпизод синхронизации.

• Синхронизация может быть инициирована лишь пользователем в явном виде.

Optimistic UI

Интерфейс показывает предположительное финальное состояние, проводя синхронизацию в фоне.

• Мгновенная обратная связь на действия пользователя в лучшем случае.

• Запуск синхронизации возможен без явного действия пользователя.

• Действия пользователя могут быть внезапно отменены через непредсказуемый промежуток времени.

• Если что-то пошло не так, а пользователь уже ушёл, то сложно адекватно объяснить ему, что произошло и что ему делать.

• Пользователь не понимает, когда изменения действительно синхронизированы и можно уходить.

Realistic UI

Интерфейс показывает все промежуточные состояния: актуально, идёт синхронизация и тп.

• Мгновенная обратная связь как на действия пользователя, так и на изменения состояния процесса синхронизации.

• Запуск синхронизации возможен без явного действия пользователя.

• Пользователь всегда понимает, когда изменения действительно синхронизированы и можно уходить.

• У каждого процесса синхронизации есть предсказуемое место в UI, где выводится его состояние.

https://github.com/hyoo-ru/mam_mol/wiki/Optimistic-vs-Pessimistic-vs-Realistic-UI Источник.

[nin-jin]

Тут более актуальный материал: https://mol.hyoo.ru/#!section=docs/=irbep1_kgl69e

[frostsumonner]

Пример с счетчиком слишком примитивный. Пусть в форме есть два текстовых поля (имя и кодовое слово) и доп. условие что кодовое слово не может содержать имя. Теперь представим, что пользователь сделал:
1. Ввел имя Bob
2. Ввел кодовое слово Secret
3. Поменял имя на John
4. Поменял кодовое слово на SecretBob

Допустим 3й запрос упал, а 4й еще в процессе - вот даже на уровне концепции объясни, что ты покажешь пользователю и что тут "Компенсация".

Получится просто и понятно? Если нет, то зачем вообще этот огород городить - есть изменение - есть запрос на сохранение, а при ошибке просто её показали и предложили ~перезагрузить страницу.

[AlekseyVY]

Привет, паттерны и структуры данных нельзя натягивать на любой кейс.

Описанный в статье подход предназначен для атомарных, независимых действий: лайк, каунтер, тоггл, добавление в корзину. Там, где UX требует мгновенного отклика и блокировать интерфейс нельзя.

Твой пример это форма со связанным состоянием, где валидация одного поля зависит от другого. В таком сценарии Optimistic UI в принципе противопоказан. Здесь достаточно стандартной обработки ошибки без компенсаций.

Не стоит забивать гвозди микроскопом. Статья решает проблему Race Conditions именно для потока атомарных событий.