Как организовать ваши зависимости во Vue-приложении
Для чего писать это самим?
Многие могут подумать – зачем это нужно, если есть, например, Nuxt, который это сделает за вас? В своих проектах я использовал его тоже, однако в простых проектах это может оказаться избыточным. Кроме того, никто не отменял проекты с legacy-кодом, которые падают на вас, как снег на голову. И подключать туда фреймворк – практически делать его с нуля.
Идейный вдохновитель
Вдохновителем такой организации явился Nuxt. Он был использован мной на крупном проекте с Vue.
У Nuxt есть прекрасная фича – plugins. Каждый плагин – это файл, который экспортирует функцию. В функцию передается конфиг, который также будет передан конструктору Vue при создании экземпляра, а также весь store.
Где это может пригодиться?
Помимо того, что main.js существенно «похудеет», вы также получите возможность использования зависимости в любом месте приложения без лишних импортов.
Яркий пример Dependency Injection – это vue-router. Он используется не так уж и часто – получить параметры текущего роута, сделать редирект, однако это глобальная зависимость. Если он может пригодиться в любом компоненте, то почему бы не сделать его глобальным? К тому же, благодаря этому его состояние тоже будет храниться глобально и меняться для всего приложения.
От слов к коду
Базовая структура проекта
Посмотрим, как сейчас выглядит проект:
src
— store
— App.vue
— main.js
main.js выглядит примерно так:
Подключаем первую зависимость
Результат
На данном этапе мы добились того, что убрали конфигурацию плагина из main.js в отдельный файл.
Если вы любите ES6-style, можете даже сделать так:
Второй этап – Dependency Injection
Мы уже создали первый плагин и сейчас наш проект выглядит так:
Wait Plugin
— start — устанавливает в state свойство объекта с именем action в true
— end — удаляет из state свойство объекта с именем action
— is — получает из state свойство объекта с именем action
В этом плагине мы будем его использовать.
И подключаем наш плагин:
Функция inject
Магия Vue.prototype
Однако на деле оказалось, что это не так. Вследствие гуглинга не нашлось ответа, почему такая конструкция не заработала. Поэтому я решил обратиться к авторам плагина, которые уже это реализовали.
Глобальный mixin
Вместо прототипа предлагается использовать глобальный mixin. Эффект в общем-то тот же, возможно, за исключением каких-то нюансов. Но учитывая, что и в store inject делается здесь же, выглядит не совсем right way и совсем не соответствует описанному в документации.
А если все же prototype?
Идея решения с прототипом, которая используется в коде функции inject была позаимствована у Nuxt. Выглядит она намного более right way, чем глобальный mixin, поэтому я остановился на ней.
Результат
После этих манипуляций мы получаем возможность обратиться к this.$wait из любого компонента, а также любого метода в store.
Что получилось
src
— plugins
— index.js
— axios.js
— wait.js
— store
— App.vue
— main.js
Заключение
При добавлении нового плагина нужно всего лишь создать файл, который экспортирует функцию, импортировать его в index.js и вызвать эту функцию.
В моей практике такая структура показала себя очень удобной, к тому же она легко переносится из проекта в проект. Теперь нет никакой боли, если нужно сделать Dependency Injection или сконфигурировать очередной плагин.
Делитесь своим опытом организации зависимостей в комментариях. Успешных проектов!
10 особенностей создания компонентов Vue.js
1. Глобальная и локальная загрузка компонентов
Vue.js предоставляет два способа загрузки компонентов: глобально на экземпляре Vue и на уровне компонентов. Каждый метод обладает своими преимуществами.
При локальной загрузке можно изолировать компоненты и загружать их только при необходимости. В сочетании с Webpack можно использовать отложенную загрузку компонентов только во время их использования. Это значительно уменьшает исходный размер файла приложения и сокращает время начальной загрузки.
2. Отложенная загрузка / Асинхронные компоненты
Отложенная загрузка компонентов с использованием динамических импортов Webpack. Vue поддерживает отложенную загрузку компонентов во время рендеринга и разделение кода. Благодаря этим оптимизациям код компонента загружается только при необходимости, благодаря чему уменьшается размер HTTP-запроса, размер файла и автоматически повышается производительность. Отличительной особенностью этой функции является возможность работы как с глобально, так и с локально загруженными компонентами.
Глобальная загрузка асинхронных компонентов:
Локальная загрузка асинхронных компонентов:
3. Требуемые Props
Props для компонента можно создать несколькими способами: передача массива строк, представляющих названия prop, или передача объекта с ключами в качестве названий prop и объекта конфигурации.
5. Разделение компонентов на логические составляющие
Как определить логические составляющие, на которые нужно разбить компонент? Первый способ разделения компонента основан на показателе изменения данных. Если данные изменяются последовательно в одном разделе компонента, но не в других, то, вероятно, из этого раздела можно создать отдельный компонент.
Причина заключается в том, что если данные или HTML изменяются последовательно в одном разделе шаблона, то этот раздел необходимо проверить и обновить. Однако, если тот же HTML размещается в собственном компоненте с данными, переданными с использованием props, то только этот компонент будет обновляться при изменении его props.
Другой способ логического разделения компонентов применяется для повторного использования. При наличии HTML, графиков или функций, которые последовательно используются в приложении, можно создать новый компонент для повторного использования.
6. Проверка Props
Вместо использования массива строк для определения props используйте нотацию объекта, с помощью которой можно конфигурировать каждый prop. К полезным стилям конфигурации можно отнести type и validator.
При использовании параметра type Vue автоматически выполняет проверку типов значения prop. Например, при ожидании prop Number, но получении String, в консоли появится следующее предупреждение:
7. Связывание и перезапись нескольких Props
Дополнительным преимуществом использования привязки объекта является возможность перезаписи любой привязки из объекта. В данном случае, если в объекте person для isActive установлено значение false, то можно сделать еще одну привязку к фактическому компоненту person и установить для isActive значение true, не перезаписывая оригинал.
8. Модификация Props в компонентах
Иногда при изменении значения, переданного из prop, может появиться предупреждение “Avoid mutating a prop directly”. Поэтому используйте значение prop в качестве значения по умолчанию для свойства локальных данных. Благодаря этому можно увидеть исходное значение, однако при модификации локальных данных значение prop не изменится.
При использовании этого метода свойство локальных данных не реагирует на значение prop, поэтому любые изменения в значении prop из родительского компонента не обновят локальное значение. В случае необходимости выполнения этих обновлений можно комбинировать значения с помощью вычисляемого свойства.
9. Утилиты тестирования Mount и Shallow Mount
Есть два способа создания и загрузки компонентов в утилитах тестирования Vue: mount и shallow mount. Каждый из них обладает своими преимуществами и недостатками.
Техника mount удобна при проведении взаимозависимого тестирования между компонентом и его подкомпонентами. С ее помощью можно проверить правильность взаимодействия родительского компонента с подкомпонентами. Метод shallow mount создает экземпляр и визуализирует только родительский компонент в полной изоляции, игнорируя подкомпоненты.
Какой метод лучше? Решать вам. Выбранные стратегии зависят от поставленных целей. При необходимости тестирования компонента с полной изоляцией стоит использовать метод shallow. При работе с компонентом, обладающим подкомпонентами, следует использовать метод mount. Также методы можно комбинировать.
10. Мощность Vue-cli
Vue CLI — это мощный интерфейс командной строки, с помощью которого разработчики могут использовать множество функций, ускоряющих рабочий процесс.
Я часто использую функцию, при которой нужно запустить vue serve и передать путь к компоненту Vue. При этом можно разрабатывать компонент изолированно, а также выполнять горячую перезагрузку и итерацию по компоненту. Нет необходимости временно импортировать новый компонент на страницу для разработки.
Регистрация компонентов
Подразумевается, что вы уже изучили и разобрались с разделом Основы компонентов. Если нет — прочитайте его сначала.
Именование компонентов
При регистрации компонента у него всегда будет имя. Например, при глобальной регистрации, которую мы видели до сих пор:
Имя, которое вы даёте компоненту, может зависеть от того, где вы собираетесь его использовать. При использовании компонента непосредственно в DOM (в отличие от строковых шаблонов или однофайловых компонентов), мы настоятельно рекомендуем следовать правилам W3C для именования пользовательских тегов (все символы в нижнем регистре, должен содержать дефис). Это позволит избежать конфликтов с текущими и будущими HTML-элементами.
Вы можете изучить другие рекомендации по именованию компонентов в разделе Рекомендаций.
Стиль именования
У вас есть два способа указания имён компонентов:
В стиле kebab-case
В стиле PascalCase
При определении компонента в стиле PascalCase, вы можете использовать любой стиль именования при обращении к пользовательскому элементу. Это означает, что и являются приемлемыми вариантами. Однако, обратите внимание, что только имена в kebab-case являются валидными при использовании непосредственно в DOM (т.е. не строковые шаблоны).
Глобальная регистрация
До сих пор мы создавали компоненты с помощью Vue.component :
Такие компоненты регистрируются глобально. Это означает, что они могут использоваться в шаблоне любого корневого экземпляра ( new Vue ), созданного после регистрации. Например:
Это относится также ко всем дочерним компонентам и означает что все три из этих компонентов также будут доступны внутри каждого из них.
Локальная регистрация
Глобальная регистрация часто не идеальна. Например, если вы используете систему сборки, такую как Webpack, глобальная регистрация всех компонентов означает, что даже если вы прекратите использовать компонент, то он всё равно будет включён в вашу сборку приложения. Это излишне увеличит количество JavaScript, который должны будут загрузить ваши пользователи.
В таких случаях вы можете определить свои компоненты как обычные объекты JavaScript:
Затем укажите компоненты которые вы хотите использовать в опции components :
Или если вы используете модули ES2015, например, через Babel и Webpack, это может выглядеть так:
Модульные системы
Локальная регистрация в модульной системе
Затем вам нужно будет импортировать каждый компонент, который вы хотите использовать, прежде чем регистрировать его локально. Например, в гипотетическом файле ComponentB.js или ComponentB.vue :
Автоматическая глобальная регистрация базовых компонентов
Многие из ваших компонентов будут относительно общими, возможно только оборачивая элемент, например input или button. Мы иногда ссылаемся на них, как на базовые компоненты и они, как правило, очень часто используются в ваших компонентах.
В результате многие компоненты будут содержать в себе длинные списки базовых компонентов:
Только для поддержки относительно небольшой разметки в шаблоне:
К счастью, если вы используете Webpack (или Vue CLI 3+, которая использует Webpack внутри), вы можете использовать require.context для глобальной регистрации только таких, очень общих базовых компонентов. Ниже приведён пример кода, который можно использовать для глобального импорта базовых компонентов в файле точки старта вашего приложения (например, src/main.js ):
Запомните, что глобальная регистрация должна происходить до создания корневого экземпляра Vue (с помощью new Vue ). Вот пример этого шаблона в реальном контексте проекта.
# Введение
# Почему появился Composition API?
Прежде чем приступать к изучению этого раздела документации необходимо понимать как базовые основы Vue, так и принципы создания компонентов.
Создание компонентов Vue позволяет извлекать повторяющиеся части интерфейса, вместе со связанной функциональностью, в переиспользуемые части кода. Этот подход добавляет приложению достаточно много с точки зрения удобства обслуживания и гибкости. Однако, коллективный опыт показал, что этого всё ещё может быть недостаточно, если приложение становится действительно большим — когда счёт идёт на несколько сотен компонентов. Когда приходится работать с такими большими приложениями — возможность разделения и переиспользования кода становится крайне важна.
Представим, что в приложении есть компонент, который отображает список репозиториев конкретного пользователя. Поверх него, нужно реализовать функциональность поиска и фильтрации. Компонент, управляющий подобным отображением, может выглядеть так:
Этот компонент имеет несколько обязанностей:
Пример большого компонента, в котором сгруппированы по цвету его логические блоки.
Подобная фрагментация усложняет понимание и поддержание таких сложных компонентов. Разделение по опциям делает менее заметными логические блоки используемые в них. Кроме того, при работе над одной логической задачей приходится постоянно «прыгать» между блоками в поисках соответствующего кода.
Было бы удобнее, если соответствующий логическому блоку код можно разместить рядом. И это именно то, чего позволяет добиться Composition API.
# Основы Composition API
# Опция компонента setup
Опция setup должна быть функцией, которая принимает аргументами props и context (о которых подробнее поговорим дальше). Кроме того, всё что возвращается из функции setup будет доступно для остальных частей компонента (вычисляемых свойств, методов, хуков жизненного цикла и т.д.), а также в шаблоне компонента.
Добавим setup в компонент:
Извлечём логику первого логического блока (отмеченной как «1» в исходном примере).
Начнём с самых очевидных частей:
Начало положено! Пока что ещё не всё работает, потому что переменная repositories не реактивна. С точки зрения пользователя, список репозиториев будет оставаться пустым. Давайте это исправим!
# Реактивные переменные с помощью ref
Наличие объекта-обёртки вокруг любого значения позволяет безопасно использовать его в любой части приложения, не беспокоясь о потере реактивности где-то по пути.
Другими словами, ref создаёт реактивную ссылку к значению. Концепция работы со ссылками используется повсеместно в Composition API.
Возвращаясь к примеру, создадим реактивную переменную repositories :
Готово! Теперь каждый вызов getUserRepositories будет изменять repositories и обновлять вид блока, чтобы отобразить изменения. Компонент станет выглядеть так:
Начнём с хука жизненного цикла.
# Использование хуков жизненного цикла внутри setup
Эти функции принимают аргументом коллбэк, который выполнится при вызове компонентом хука жизненного цикла.
Добавим его в функцию setup :
# Отслеживание изменений с помощью watch
Простой пример, чтобы понять как это работает:
Эквивалент при использовании Options API:
Более подробную информацию о watch можно найти в продвинутом руководстве.
# Функция setup
В этом разделе используется синтаксис однофайловых компонентов в примерах кода
Подразумевается, что уже изучили и разобрались с разделами Введение в Composition API и Основы реактивности. Если нет — прочитайте их сначала.
# Аргументы
При использовании функции setup она будет получать два аргумента:
Разберёмся подробнее с тем, как можно использовать каждый из аргументов.
# Входные параметры
Поскольку props реактивны, то нельзя использовать деструктуризацию ES6, потому что это уберёт реактивность со входных параметров.
Если необходимо выполнить деструктуризацию входных параметров, то это можно сделать с помощью toRefs внутри функции setup :
# Контекст
Так как объект context будет обычным объектом JavaScript (т.е. он нереактивный), то для context можно спокойно использовать деструктуризацию ES6.
Роль expose рассмотрим в ближайшее время.
# Доступ к свойствам компонента
При выполнении setup ещё не будет создан экземпляр компонента. Поэтому можно получить доступ только к следующим свойствам:
Другими словами, не получится обратиться к следующим опциям компонента:
# Использование в шаблонах
# Использование в render-функциях
Функция setup может также возвращать render-функцию, которая сможет использовать реактивное состояние, объявленное в той же области видимости:
Возвращение render-функции, не позволяет возвращать что-либо ещё. Внутри компонента это не проблема, но могут быть сложности, если нужно объявить методы этого компонента, которые могут использоваться родительским компонентом через ссылки в шаблоне.
Теперь метод increment доступен в родительском компоненте через ссылку в шаблоне.
# Использование this
Внутри setup() использование this не будет ссылкой на текущий активный экземпляр. Так как setup() вызывается до разрешения других опций компонента, то поведение this внутри setup() будет несколько отличаться от this в других опциях. Это может привести к путанице при использовании setup() совместно с другими Options API.
(opens new window)
Последнее обновление страницы: около 2 месяцев назад