Как исключить дребезг живого поиска?

Question

[Игорь]

Коллеги, как исключить дребезг живого поиска?


Вот некоторые детали

events()
{
    this.$root.$on("on-root-main-search-change", async ({e, value, f}) => {
        let response = await Digest.fastSearch({
            q: value
        })

        f(response.items)
    })
}

Понятное дело, что если использовать кнопку поиска, то по нажатию инициализировался бы и поиск.

Как снизиться частоту обращений на сервер?
Вот например, пользователь яростно колотит по кнопкам и при каждом движении происходит запрос.

На гифке видно, что я имею в виду.
Не приятное зрелище.

Спасибо!

Comments

[Игорь]

Посмотрел, как у Google это происходит, у него так же часто уходят запросы.

[Decadal]

ставьте таймер на последнее событие нажатия клавиши. Чтобы запрос отправлялся спустя 1-2 секунды после окончания ввода.

[Игорь]

Decadal, А разве выполнение не будет складываться в стек вызовов ?
А после выполняться по очереди...

[Interface]

Decadal, не поможет. Будет та же картина только с задержкой в 1-2 секунды. Тут нужен debounce или throttle

Answer 1

[lloydbanks]

debounce

Answer 2

[xmoonlight]

1. Timeout (в 1 сек) по событиям от UI или более 3-х символов (или символ "пробела") => запрос на сервер.
2. Использовать локальный кэш запросов и ответов.

Answer 3

[Interface]

Тут стоит использовать throttle или debounce
https://lodash.com/docs/#throttle
https://lodash.com/docs/#debounce

Когда-то давно я писал маленькую библиотеку, которая как раз решает задачу с поиском. Я не то чтобы предлагаю ее использовать (хотя я был бы только рад :) ), но зато там есть демо, где иллюстрируется работа throttle: https://int0h.github.io/promise-decorators/
Сама библиотека: https://github.com/int0h/promise-decorators
Пример с поиском: https://github.com/int0h/promise-decorators/blob/g... (живьем есть на демо странице)

Еще хорошая иллюстрация есть в rxmarbles: https://rxmarbles.com/#debounce
(можно это же решать rx'ом)

Comments

[Stalker_RED]

Очень круто, но совсем непонятно зачем.
Обычно debounce укладывается строк в 10 )

[Interface]

Stalker_RED, нуу в 10 строк укладывается самая простая реализация (которая, впрочем, подойдет в ряде случаев). https://github.com/lodash/lodash/blob/master/debou... ребята из lodash немного вышли за пределы 10 строк :) и последний раз когда я это вдумчиво читал, я не нашел там что-то, что можно выкинуть.

Насчет моей библиотеки: для решения проблемы в посте не совсем достаточно одного debounce. Он резко улучшит ситуацию, но исправит не все проблемы. Есть 2 потока событий: keydown и получение результата с сервера.

Обычно запросы исполняются относительно быстро, но чтобы избежать лишней нагрузки на сервер (или не упереться в лимит стороннего сервиса) запрос отсылают не на каждый keydown, а не ранее чем через N мили-секунд после последнего (debounce).

Однако, это значит, что пользователь не увидит никакого промежуточного результата. Это может быть неудобно. Например, в базе есть товар "Постельное белье розовое с цветочками", и пользователь вбивает прямо ровно эту строку, в таком случае мы могли бы уже на фразе "Постельное бель" вывести ему подсказку и он не стал бы дописывать, а "табнул" бы. Особенно это полезно в случае когда в базе ничего больше "постельного". Поэтому может быть удобно использовать throttle, а не debounce.

Но можно нарваться на интересную проблему: Порядок отправки запросов и получения ответов может отличаться! То есть: клиент отправит запросы A, B, C, а ответы придут в порядке A, C, B. И если их обработка написана в лоб - то в результате пользователь может увидеть неактуальный ответ B, хотя последнее что но ввел - это C.

Более того, по схожим причинам, ответы могут не только перемешаться, но и придти все разом одной большой пачкой. (Это актуально и для debounce, только время ответа должно быть больше паузы и пользователь должен успеть отправить второй запрос до исполнения первого). А это уже черевато все тем же "дребезгом". Например, пользователь может вбивать текст в течении 10 секунд, а затем ему разом (с произвольной разницей, например, в 50 мс) вернется ответ на его 5 запросов, в итоге интерфейс моргнет 5 раз за четверть секунды - "дребезг".

Это значит, что и обработку запроса, надо throttl'ить.

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

На демо-странице можно выставить в последней секции задержку в Fetch time: 500 ± 3000 ms, тогда некоторые запросы будут выполняться дольше, чем более свежие.

...так вот библиотеку я и писал для этих целей :)

- throttle - привычный throttle
- takeLast - брать в учет только актуальный запрос
- watchPromise - по пути добавил простую поддержку лоадеров

Ну и плюс она предоставляет несколько другой АПИ. В случае с обычным debounce, вся функция получается не совсем ассинхронной - она исполнятся синхронно, просто в ряде случаев ничего не делает. В то время как "мой" throttle возвращает функцию которая, возвращает "честный" Promise, который будет разрезолвен, когда будет получен актуальный ответ. Это позволяет выстраивать цепочки .then(...).then и async/await.

P.s. Вроде бы смысл был в этом :) Писалось 2 года назад, сейчас могу уже что-то путать. :)

Answer 4

[Игорь]

Всем, спасибо, действительно помогло.

Когда перестаёшь тапать, запрос отправляется.

events()
    {

        let search = debounce(async ({e, value, f}) => {
            let response = await Digest.fastSearch({
                q: value
            })
            f(response.items)
        }, 1000)

        this.$root.$on("on-root-main-search-change", async ({e, value, f}) => {
            search({e, value, f})
        })
    }