От автора: в течение очень долгого времени я хотел рассмотреть различные способы вызова Vue API. В этой статье я расскажу о шаблоне, который лучше всего подходит для меня, поэтому позвольте мне познакомить вас с RepositoryFactory.
Мне нравится этот подход, потому что он хорошо масштабируется и, по крайней мере, для меня, он работал почти всегда. Позвольте мне объяснить, почему.
С одной стороны, мы будем использовать шаблон репозитория для доступа к ресурсам обособленно, без какой-либо логики, кроме возврата данных.
А с другой стороны, мы будем использовать шаблон фабрики для создания экземпляра или репозитория, которые нам нужны в каждом случае, а также логику среды. Это дает нам то преимущество, что фабрика может решить, следует ли создавать экземпляр виртуального репозитория или производственного, если это необходимо.
Сколько раз вы видели примеры с экземпляром axios в каждом компоненте? Каждый раз, когда я вижу это, меня одолевают те же вопросы:
Что произойдет, если вам нужно повторно использовать вызов?
Что произойдет, если конечная точка изменится?
Что произойдет, если я хочу повторно использовать вызовы API для другого проекта?
Что произойдет, если вам нужно реорганизовать какой-либо вызов или перенести его в действия Vuex?
У меня есть несколько ресурсов, теперь нужно определять 4 разных конечных точки?
Как я могу обрабатывать макеты или разные конечные точки, чтобы проверить это?
Правильный способ
В этом случае мы собираемся использовать обычные объекты JavaScript (POJO), чтобы они были простыми и определяли разные ресурсы (конечно, вы можете использовать класс, если хотите). Давайте начнем с определения конфигурации axios. Мы назвали этот файл Repository.js, потому что он отвечает за соединение с ресурсом.
Есть также люди, которые используют термин служба или непосредственно API, но мне кажется, что репозиторий — это то, что лучше всего описывает его функцию.
Затем нам нужно будет объявить ресурс для каждого объекта вашего проекта. Для этого примера предположим, что у вас есть блог. Таким образом, у вас есть посты, поэтому вы можете определить все операции CRUD в своем файле репозитория.
Вот как выглядит postsRepository:
А теперь наипростейшая фабрика в мире…
Как вы можете видеть, это простой объект, который возвращает запрошенный ресурс. На данный момент вы заметили, что мы можем обрабатывать более одной среды и импортировать даже виртуальные репозитории, добавляя другую логику к вашему методу get().
Например, в моей текущей компании Snap.hr нам нужны разные среды и в зависимости от среды мы переходим на mocks или соответствующую конечную точку. Под этим я имею в виду, что все может быть настолько сложно, насколько вам нужно. Но для этого примера давайте упростим все.
Теперь я покажу, как использовать это в вашем .vue sfc:
Поскольку у нас есть полностью отделенная логика, вы даже можете использовать другую конечную точку с другой парадигмой, например, GraphQL.
Заключение
Как всегда, серебряной пули не существует. Эта модель подходила мне практически во всех моих проектах, но это не значит, что она лучше всего подходит для ваших проектов. Однако, я думаю, у нее есть некоторые преимущества, такие как:
Этот шаблон позволяет выполнять тестируемый код очень простым способом.
Ваши компоненты выглядят чище.
Он легко расширяемый, не так ли?
Сохраняет код DRY.
Я создал рабочую демо-версию на Codesandbox, чтобы продемонстрировать этот подход в действии, и мне бы хотелось услышать, используете ли вы уже эту технику!
Автор: Jorge Nieto
Источник: https://blog.snap.hr/
Редакция: Команда webformyself.