Я создал простое веб-приложение для школы

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

Фон

Для курса разработки программного обеспечения, который я прохожу в школе Flatiron, нам было поручено создать одностраничное веб-приложение, которое будет использовать API и обеспечивать некоторую степень интерактивности пользователя. Мои инструкторы предоставили список общедоступных API GitHub, и, просматривая его, я увидел, что у Best Buy есть общедоступный API. Я подписался на него и немного повозился с ним, и подумал, что было бы неплохо создать небольшое приложение, которое показывало бы, какие карты серии RTX 3000 есть в наличии. Если вы увлекаетесь компьютерными играми, вы, вероятно, знаете, как сложно их найти прямо сейчас.

Когда я начал создавать приложение, я понял, что мой ключ API будет виден на GitHub и всем, кто проверит исходный код страницы. Это казалось далеко не идеальным, учитывая условия использования, с которыми я согласился, когда регистрировался в учетной записи разработчика Best Buy. Беглый взгляд на Google показал, что это не так уж сложно скрыть с помощью определенных фреймворков, но нам не разрешили использовать их для нашего проекта. Пообщавшись с несколькими студентами, мы пришли к выводу, что лучше всего будет выбрать проект, в котором вообще не используется аутентификация. Поэтому я вернулся к общедоступному списку API и попытался просто отсортировать API, которые не прошли аутентификацию. Список этого не поддерживает. Но я заметил в верхней части файла readme, что список доступен через общедоступный API без аутентификации. Итак, для своего проекта я решил просто сделать веб-приложение, которое позволяло бы вам сортировать или фильтровать его.

Создание приложения

По предложению моего инструктора я начал работу над проектом со схемы, в которой список функций был разделен на «MVP» (минимально жизнеспособный продукт) и «расширяемые» функции, которые должны быть разработаны после достижения MVP и завершения проекта, который можно представить. Для GitHub Public API List Filterer MVP просто отображал список API и имел возможность сортировать по каждому типу аутентификации.

Для API, задокументированных в списке GitHub, существует 4 типа аутентификации: ключ API, OAuth, X-Mashape-Key и пользовательский агент (без аутентификации, конечно). Есть четыре записи для X-Mashape-Key и одна для User Agent, поэтому я решил просто объединить их в категории «Другое». В результате у меня осталось 5 кнопок фильтра: «Все», «Ключ API», «OAuth» и «Другое». API позволяет вам запрашивать API по типу аутентификации, но, насколько я могу судить, только по одному за раз. Мне очень не хотелось иметь кнопку, которая возвращает 4 совпадения, и еще одну кнопку, которая возвращает только одно. Мне также показалось неправильным делать запрос одного типа, добавлять его, затем запрашивать другой и добавлять его одним нажатием кнопки. По этой причине, а также потому, что я думал, что API немного медленный, я решил просто взять весь список один раз, когда веб-сайт впервые загружается, а затем выполнить фильтрацию самостоятельно.

Итак, под капотом приложение извлекает весь список API и добавляет их в массив. Чтобы показать фильтр «Все», я просто беру каждую запись в этом массиве, превращаю ее в элемент строки таблицы и добавляю эту строку таблицы в таблицу, ожидающую ее в DOM. Когда вы выбираете фильтр, полный массив затем фильтруется вашим выбором в «рабочий» массив (так что я могу сохранить весь список, не извлекая его снова), и процесс добавления его в DOM такой же, только вместо этого с помощью рабочего массива.

Фильтр «Все» был очень простым. Просто добавьте полный список в DOM. Ключ API и OAuth требовали простой проверки пары ключ:значение, а затем возвращали только соответствующие API, а затем добавляли их в DOM. Для кнопки «Другое» мне пришлось проверить, была ли авторизация X-Mashape-Key ИЛИ User-Agent. Страшный! Фильтровать список оказалось очень просто. Но я заметил, что мой сайт работал очень медленно и не отвечал при переходе между фильтрами.

Устранение неполадок

Сначала я подумал, что проблема заключается в фильтрации массива из примерно 750 объектов. Я добавил несколько журналов консоли на каждый шаг фильтрации, чтобы быть уверенным, откуда идет задержка. Оказалось, что проблема заключалась в добавлении ~750 или ~350 строк таблицы в DOM за один раз. Пагинация (то, чего не предлагал API) была в моем списке сложных целей, но она была в конце списка, после поиска по имени и словам в описании, фильтрации по категориям API (животные, финансы, покупки и т. д.). ) и фильтрация с помощью API, использующих HTTP или HTTPS. Однако блокировка браузера настолько сильно, что вы все еще застреваете с курсором указателя после нажатия кнопки, была для меня совершенно неприемлемой. Несмотря на то, что сайт технически работал и соответствовал MVP, я был им недоволен. Закончив с CSS, я решил немедленно реализовать пагинацию.

Разбивка на страницы вращается вокруг этого кода:

.slice((номер страницы-1)*20, номер страницы*20)

Мне потребовалась минута, чтобы вычислить математику для этого (это никогда не было моей сильной стороной), но как только я это сделал, мне было довольно легко закончить эту функцию. Теперь вместо простого добавления рабочего массива приложение берет первые 20 записей и добавляет их в «выгружаемый» массив. Затем приложение добавляет эти 20 строк в DOM. Это намного быстрее. Когда вы нажимаете кнопку «Следующая страница», он вызывает метод .slice для рабочего массива, получает следующие 20 API в списке и добавляет их. Кнопка «Назад» уменьшает переменную pageNumber и получает предыдущие 20 записей. Конечно, приложение проверяет, не пытаетесь ли вы вернуть отрицательные значения при возврате назад, и останавливает разбиение на страницы в конце при переходе вперед.

Движение вперед

Очевидно, есть еще улучшения, которые можно сделать. Например, панель поиска кажется довольно хорошей идеей. На самом деле у меня есть один в разработке, но я не закончил его вовремя, чтобы представить его для проекта. Есть также некоторые улучшения стиля, которые я хотел бы внести, особенно для стола. Безусловно, этому проекту есть куда расти. Я с нетерпением жду возможности доработать его в будущем.