Управление запросом Async Batch внутри действия redux

У меня есть действие redux для поиска в приложении. Когда пользователь начинает поиск, он группирует запросы и отправляет 30 запросов на запрос и ставит в очередь первые 10 запросов. Как только любой из запросов будет успешным, он добавит следующий запрос в очередь запросов. Все это происходит как действие redux, и всякий раз, когда запрос оказывается успешным, он отправляет действие для добавления результата в хранилище. Я хотел бы получить информацию о том, как с этим справиться, если пользователь нажимает «отменить поиск» и вводит новый поисковый запрос. Как я могу отменить существующие действия запроса и сокращения, чтобы предыдущие запросы поиска не были успешными, и добавить их в хранилище результатов?

Пример кода ниже: -

function search(queries){
  // split the queries into chunks of size 30
  batches = _.chunks(queries, 30);

  let count = 0;

  //get the first batch manually
  getBatch(batches[0]);

  function getBatch(batch){
    axios.post('url', batch.join(',')).then((response) => {

      // recursively call get batch to get rest of the data
      if (count < batches.length) { getBatch(batches[count++]); }

      // dispatch action to append the result into the store
      dispatch({ type: 'APPEND_RESULT', payload: response })
    }
  }
}

this is a minimal code for sharing the concept

Я читал об отменяемых обещаниях, которые поддерживает Axios. Но я не уверен, как контролировать этот рекурсивный вызов при втором выполнении той же функции.

eg: user input will be { ids :[1,2,3,..1000] } I am trying to create batches and sent parallel requests { ids:[1,2, .. 29,30 }, { ids: [31, 32, .. 59,60]} etc.

Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
Улучшение производительности загрузки с помощью Google Tag Manager и атрибута Defer
В настоящее время производительность загрузки веб-сайта имеет решающее значение не только для удобства пользователей, но и для ранжирования в...
Безумие обратных вызовов в javascript [JS]
Безумие обратных вызовов в javascript [JS]
Здравствуйте! Юный падаван 🚀. Присоединяйся ко мне, чтобы разобраться в одной из самых запутанных концепций, когда вы начинаете изучать мир...
Система управления парковками с использованием HTML, CSS и JavaScript
Система управления парковками с использованием HTML, CSS и JavaScript
Веб-сайт по управлению парковками был создан с использованием HTML, CSS и JavaScript. Это простой сайт, ничего вычурного. Основная цель -...
JavaScript Вопросы с множественным выбором и ответы
JavaScript Вопросы с множественным выбором и ответы
Если вы ищете платформу, которая предоставляет вам бесплатный тест JavaScript MCQ (Multiple Choice Questions With Answers) для оценки ваших знаний,...
0
0
887
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ полный ИМХО

На мой взгляд, здесь нарушен весь способ решения проблемы. Вы откажетесь от своего сервера, постоянно запрашивая у него любое изменение ввода. Только представьте, сколько трафика будет потреблять ваш сайт для мобильных устройств!

Лучшее решение здесь:

  1. Добавьте _.debounce к вашему вводу с небольшим временем ожидания (100 мс - это хорошо)
  2. Есть только один запрос в памяти. При каждом новом событии от user вводите отменить запрос и отменяйте текущее.
  3. Отправлять действие с данными о каждом ответе сервера

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

Sreevisakh 18.06.2018 08:57

например: пользовательский ввод будет {ids: [1,2,3, .. 1000]} Я создаю пакеты и отправляю параллельные запросы {ids: [1,2, .. 29,30}, {ids: [31, 32 , .. 59,60]} и т. д.

Sreevisakh 18.06.2018 09:00
Ответ принят как подходящий

Это похоже на кандидата на наблюдаемая редукция. Вы можете создать наблюдаемый, а затем добавить debounce (как указано в одном комментарии выше), и вы можете легко отменить или переключить карту на новый запрос всякий раз, когда текущий запрос будет завершен, так что любые оставшиеся элементы в предыдущей очереди не будут учитываться.

Другие вопросы по теме