Из всех проектов, которые я создал за время учебы во Flatiron School, этот я ждал меньше всего. Наша задача состояла в том, чтобы создать веб-приложение с внешним интерфейсом Javascript и внутренним интерфейсом API Rails и минимум двумя моделями с отношением exists_to и has_many.

Я чувствовал себя очень уверенно в своих знаниях о рельсах и рано решил, что хочу иметь четыре модели в своем проекте. Я начал создавать свой рельсовый бэкенд Trip Planner, используя следующие модели: «Поездка», «Категория», «Предмет» и «Категория поездки». Последняя модель была необходима для создания таблицы соединений между Trip и Category, поскольку каждая из них «имеет_много» другой. Ко второму дню моего проекта я серьезно задавался вопросом, почему, черт возьми, я считаю создание четырех моделей хорошей идеей. Тем не менее, я продолжал.

Первое, что я хотел показать в своем веб-приложении, — это список всех поездок, которые были созданы, с соответствующими категориями, перечисленными под ними. Для этого потребовался fetch вызов моего API Rails по адресу localhost:3000/trips. Я решил создать сервисный класс, который будет обрабатывать все мои вызовы выборки, делая их асинхронными. Моя первая выборка выглядела так:

Поскольку этот проект требовал от нас использования объектной ориентации, я знал, что мне понадобится Trip class, чтобы иметь возможность обрабатывать все мои объекты поездки и то, как я могу отображать их на странице. Для этой первой функции, чтобы отображать мои поездки в DOM, я создал функцию renderTrip() в своем файле Trip.js.

Чтобы собрать все это воедино, я создал функцию в своем index.js, которая будет вызывать как выборку, так и функции рендеринга.

Эта единственная асинхронная функция вызывается, когда страница впервые загружается с помощью моей функции bindEventListeners. Он эффективно вызывает экземпляр моего ApiService class (который я создаю в самом верху страницы, а не изображения) и использует метод экземпляра fetchTrips() для получения всех данных, связанных с поездкой. Когда у меня есть данные, я перебираю каждый объект поездки, создавая новый экземпляр моего Trip Class, а затем использую мой метод renderTrip для отображения каждого из них на странице.

Мой проект начал выглядеть как настоящее веб-приложение! Как только я понял, как эффективно использовать свой Api Service class, получение необходимых мне данных не стало для меня слишком сложной задачей. Самой сложной частью этого проекта для меня было манипулирование DOM таким образом, чтобы я мог хранить все необходимые идентификаторы объектов в местах, где я мог получить к ним доступ, чтобы в конечном итоге создать новый объект. Например: чтобы создать новый экземпляр моего Item class, каждый элемент должен знать как экземпляр поездки (trip_id), так и экземпляр категории (category_id), к которому он принадлежит. Для этого мне пришлось незаметно вставить эту информацию в документ и форму, в которой создается экземпляр элемента.

В моей функции createNewItem() мне понадобилась информация trip_id и category_id для создания моего configObj, который будет отправлен на мой сервер для создания нового экземпляра Item. Мне удалось получить trip_id из элемента <div>, который я создал на странице с идентификатором этой конкретной поездки.

И у меня был доступ к category_id элемента из набора данных формы, который я вставил в форму элемента при создании формы:

Чтобы создать сам экземпляр элемента, мне просто нужно было собрать все вместе:

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

Первоначально опубликовано на https://dev.to 7 января 2021 г.