Как бороться с race condition при обращении к REST API во Vue?

Question

[Артур Галяев]

Под race condition я подразумеваю такое состояние, когда пользователю отобразилось не то, что он хотел из-за отработки предыдущего запроса, наглядный пример:
https://sebastienlorber.com/handling-api-request-r... в разделе Adding network delays + failures
Возможное решение автора сохранять предыдущий запрос:

// A ref to store the last issued pending request
const lastPromise = useRef();
useEffect(() => {
  setData(null);
  // fire the api request
  const currentPromise = fetchStarwarsHeroData(id).then(
    async data => {
      await delayRandomly();
      throwRandomly();
      return data;
    },
  );
  // store the promise to the ref
  lastPromise.current = currentPromise;
  // handle the result with filtering
  currentPromise.then(
    result => {
      if (currentPromise === lastPromise.current) {
        setData(result);
      }
    },
    e => {
      if (currentPromise === lastPromise.current) {
        console.warn('fetch failure', e);
      }
    },
  );
}, [id]);

В react есть thunk, saga, а как правильнее сделать это во Vue?

Еще пример: гифка

Answer 1

[Aetae]

Просто не давть пользователю повторно тыкать там, где это вызовет повторный запрос, пока идёт загрузка текущего?

Но если хочется быть ленивым - можно просто обернуть запросы в leading debounce-promise.

Все эти thunk и saga - полная ересь, порождённая богомерзким redux.

Comments

[Артур Галяев]

Я имею ввиду не повторные запросы. Проблема как на этой гифке: gif статья
Не хочется блокировать пользователю интерфейс из-за запроса (вдруг он ошибся и теперь ему нужно ждать пока отработает запрос, перерендерится компонент и т.д.).

[Константин Б.]

Артур Галяев, можно делать отмену запроса при инициализации нового.

[Артур Галяев]

Константин Б., ну по сути можно или отменить предыдущие запросы или игнорировать их. Только как это лучше сделать?

[Константин Б.]

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

[Константин Б.]

Артур Галяев, посмотрите как реализуются какие-нибудь autocomplete компоненты. Хоть там в большинстве случаев debaunce, но в нормальных решения используется отмена

[Aetae]

Артур Галяев, если не хочешь блокировать кнопку - блокируй отображение пока идёт загрузка.:) Остальное решит debounce-promise: да будет несколько раз вызвано обновление, но эти несколько обновлений все будут содержать последние данные, т.е. просто дублироваться. Да, немного расточительно, но оверхед пренебрежительно мал, по сравниванию с иными вариантами горожения огорода, типа той же саги.

[Артур Галяев]

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

[Артур Галяев]

Aetae, понял, да, вариант debounce-promise довольно хороший)

[Константин Б.]

Артур Галяев, debounce хорошее решение, он нужен, но он не золотой ключик и не спасет от состояния гонки

[Константин Б.]

Артур Галяев, я описал смысл, как именно сделать уже ваша кухня))

[Константин Б.]

Предположим у вас debounce 300 мс, запрос еще 300 в хорошем случае. Нажали кнопку и сеть мигнула или еще какая-то задержка удвоила время запроса в двое и вот через 300 мс отправится второй запрос, а первого еще нет

[Aetae]

Константин Б., debounce-promise немного по-другом работает, он учитывает время самого промиса, и его можно для данных целей использовать вообще с нулевой задержкой.

Answer 2

[VegasChickiChicki]

Артур Галяев На самом деле то что у вас на скриншоте я решил у себя на проекте более практично - AbortController. Мы просто записываем текущий запрос в переменную, если пользователь сделал действие, которое создает еще запрос на тот же адрес, то мы отменяем предыдущий запрос и создаем новый, помещая его снова в переменную и так до тех пор пока пользователь не перестанет тыкать.

Так же можно комбинировать и добавить debounce + блокировку контента, ко посоветовали выше.

Answer 3

[impruvd]

Очевидно, гифка с кнопками - переупрощённый пример. Более-менее реальный для поднятой проблемы - построение динамической формы по её типу. Условно - есть дропдаун, в нём какие-то значения (тип формы), на изменение выбранного значения идёт fetch на сервер за набором полей, которые нужны для построения формы. Шапка формы вполне может билдиться из информации, полученной не от сервера в ответ на запрос полей, а из информации, известной заранее, при построении дропдауна с выбором типа формы, это нормально.
И в таком варианте, разумеется, надо блокировать контрол, ответственный за вызов бэкенда, а на контент по желанию вешать блюр, прелоадер, оверлей полупрозрачный, что угодно, чтобы пользователь понимал, что сейчас форма недоступна для взаимодействия, тыкать не надо (да и лишние запросы на бэкенд ходить не будут).

Answer 4

[Владимир Коротенко]

Как уже сказали блокировать кнопку.

Как пели давно "нажми на кнопку получишь результат" в вашем случае "нелязя нажать на кнопку"

Comments

[Артур Галяев]

Я имею ввиду не повторные запросы. Проблема как на этой гифке: gif статья
Не хочется блокировать пользователю интерфейс из-за запроса (вдруг он ошибся, и теперь ему нужно ждать пока отработает запрос, перерендерится компонент и т.д.).

[Артур Галяев]

гифка

статья

[Rsa97]

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