UX при eventual consistency: свободное припоминание
Промпты на свободное припоминание по юниту. Сначала ответь своими словами, затем раскрой модельный ответ и сравни.
Припоминание сильнее перечитывания. На каждый промпт проговори или запиши полный ответ по памяти, прежде чем открыть модельный — именно усилие припоминания закрепляет материал.
Восстанови ключевые идеи юнита — consistency-окно, трёхчастный контракт optimistic UI, когда показывать pending-состояние, идемпотентные retry и осознанный conflict resolution — не подглядывая в урок.
- 01Что такое consistency-окно и почему асинхронный бэкенд делает его проблемой фронтенда?
- 02Сформулируй трёхчастный контракт optimistic UI и какую часть пропускают джуны.
- 03Когда optimistic UI — неверный инструмент и что показывать вместо него?
- 04Почему каждому pending-состоянию нужен timeout и какие два failure mode тут таятся?
- 05Объясни компромисс LWW vs merge vs CRDT для разрешения двух конкурентных асинхронных записей и роль фронтенда в каждом случае.
- 06Почему «POST, а затем сразу рефетч» ломает read-your-own-writes и как сохранить итоговый refresh без нарушения?
Если ты смог восстановить каждый ответ по памяти, ты держишь хребет юнита: асинхронная запись переносит consistency-окно на фронтенд; контракт apply-send-reconcile у optimistic UI покупает ~0мс воспринимаемой задержки, но без шага rollback это ложь; когда исходом владеет сервер, ты показываешь честное pending-состояние под защитой timeout; double-submit делается безопасным через idempotency key; конкурентные записи разрешаются осознанно (LWW для простых полей, CRDT для общего текста); а read-your-own-writes выживает за счёт локального эха вместо доверия гоночному рефетчу. Теперь, когда проектируешь следующую фичу над асинхронным бэкендом, ты можешь назвать consistency-окно, выбрать верный контракт для каждого действия и объяснить это любому, кто считает, что 202 означает «готово».
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.