От автора: в предлагаемой статье начинающие разработчики на VueJs найдут ряд советов по работе с фреймворком.
Не используйте одно и то же имя для файла компонента, объявлений шаблона компонента и свойства имени компонента.
<template> <foo-bar-component></foo-bar-component> <template>
import FooBarComponent from '../components/FooBarComponent.vue' default { name: 'FooBarComponent', components: { 'foo-bar-component': FooBarComponent }
}Объявления шаблонов компонентов должны быть записаны в snake-case версии имени файла компонента, имя файла должно быть написано в PascalCase. Чтобы преобразовать PascalCase в snake-case, просто замените заглавные буквы (кроме первой!) на дефисы:
YouAreAwesome --> you-are-awesome ThisMakesDebuggingEasier --> this-makes-debugging-easier
Да — это упрощает отладку, при использовании VueDevTools намного проще найти все, если все имена; имя файла, атрибут name в компоненте и декальтивация компонента в блоках шаблона одинаковы, за исключением кейса.
Не перенос строки
Неверно:
<div class="warning-subtext">{{firstLetterUpperCase(participant.fullName)}} will not be able to see your message until his/her employer turns Coach Chat on.</div>Верно:
<div class="warning-subtext"> {{firstLetterUpperCase(participant.fullName)}} will not be able to see your message until his/her employer turns Coach Chat on.
</div>Неверно:
<div class="survey-popup-card-footer"> <b-button class="btn-heartbeat small white" variant="secondary" @click="handleHidePopup">BACK TO SURVEY</b-button> <b-button class="btn-heartbeat small blue" variant="primary" @click="handleCancelSurveyToDeleteQuestions">CANCEL</b-button> </div>
Верно:
<div class="survey-popup-card-footer"> <b-button class="btn-heartbeat small white" variant="secondary" @click="handleHidePopup" >BACK TO SURVEY</b-button> <b-button class="btn-heartbeat small blue" variant="primary" @click="handleCancelSurveyToDeleteQuestions" >CANCEL</b-button> </div>
Неверно:
import { FETCH_EMBER_PATHS, FETCH_EMBER_REVIVE_PATHS, FETCH_EMBER_FILTERED_PRACTICES, FETCH_EMBER_PRACTICES_BY_ID, FETCH_EMBER_PRACTICES_BY_PATHS, FETCH_EMBER_PATH_ELIGIBILITY } from '../../store/modules/embers/constants';Верно:
import { FETCH_EMBER_PATHS, FETCH_EMBER_REVIVE_PATHS, FETCH_EMBER_FILTERED_PRACTICES, FETCH_EMBER_PRACTICES_BY_ID, FETCH_EMBER_PRACTICES_BY_PATHS, FETCH_EMBER_PATH_ELIGIBILITY } from '../../store/modules/embers/constants';Перенос строк — это просто означает, что мы можем одновременно открывать два или три файла в редакторах, это означает, что мы можем читать PR без боковой прокрутки, что означает их быстрее читать, это упрощает чтение кода и если код легче читать, его легче отлаживать. Если код правильно обернут, вероятность того, что он будет содержать ошибки, меньше, потому что вы не скрываете вещи за пределами экрана.
Это не нужно делать вручную, расширение VSCode prettier имеет действительно хорошую поддержку Vue и отлично справляется с автоматизацией форматирования.
Используйте одну и ту же версию NodeJs для баз кода
Переключение между проектами должно быть простым — репозиторий, проверка ветки, установка npm, запуск dev. Написание кода — должно быть быстрым, достаточно быстрым, чтобы вам не казалось, что вам нужно пойти и сварить кофе после запуска dev. Вы должны иметь возможность сказать любому другому разработчику: «Запусти мою ветку и посмотри, что я имею в виду», и они смогут сделать это очень быстро, поскольку наличие той же версии Node — важная часть этого.
Обычно эта проблема возникает при использовании SCSS / SASS, если вы не используете препроцессоры, то вы, вероятно, можете игнорировать это.
Node 12.x — четный номер версии, что означает, что это версия LTS, выпуск Long Term Stable. Это означает, что ошибки в Node будут исправлены. Это также означает, что когда мы обновляем системы сборки, остается на одну вещь меньше.
Я предлагаю использовать пакет nvm Node Version Manager. Установите его, затем выполните nvm current и посмотрите результат, если вас интересует правильность, вы должны увидеть 12.xx.xx или 14.xx.xx. Самым важным здесь является то, что члены команды видят одно и то же.
TL; DR — установите nvm и тогда выполните:
nvm install 12.16.1 && nvm alias default 12.16.1
Отсутствие :key при использовании v-for
В принципе, если вы пишете v-for, вам нужно предоставить ключ:
<my-awesome-component class="intelligent-reusable-class-name" v-for="(value, index) in listOfThings" :key="index" ></my-awesome-component>
Если вы внимательно прочитаете документацию, вы увидите, что есть несколько вариантов использования с более высокой производительностью, в которых вы не стали бы использовать :key. Если вы думаете, что нашли один из этих вариантов использования, свяжитесь с Хэмишем, чтобы обсудить это, в противном случае используйте :key.
В наших целях мы добавляем :key каждый раз, когда используем v-for.
Написание повторно используемых блоков кода или новых компонентов
Этот элемент является прологом другого поста, который я сейчас пишу. Даже если вы используете фреймворк, такой как vuetify или vue-bootstrap (чего я не одобряю и с чем не согласен, но тем не менее), это не должно означать, что вы никогда не пишете новые пользовательские компоненты. Распространенными случаями — при использовании фреймворка — могут быть такие вещи, как компоненты оболочки для часто используемых групп компонентов фреймворка, если вы часто используете набор из двух или трех кнопок, напишите компонент оболочки с именем HorizontalButtonWrapper или напишите v-if / v- else и в компоненте маршрутизатора верхнего уровня используйте компонент, чтобы обернуть логику и уменьшить количество строк в блоке шаблона.
Каждый раз, когда вы обнаружите, что используете CTRL + C, CTRL + V — напишите новый компонент и повторно используйте код, а не используйте один и тот же код дважды! Одним из основных преимуществ использования фреймворка SPA, такого как Vue, является повторное использование кода. Компоненты — вот как проявляется это преимущество. Это также дает разработчикам возможность действительно уменьшить размеры пакетов при правильном использовании.
Есть предел тому, как далеко вы должны зайти, наличие в репозитории тысяч файлов, которые очень редко используются — это всего лишь еще один симптом неопытности или неорганизованного мышления. Но то, что я видел гораздо чаще – это огромные файлы Vue с тонной спагетти-кода, значительно замедляющие отладку или рефакторинг, и, как указано выше, это
полное игнорирование одного из основных преимуществ использования Vue.
Чем больше кода вы повторно используете, тем меньше ошибок вы создадите. Чем больше кода вы повторно используете, тем меньше модульных тестов вам придется писать. Чем меньше ваш блок кода, тем легче будет его тестировать.
Каждый раз, когда вы обнаружите, что используете CTRL + C, CTRL + V — напишите новую функцию и используйте код повторно, а не используйте один и тот же код дважды!
Некоторые примеры
Неверно:
<template> <div class="row-container"> <div class="row-item-container one"> <div class="row-item-actual">{{ someData }}</div> </div> </div> <div class="row-container"> <div class="row-item-container two"> <div class="row-item-actual">{{ someOtherData }}</div> </div> </div> <div class="row-container"> <div class="row-item-container three"> <div class="row-item-actual">{{ someMoreData }}</div> </div> </div>
</template>Верно:
<template> <div class="row-container" :class="value.className" v-for="(value, index) in computedProperty" :key="index" > <div class="row-item-container> <div class="row-item-actual">{{ value.data }}</div> </div> </div>
</template>default { computed: { computedProperty() { return [ { value: this.someData, className: 'one' }, { value: this.someOtherData, className: 'two' }, { value: this.someMore∂Data, className: 'three' } ] } }
}Даже лучше:
<template> <row-container class="row-container" :class="value.className" v-for="(value, index) in computedProperty" :key="index" :dataAsProp="value.data" ></row-container> </template>
default { computed: { computedProperty() { return [ { value: this.someData, className: 'one' }, { value: this.someOtherData, className: 'two' }, { value: this.someMore∂Data, className: 'three' } ] } }
}Каждый раз, когда вы можете уменьшить повторное использование кода, вы фактически экономите время. Меньше ошибок, меньше обслуживания, что упрощает чтение и понимание для другого человека.
Вы можете подумать: «Но так быстрее!» Это не так.
Сегодня это быстрее, но это означает, что после завершения функции вы тратите больше времени на исправление ошибок. Вы также ничего не узнаете, а это значит, что в следующий раз, когда вам нужно будет выполнить ту же задачу, вы сделаете то же самое. Если бы вы написали это хорошо с первого раза и написали так, чтобы вы и все остальные могли это повторно использовать — вы бы уже были за обедом или дома со своей семьей — но вместо этого вы яростно копируете и вставляете код откуда-то, пытаясь уложиться в дэдлайн.
Это реально — хочешь двигаться быстрее — иди медленнее. Каждый раз, когда вы обнаруживаете, что используете CTRL + C, CTRL + V — напишите новую функцию или новый компонент и повторно используйте код, а не используйте один и тот же код дважды!
Другой документ по этой теме в настоящее время находится в разработке, потому что это одна из самых больших проблем, которые у нас есть в наших базах кода.
Игнорирование предупреждений от системы сборки, eslint или VSCode
Хотите верьте, хотите нет — предупреждения существуют не зря! Они существуют потому, что более умные люди, чем мы, решили, что если мы разберемся с предупреждением, оно уменьшит количество ошибок, а если мы проигнорируем его… Придется потратить время на исправление ошибок.
Предупреждения — ваши друзья. Если вы его видите, погуглите. После этого исправьте. Затем зафиксируйте это. Если вы не можете это исправить, свяжитесь с одним из старших сотрудников, чтобы получить помощь.
Проблема, которая существует в настоящее время, заключается в том, что у нас так много предупреждений, что они больше ничего не значат. Давайте это исправим!
Работа с предупреждениями из консоли разработчика, из Webpack, из NPM и из расширений VSCode действительно может значительно сократить время, которое мы тратим на исправление ошибок …
Попытайтесь исправить одно предупреждение в день. Это сделает вас более счастливым разработчиком.
Использование eslint-disable
Совсем неверно:
// es-lint disable const someDodgyCode = expressionThatTriggeredAnEslintWarning()
Верно (но очень-очень редко):
return () => { // Explain: 'arguments' is a javascript keyword, eslint is wrong // Blame: Hamish // eslint-disable-next-line no-undef const context = this, args = arguments const later = () => {Предупреждения Eslint похожи на предупреждения, упомянутые выше, они существуют не просто так. Они были написаны людьми, которые являются экспертами высшего уровня в этой области, они помогут вам стать лучшим разработчиком и предотвратят написание кода с ошибками.
Если вы используете es-lint disable, вы должны предоставить:
// Explain: reason for using, why you think eslint is wrong // Blame: Your Name Here
Я находил всего только два или три места, где eslint disable был правильным решением. Это редкость. Вместо использования disable — погуглите проблему, а затем исправьте свой код. Если вы не можете исправить его, и предупреждение исчезло, свяжитесь с одним из старших сотрудников, а затем вместе решите проблему.
Если вы считаете, что конфигурация eslint неправильная, поговорите со своим руководителем группы и измените конфигурацию, чтобы она отражала ваши рассуждения.
Используйте $forceUpdate
В 99% случаев $forceUpdate() — это неправильное решение, вы можете добиться тех же результатов, используя :key и $set(), а иногда $nextTick(). Практически никогда не бывает причин перезагружать все дерево компонентов.
Если вы окажетесь в положении, в котором действительно хотите его использовать, свяжитесь со мной или с одним из старших сотрудников, чтобы найти способ обойти проблему. $forceUpdate() может легко вызвать полную перезагрузку страницы, что очень плохо для взаимодействия с пользователем, и заставляет одностраничное приложение вести себя так же, как стандартное приложение HTML SSR. Это плохо — и ситуацию всегда можно исправить с помощью других методов Vue API.
Включите магические числа и строковые литералы
Неправильно:
const foo = 300000 this.bar = 'some awesome string'
Правильно:
import { AWESOME_CONST } from '../constants/time.js' const FIVE_MINUTES = 1 * 1000 * 60 * 60 // Five minutes in miliseconds
this.bar = AWESOME_CONSTДовольно просто: не должно быть никаких чисел, плавающих вокруг базы кода, объявляйте переменную с описательным именем и пояснительным комментарием, то же самое касается строк, литералы не могут быть интернационализированы позже, а магические числа трудно понять, если вы не описали их.
Использование ненужных блоков <template>
Неправильно:
<template v-if="someThing"> <template v-if="someOtherThing && anotherThing || somethingElse"> <div> // some content here </div> </template> <template>
Шаблоны — это невидимые элементы, предоставляемые VueJs, позволяющие группировать элементы вместе. Вам не нужен шаблон для использования v-if или v-show. Вы можете использовать v-if и v-show для любого элемента!
Также неправильно:
<template v-if="something"> <cool-component v-for="(datas, index) in arrayOfData" :key="index" ></cool-component> </template>
Использование шаблона, потому что вы не можете использовать v-if и v-for для одного и того же элемента. Намного проще использовать вычисляемое свойство и Array.filter() или Object.keys().
<cool-component v-for="(datas, index) in filteredArrayOfData" :key="index" ></cool-component>
computed: { filteredArrayOfData() { return arrayOfData.filter(value => { return value !== something }) }
}Оно будет работать быстрее, его легче читать, и вы правильно используете Vue API. На самом деле есть только одно место, где вы должны использовать <template> — когда вы хотите сгруппировать несколько элементов вместе для условной видимости.
<template v-if="something"> <div>{{ someOtherData }}</div> <cooler-component></cooler-component> <span>{{ fooBar }}</span>
</template>Использование !important, когда это не нужно
Каждый раз, когда вы обнаруживаете, что используете !important, вы, вероятно, ошибаетесь. Когда вы обнаруживаете себя в положении, в котором чувствуете, что должны использовать правило !important, это обычно происходит из-за неправильной структуры файлов CSS / SCSS в вашей кодовой базе. Самое важное, что нужно запомнить — это то, что CSS построен как иерархия, поэтому вы должны использовать !important либо потому, что кто-то другой использовал его до вас (что приводит к нескончаемой битве в CSS за использование правил избавления !important), либо потому, что сторонний CSS был включен слишком далеко в иерархию CSS.
Я допускаю, что иногда вам придется использовать !important — но прежде чем использовать его, найдите время и спросите себя, почему вы должны это сделать.
Гораздо лучше решить проблему, чем избегать ее. Если вы посмотрите на правила CSS в консоли разработчика браузера, сможете ли вы увидеть, не отменяете ли вы правило из файла css поставщика или написанное нами правило. Если это правило поставщика, посмотрите, куда оно импортируется, в main.js? Если да, то импортировано ли оно до или после файла, над которым вы сейчас работаете?
Если вы не можете понять, почему вам нужно !important, свяжитесь с Хэмишем и получите некоторую помощь, обычно это довольно легко исправить.
Использование библиотеки, когда вы можете просто написать код самостоятельно
В настоящее время я вижу одну из самых больших проблем — это размер пакета. Я видел кодовые базы, загружающие 10 МБ ресурсов, что изначально медленно, но эти ресурсы все равно нужно анализировать и считывать в память браузера. Это заставляет приложения работать медленно, а это означает, что пользователи с меньшей вероятностью будут использовать ваш продукт.
Основная причина проблем с размером пакета — слишком много библиотек. Это очень важно, нам нужно прекратить использование дополнительных библиотек для решения проблем, которые мы могли бы легко решить, написав код. Ведь мы разработчики?
В некоторых случаях библиотека — правильный вариант, но во многих случаях это не так. Я видел несколько забавных примеров этого и начал писать пост конкретно об этом.
Использование eval()
Прочтите документы MDN, у них есть хороший пост на эту тему. По сути, это хорошо известная угроза безопасности, и ее никогда не стоит использовать. Вы всегда можете заменить eval() на window.Function().
Забыть закоммитить package-lock.json
Всегда коммитьте package-lock.json. Таким образом мы гарантируем, что все в команде используют одни и те же версии пакетов в папке node_modules. По сути, package-lock.json создает список зависимостей пакетов в вашем package.json, в нашей кодовой базе это могут быть тысячи пакетов. Если один член команды работает с версией 0.12, а другой — с версией 1.01, это может привести к тому, что кто-то скажет…
Почему ваша локальная версия работает, а моя нет? Эти проблемы может быть очень трудно отладить, но их легко предотвратить!
Автор: Hamish Clulee
Источник: https://dev.to
Редакция: Команда webformyself.