Optimistic UI

На своём выступлении я уже упоминал хук useOptimistic из React, но здесь расскажу чуть подробнее, в чём его идея.

Хук useOptimistic добавится в React только в версии 18.3.0. Вроде бы хук новый, но по сути это просто частный случай применения дизайн-паттерна Optimistic UI, который на слуху уже как минимум лет 7. Но React позволяет использовать этот подход чуть более гибко.

В чём смысл паттерна

При использовании паттерна Optimistic UI ваш интерфейс отобразит положительный результат операции, не дожидаясь обработки этой операции сервером. Иными словами, мы заранее предполагаем, что всё ок, и сразу показываем пользователю успешный результат.

Пример, который я приводил в докладе: лайки.
Вы ставите лайк на пост, и сердечко сразу становится красным, никаких спиннеров и лоадеров, никаких «подождите, пожалуйста» и т.д., пользователь сразу видит успешный результат, хотя бэк всё ещё сохраняет его лайк куда-то в БД и ещё не вернул успешный результат.

В документации к React даётся немного другой пример: они там и успешный результат сразу отображают, и индикатор выполнения позволяют добавить, если он вам нужен. Это уже некий гибрид между Optimistic UI и каким-то AJAX-спиннером из 2005 года))

Когда использовать Optimistic UI

Я точно не стал бы использовать этот подход для тех сервисов и операций, результат которых критично важен для клиента. Было бы странно показать клиенту, что его карта успешно оформлена, а через 2 секунды переобуться. Такие оптимизации нам не нужны))

Даже лайки из моего примера могут быть критичными в некоторых случаях. Например, я иногда пересматриваю лайкнутые видео, и я бы очень расстроился, если бы то, что я лайкнул, не добавились в список понравившихся видосов;

Поэтому, используем на свой страх и риск, если:

- вы на 100% уверены, что неверно угаданный вами результат операции не испортит пользовательский опыт. Об этом я бы задумывался в первую очередь;

- вы уверены в стабильности своего API. Если у вас часто стреляют ошибки, то я бы лучше сфокусировался на стабильности и предсказуемости результата выполнения операции;

- обработка вашей операции занимает не более 2 секунд. Иначе, как минимум, пользователь может уйти слишком далеко от того места, где он работал с вашим сервисом. Никому не понравится возвращаться назад и что-то исправлять;

В этом плане реализация от React довольно удобна и безопасна: там всё таки остаётся возможность не только заранее отрисовать успешный результат операции, но и условный спиннер прикрутить тоже получится при желании. Пользователь получает и отзывчивый интерфейс, и информацию о выполнении его действия.

А причём тут скорость загрузки страницы то?

Да даже загрузочный экран заранее отрисовать после нажатия на ссылку — уже улучшите себе Interaction to Next Paint.

Или, например, вы уже знаете, что у пользователя есть две песни в плейлисте. Первая песня выбрана, по ней отображается UI проигрывателя. Пользователь кликает на другую песню — нам ведь не обязательно все 10 мегабайт трека скачивать, прежде чем мы кнопку Play отрисуем. Вот и рисуем сразу. А если потом окажется, что на серваке с этой песней что-то не так — тогда и отображаем ошибку.

Так что пользуемся, но с осторожностью))
И напоминаю, что это просто примеры, взятые из моей фантазии, а не рекомендации. В любом случае, только вам решать, подходят они под ваш кейс или нет. Если не подходят — ну ок))