Методология: Реализация Logi c для действий пользователя? (Без дублирования кода между клиентом и сервером или неприемлемого UX) - PullRequest
0 голосов
/ 16 января 2020

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

Итак, мой вопрос: Каковы наилучшие практики для реализации этого ? У меня есть два наивных решения, но я думаю, что у них обоих есть некоторые недостатки. Поэтому мне интересно, есть ли лучшее третье решение, или одно из моих решений - это то, что делают все.


Для вашей информации, вот две мои попытки:

Метод А : при нажатии запускаются две вещи. (1) Непосредственно измените состояние (например, в Redux), установив state.thumbup=true, и тогда React автоматически выполнит повторную визуализацию интерфейса. В то же время (2) отправьте сообщение HTTP на сервер. Когда сервер получит его, он обновит свою базу данных (например, user.setThumbUp(true);repo.save(user);).

Проблема в том, что мне нужно продублировать мои логи c дважды , один раз в клиенте ("если щелкнуть, state.thumbup становится 1") и один раз в сервер («если клиент щелкает, одно место в базе данных меняется на 1»). В нашем примере это просто, но оно не подчиняется правилу KISS, и много кода дублируется, когда действие усложняется ...

Метод B : при нажатии клиент не изменяет местное состояние. Вместо этого мы отправляем только HTTP-сообщение на сервер. Затем сервер получает его и изменяет свою базу данных. После того, как мы знаем, что сервер выполнил свою работу, клиент запускает HTTP-запрос get, чтобы получить последнее состояние всей страницы. После того, как клиент получает данные, он рендерится, и пользователь видит, что большой палец окрашен.

Конечно, это делает дублирование кода исчезающим. Однако теперь пользователь будет долго ждать (в ожидании HTTP-запроса), прежде чем увидит, что пользовательский интерфейс изменен. Кажется, это тоже очень плохо ...

Поэтому интересно, есть ли лучшее решение? Или все просто используют первый метод? Большое спасибо!

1 Ответ

1 голос
/ 16 января 2020

Метод А лучше. Чтобы решить ваши проблемы:

  1. Дублирование логики c: вам нужно всего лишь дублировать, так сказать, «операцию записи». Редуктор сохранит состояние thumbs up, а создатель действия отправит запрос api «thumbs up» на сервер. Но базовая проводка кнопки -> thumbs up остается прежней. Компонент React не знает об оптимистических c обновлениях и просто отображает свои реквизиты. Так что это не дублирование логики c само по себе, вы просто добавляете больше логики c для улучшения UX, что является законным.

  2. Откат / обработка ошибок: метод А и В могут быть объединены. Вы бы отправили запрос API для больших пальцев, подождать, пока он завершится успешно или не получится, и, наконец, отправить запрос GET, который выбирает тот же ресурс, который вы пытались изменить на сервере (поскольку он является источником правды). Это откатит обновление Optimisti c, если операция записи не удалась. Или он просто ничего не делает, если ему это удалось, но гарантирует, что у вас есть обновленный ресурс в вашем магазине.

Однако я бы предположил, что 80% React / Redux приложения не выполняют оптимистические c обновления, поскольку большинство разработчиков тестируют быстрые соединения inte rnet и просто не знают о плохом UX при медленных соединениях. Но это правильно.

...