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

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

Так как всего происходит довольно много, мы сосредоточимся на основной части — логике JavaScript. Начнем.

Первое, что мы собираемся рассмотреть, это то, как извлекаются статьи. Для целей этого руководства я построил маршрут API, который возвращает все опубликованные статьи. Я не буду вдаваться в подробности того, как устроен API или как его создать. В сети довольно много руководств, объясняющих это. Мы сосредоточились здесь на том, что у нас есть маршрут, который выдает некоторые результаты, которые выглядят примерно так, как на изображении ниже.

Как только у нас есть рабочий маршрут API, связанный с желаемыми результатами, мы должны передать эти данные клиенту и сделать их доступными, когда он/она начнет печатать. Этого можно добиться синхронно, загрузив данные во время загрузки страницы, или загрузив их асинхронно, когда клиент инициирует определенное событие. Первый подход довольно прост и в нем нет ничего сложного, и в небольшом проекте он может работать без нареканий, если данных, которые мы загружаем из API, достаточно мало. Если нам придется синхронно извлекать много данных, это непреднамеренно замедлит загрузку страницы для клиента и заставит приложение выглядеть медленным. Другой подход заключается в использовании асинхронных запросов и извлечении данных в фоновом режиме. В этом сценарии клиент, вероятно, не заметит, что эта информация извлекается с сервера на лету.

Фрагмент кода ниже использует асинхронный/ожидающий синтаксис JavaScript вместе с интерфейсом Fetch API для асинхронной загрузки данных с указанного URL-адреса. Я не буду описывать все детали async/await, но могу указать на хороший ресурс, который показался мне очень полезным.

В двух предложениях, что происходит? Что ж, мы определяем URL-адрес нашего маршрута API и передаем этот URL-адрес нашей асинхронной функции. В нашем случае мы используем fetch для получения результата, который, если мы напечатаем в консоли браузера, увидит, что это фактический ответ сервера и, в конечном итоге, сами данные (notice the await postResponse.json() call).

Как только мы получим необходимые данные, мы можем перейти к следующему шагу, а именно к отображению данных клиенту. Эта часть нашей функции выглядит так.

Давайте погрузимся и разберемся, что происходит. Первое, на что следует обратить внимание, это то, что у нас есть событие клика jQuery, которое запускает загрузку данных для клиента. Это означает, что когда пользователь нажимает на элемент с идентификатором #search-bar, срабатывает событие, и мы собираемся передать данные в браузер клиента. Поскольку мы создаем живой поиск, мы хотим, чтобы по каждому письму, набранному клиентом, данные были отфильтрованы соответствующим образом. В библиотеке jQuery есть удобная функция keyup, которая запускается событием, когда пользователь отпускает нажатую клавишу. Следующее, что нужно сделать, это сравнить, входят ли введенные пользователем символы в заголовок поста. Если это действительно так, мы возвращаемся из функции фильтра и отображаем результаты в консоли.

Представьте, что пользователь вводит javascript в строку поиска. Результаты, которые вернет приложение, следующие.

Если пользователь продолжает печатать, например, учебник, пользователю будет возвращен только один результат.

Вот как рана пользователя увидит приведенные выше результаты.

В этой статье я представил быстрый и простой способ создания функции живого поиска на JavaScript с помощью нескольких функций. Как я сказал в начале — это не самый практичный способ создания такой фичи, но это начало. Есть довольно много вещей, которые вы должны учитывать, если хотите улучшить этот код. Прежде всего, проверьте, соответствует ли ответ сервера 200, и получаете ли вы вообще какие-либо данные. Вторая и более важная вещь, которую следует учитывать, — это то, как вы сравниваете пользовательский ввод с данными, которые у вас есть. В настоящее время функция использует JavaScript includes(), который проверяет, включен ли пользовательский ввод в заголовок сообщения не как отдельные слова, а как целое предложение. Возьмем, к примеру, статью Python vs Javascript из результатов. Если пользователь наберет python javascript в строке поиска, он/она получит нулевые результаты, потому что такая строка не включена в наши примеры статей. Что, вероятно, должно было произойти, так это то, что каждая работа должна быть обработана отдельно, а статьи, содержащие эти слова, должны отображаться в качестве результатов. Это широкая тема для обсуждения в небольшой статье, подобной этой.

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

Удачных поисков!