Thread by @jsunderhood

Заканчиваем с флудом и переходим к главной теме дня — что не так с AJAX и как нам сделать новую парадигму общения клиента и сервера

У нас есть проблема, от которой все страдают, но мало кто замечает — так как мы не говорим об этом.

Наши веб-приложения отвратительно работают с сетью.

Проблема, что мы разрабатываем их в идеальных условиях, а реальная сеть темна и полна ужасов.

Картинки в тему от @nikitonsky

Проблема 1 «нарушение порядка»:

В поиск вводят X, отправляем X AJAX на сервере. Потом тут же добавляют XY, отправляем.

Но с сервера ответы приходят в другом порядке — XY, X.

В итоге в поиске написано XY, а результаты для X. Даже у ВК была такая ошибка.

Решение «в лоб» в введении счётчика запросов и, при получении ответа, сравнении последнего и текущего номера запроса
gist.github.com/ai/fa3999b22a6…

Проблема 2 «рассинхронизация деплоя»:

Вышла новая фича, обновили API между клиентом и сервером. Депллоим вместе клиент и сервер.

Но у нас SPA и пользователи неделями не обновляют страницу приложения. В итоге старый JS посылает AJAX на новый сервер и всё ломается.

Решение «в лоб» в HTTP-заголовках с номером версии клиента и сервера. Если версия клиента не поддерживается, сервер отвечает специальным кодов. Глобальный обработчик запросов на этот код показывает UI с просьбой обновить страницу.

Проблем 3 «оборванный лоадер»:

Показываете крутилку, отсылаете AJAX на сервер.

Интернет слега мигает (метро или помехи в LTE) — fetch() выкидывает catch() для которого забыли обработчика. В UI вечно крутится лоадер без возможности отменить запрос.

«Просто ставь catch()» — не решение. Тем более 500 ответ не идёт в catch(). Мы все люди и легко забыть. Нужно делать обёртку над fetch(), где обработчик на 500 будет стоять глобально. И глобальный UI, чтобы показать что была ошибка сервера.

Проблема 4: отсутствие оптимистичного UI.

Едешь в метро (в Нью-Йорке в тунеле нет Интернета), увидел вопрос. Написал ответ — скучаешь и ждёшь станции, чтобы отправить написанный ответ.

Надо как в Телеграме. По нажатию на Отправить сворачиваем форму, но показываем, что ответ только публикуется. Пост ставим в очередь в ожидании связи.

Опционально можно сделать ещё круче. Если ответа нет минут 15, то он мог потерять актуальность. Убираем его из очереди. Показываем в ОС уведомление, что отправка не удалась, проверьте актуально ли.

Проблема 5 «ненастоящий оптимистичный UI».

Вот в приложении Твиттера можно кликнуть на лайк, он покажет что лайк засчитан, отматываешь ленту на пару экранов вперёд. С AJAX приходит ошибка (так как связь в метро пропала) — твиттер-клиент показывает, что лайк не засчитан.

Если вы показываете успех до прихода ответа с сервера (оптимистичный UI) важно:
1. очередь сообщений — посылать их заново, когда связь появилась
2. UI, что есть запросы в очереди

Проблема 6 «ад вкладок»:

Если сайт открыт в нескольких вкладках, то там вечно несинхронизированные данные. Например, кол-во товаров или уведочлений будет отличаться в разных вкладках.

Данные между вкладками можно синхронизировать через localStorage. При его изменении выбрасывается событие storage.
developer.mozilla.org/en-US/docs/Web…

Проблема 7 «конфликты редактирования»:

Пользователь А открыл документ. Б открыл тот же документ. Пока А что-то правит, Б не видит этих изменений. В итоге Б затрёт изменения А.

UI «Документ был изменён кем-то ещё, объедините правки руками» — тоже ад.

Лёгкого решения тут нет на текущем стеке технологий. Надо делать живое обновление — а даже это сложнее, чем может большинство проектов себе позволить.

А отдельный ад, когда даже в простом приложении с кучей ошибок вы заходите в код работы с AJAX-запросами. Там обычно очень сложная архитектура и куча кода.

Люди добавляют саги, action creators и т. п.

А что ваш раздражает в работе с сетью у мобильных приложений и веб-приложений вокруг вас?