Лучшие практики Vue.js

Лучшие практики Vue.js

От автора: привет, друзья-разработчики! После некоторого изучения документации VueJS и Интернета я создал список лучших практик и руководств по стилю для более правильного или общепринятого способа использования VueJS.

Ниже приведены некоторые из них, связанные с функциональностью / оптимизацией, другие — с соглашениями об именах и упорядочением элементов во VueJS. Более подробную информацию можно найти по ссылкам в заключении. Итак, практика Vue.

Очищайте прослушиватели событий для компонента, удаляя их с помощью $off

При прослушивании событий с помощью $on, мы никогда должны не забывать удалить этот прослушиватель с помощью $off для destroyed(). Это предотвращает неоптимальное использование памяти.

Всегда используйте kebab-case для имен событий

При отправке / прослушивании пользовательских событий мы всегда должны использовать kebab-case. Почему? Потому что в любом случае события будут автоматически преобразованы в kebab-case. Мы никогда не будем прослушивать событие в camelCase или PascalCase, поэтому имеет смысл объявить событие так же, как мы будем его прослушивать: в kebab-case.

Фреймворк VUE JS: быстрый старт, первые результаты

Получите бесплатный курс и создайте веб-приложение на трендовой Frontend-технологии VUE JS с полного нуля

Узнать подробнее

Избегайте вызова одного и того же метода в created и watch

Если нам нужно вызвать метод при инициализации компонента и при изменении свойства, обычной практикой является сделать что-то вроде этого:

Даже если это выглядит правильно, использование здесь created() излишне. Мы можем использовать весь функционал watch, избегая, таким образом, дублирования кода created() и при этом вызывая его при создании компонентов. Например:

Всегда используйте :key в циклах v-for

Это обычная практика, всегда добавляйте :key к своим циклам шаблонов. v-for без :key может привести к трудностям при поиске ошибок, особенно с анимацией.

Используйте $ _ для свойств миксинов

Миксины — отличный способ собрать повторяющийся код в один блок и импортировать его столько раз, сколько вам нужно, но (и это очень важно) это может привести к нескольким проблемам. В этом пункте мы рассмотрим проблему перекрывающихся свойств.

Когда мы импортируем миксин в Компонент, мы объединяем код миксина с кодом компонента. Что теперь происходит со свойством с таким же именем? Компонент всегда будет иметь преимущество, свойства компонента имеют более высокий приоритет.

Что если я хочу, чтобы мой миксин имел больший приоритет? Вы не можете назначить приоритет, но вы можете избежать наложения или перезаписи свойств, выбрав правильное соглашение об именах.

Чтобы отличить свойства миксинов от свойств Компонента, мы используем $_. Почему эти символы? Ну, несколько причин:

Конвенция из руководства по стилю VueJS

_ зарезервировано для частных свойств Vue

$ зарезервировано для экосистемы Vue

В руководстве стиля VueJS вы обнаружите, что они предлагают добавить имя миксина, например: $_myMixin_updateUser.
Я обнаружил, что добавление имени миксина создает больше путаницы. Но это также зависит от миксина, ситуации и разработчика.

Добавив просто $_, например, в $_updateUser, я обнаружил, что код стал более читабельным.

То, что используется в миксине, должно захватываться в миксине

В продолжение предыдущего пункта, у миксинов есть еще одна проблема: мы забываем о вещах.

Если мы создаем миксин, который использует, скажем, this.language, и это свойство не определяется или не захватывается из хранилища внутри миксина, то компонент, в котором определен миксин, должен содержать это свойство language.

Как вы уже знаете, это чревато ошибками. Чтобы избежать этих ошибок, мы берем то, что нужно миксину внутри самого миксина. Не волнуйтесь, если мы берем что-то дважды, VueJS достаточно умный, и не будет выполнять двойную работу, если обнаружит, что те же вещи были захвачены из Хранилища (так как в большинстве случаев вещи будут захватываться из Vuex)

Используйте PascalCase или kebab-case для однофайловых компонентов

PascalCase имеет лучшую интеграцию с редакторами и обеспечивает лучший функционал автозаполнения / импорта в часто используемых IDE.

Kebab-case — это решение, если мы хотим избежать проблем с нечувствительными к регистру файловыми системами.

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

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

Используйте PascalCase для имен компонентов в JS

В JavaScript PascalCase является соглашением для классов и конструкторов прототипов, имеет смысл, чтобы компоненты Vue также использовали PascalCase.

Если мы используем только глобальные определения компонентов через Vue.component, рекомендуется использовать kebab-case.

В именах свойств всегда должен использоваться при объявлении camelCase, но в шаблонах kebab-case

Следуя соглашению каждого языка: JavaScript (camelCase) и HTML (kebab-case), имеет смысл, чтобы prop определялось в JS в camelCase, а в HTML использовался kebab-case.

Используйте порядок параметров компонента из руководства по стилю

Это может показаться тривиальным, но следование одному и тому же порядку для всех параметров компонента во всем проекте очень помогает при поиске материала и создании новых компонентов. Соглашение VueJs можно найти в руководстве по стилю.

Фреймворк VUE JS: быстрый старт, первые результаты

Получите бесплатный курс и создайте веб-приложение на трендовой Frontend-технологии VUE JS с полного нуля

Узнать подробнее

Никогда не используйте v-if для того же элемента, что и v-for

Это убийство производительности, чем больше список, тем больше производительность пострадает от этой практики. Давайте объясним это с помощью кода, представьте следующий сценарий:

Будет оцениваться аналогично следующему:

Здесь мы видим, что нам придется перебирать весь список games, не зависимо от того, были ли активные games изменены или нет. В других средах, таких как Angular, эта практика просто не компилируется (*ngIf не может находиться в том же элементе, где есть *ngFor).

Действия должны всегда возвращаться

Это плод борьбы с async/ await и действиями Vuex. Возьмем следующий пример:

Это происходит потому , что await не знает, чего ожидать, а вместо этого, если мы на самом деле возвращаем Promise.resolve(), то await будет ожидать разрешения , а затем двигаться дальше.

Используйте селекторы внутри действий и геттеров

Мы создаем селекторы не просто, чтобы использовать их во всем приложении, но и в хранилище Vuex. Объясним это на примере кода:

Заключение

Очищайте прослушиватели событий при удалении компонента с помощью $off

Всегда используйте kebab-case для имен событий

Избегайте вызова одного и того же метода в created и watch

Всегда используйте :key в циклах v-for

Используйте $_ для свойств микисинов

То, что используется в миксине, должно захватываться в миксине

Используйте PascalCase или kebab-case для однофайловых компонентов

Использовать префикс для имен базовых компонентов

Используйте PascalCase для имен компонентов в JS

Для имен свойств всегда должен использоваться camelCase во время объявления, но kebab-case в шаблоне

Используйте порядок параметров компонента из руководства по стилю

Никогда не используйте v-if для того же элемента, что и v-for

Действия должны всегда возвращаться. Это позволяет избежать недоразумений относительно того, когда действие выполнено

Используйте селекторы внутри действий и геттеров

Автор: Riccardo Polacci

Источник: https://blog.usejournal.com/

Редакция: Команда webformyself.

Фреймворк VUE JS: быстрый старт, первые результаты

Получите бесплатный курс и создайте веб-приложение на трендовой Frontend-технологии VUE JS с полного нуля

Узнать подробнее

Фреймворк VUE JS

VUE JS - полное руководство для современной веб-разработки

Подробнее

Метки:

Похожие статьи:

Комментарии Вконтакте:

Комментарии Facebook:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Я не робот.

Spam Protection by WP-SpamFree