Какова грубая архитектура функции фаворита / звезды в Gmail?

Question

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

Backend : экземпляр AWS ELB EC2 сNodeJS, Restify, другие разные библиотеки, подключенные к DynamoDB.

Front-end : Реагируйте с Redux.

Я пытаюсь создать функцию, которая архивирует определенные фрагментыданных о нашем React-based Front-end.На практике это очень похоже на «пометку» или «добавление в избранное» сообщения или электронной почты, как в Gmail или <--- прямо там, со StackOverflow. </p>

Мне это кажется очень простымпроблема на поверхности.Но по мере того, как я углубляюсь в это, он становится все более сложным.

Основная проблема связана с одним фактом: если я нажимаю на значок «звездочка», он должен сгенерировать запрос и изменить свое изображение.Однако в большинстве случаев я бы подождал ответа, прежде чем менять соответствующее значение на внешнем интерфейсе, чтобы предотвратить конфликты.Проблема в том, что наши запросы слишком длинны для этого.Gmail и SO показывают переход между помеченными и не помеченными звездами мгновенно, и я чувствую, что пользователи не были бы рады, если бы это было что-то, кроме как для этой функции.не обращая внимания на ответы на запросы, которые он генерирует, я очень быстро сталкиваюсь с проблемами гонки и конфликтов.Особенно, если учесть, что мы хотим иметь возможность «Выбрать все» и пометить звездочкой (архив) на таблице длиной более 200 записей.

Так, каков здесь ответ?Честно говоря, я в растерянности.

Answer 1

Я думаю, что концепция, которая может быть полезна здесь, это «оптимистичный интерфейс».Это шаблон, обычно используемый для того, что вы описываете, чтобы поддерживать тесную обратную связь с пользователем, указывая ему, что его действие что-то сделало, предполагая положительный результат, когда что-то (например, HTTP-запрос) выполняется асинхронно, и если естьЭто ошибки, вы можете вернуть положительное состояние и предупредить пользователя о проблеме.

На практике в React, если вы используете что-то вроде Redux, вы можете создать какое-то «архивное» действие, которое устанавливает состояниедля каждого выбранного элемента как «заархивированного» в редукторе, и в то же время отбросить запрос к бэкэнду на обновление сервера в заархивированном состоянии.Предполагая, что вы используете async/await для создания запроса к серверу, вы можете заключить его в try/catch, где catch обнаружит неудавшийся запрос и вернет «архивированное» состояние выбранных элементов в редукторе и, возможно, отобразит ошибкусообщение пользователю.

Answer 2

Как уже упоминалось в комментариях, я думаю, что лучший подход - это "надеяться на лучшее".

Пользователь ожидает, что при нажатии кнопки со звездочкой проблем не возникнет, поэтому он делает что-то кроме освещениядо звезды будет тревожным для пользователя.Конечно, вам нужно проверить звезду на вашем бэкэнде, но в то же время вы будете предполагать, что она будет успешной, и зажечь звезду.

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

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