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

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

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

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

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

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

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

// Отправка
this.$emit('my-event') // instead of myEvent
// Прослушивание
v-on:my-event

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

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

watch: { myProperty() { this.doSomething(); }
},
created() { this.doSomething();
},
methods: { doSomething() { console.log('doing something...'); }
},

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

watch: { myProperty: { immediate: true, // вводим обработчик для статуса инициализации handler() { this.doSomething(); } }
},
methods: { doSomething() { console.log('doing something...'); }
},
// Еще лучшее решение
watch: { myProperty: { immediate: true, // вводим обработчик для статуса инициализации handler() { console.log('doing something...'); // Нет необходимости объявлять функцию в методах первого случая использования } }
},

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

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

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

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

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

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

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

В руководстве стиля 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 можно найти в руководстве по стилю.

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

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

<ul> <li v-for="game in games" v-if="game.isActive" :key="game.slug" > {{ game.title }} <li>
</ul>

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

this.games.map(function (game) { if (game.isActive) { return game.title }
})

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

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

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

// Хранилище
[SOME_ACTION] () { // Выполняем вещи, которые занимают какое-то время console.log('Action done');
}
// Предполагаемое действие
async doSomething() { await dispatch(SOME_ACTION); console.log('Do stuff now');
}
Это даст:
// Do stuff now
// Action done

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

// Хранилище
[SOME_ACTION] () { // Выполняем вещи, которые занимают какое-то время console.log('Action done'); Promise.resolve();
}
// Предполагаемое действие
async doSomething() { await dispatch(SOME_ACTION); console.log('Do stuff now');
}
Это даст:
// Action done
// Do stuff now

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

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

// У нас есть селектрор
export const language = (state) => state.userConfig.language;
// В одном из действий нам нужен language:
// Плохо
[GET_GAMES]({ commit, rootState }) { const lang = rootState.userConfig.language; // Делаем что-то...
}
// Хорошо
[GET_GAMES]({ commit, rootState }) { const lang = language(rootState); // Делаем что-то...
}

Заключение

Автор: Riccardo Polacci

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

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