Redux (с React) - отправка действия REQUEST, которое устанавливает загрузку и т. Д., Вызывает дополнительный рендер

Question

Довольно простой вопрос.(Я старый разработчик, создающий приложение React, которое требует высокой производительности и унаследовало старое хранилище).

Большинство приложений, которые я вижу, при отправке запроса API сначала отправляют 1) ЗАПРОС, затем либо 2) УСПЕХ, либоFAILURE

Дело в том, что когда вы отправляете запрос, он изменяет состояние и вызывает повторное рендеринг всех подключенных компонентов.

Я обнаружил это, когда пытался выяснить, почему мои тесты на кукловодов такие ненадежные.(Использование пользовательского интерфейса материала с рендерингом анимации / выпусками, готовыми к действию и т. Д.)

Итак,

Почему в Redux обычно / хорошей практикой является использование действия REQUEST, которое изменяет состояние?(например, очищает его, устанавливает загрузку: true, метка времени и т. д.) и т. д. Если да, то почему это действие REQUEST?Почему бы не пропустить действие REQUEST и просто обновить SUCCESS / FAILURE, чтобы предотвратить повторный рендеринг?

Или отправить REQUEST с неизменяющим редуктором?

Очевидно, есть варианты использования дляочистить состояние в REQUEST, но при получении чего-то похожего на страницу категории, обновить состояние в REQUEST?

Что-то мне не хватает?

Спасибо

Answer 1

Почему в Redux обычно / хорошей практикой является использование действия REQUEST, которое изменяет состояние?(например, очищает его, устанавливает загрузку: true, метка времени и т. д.) и т. д. Если да, то почему это действие REQUEST?Почему бы не пропустить действие REQUEST и просто обновить SUCCESS / FAILURE, чтобы предотвратить повторный рендеринг?

Один пример: представьте, что у вас есть компонент, которому требуются данные, которые необходимо получить из API.На веб-интерфейсе вы хотели бы иметь индикатор загрузки бар.Вы сможете отобразить эту полосу загрузки только в том случае, если знаете, что запросили вызов.

Представьте, что мы делаем это без индикатора ЗАПРОС / ЗАГРУЗКА: если пользователь уже был на этой странице с компонентом, вызывающим запроси приходит снова, состояние (СБОЙ / УСПЕХ) уже было бы установлено.Это означает, что если предыдущее состояние было «FAILURE», и вы рендерили свой компонент в зависимости от этого состояния, то сначала будет отображаться ваш «FAILURE» рендеринг.И затем, это может быть обновлено с вашим рендером УСПЕХА.Для пользователя это приведет к переключению с сообщения об ошибке / страницы на страницу результатов или наоборот, что действительно является плохим UX.