Русский
Русский
English
Статистика
Реклама

Eslint

Перевод Почему вы можете обойтись без Babel

01.03.2021 20:22:05 | Автор: admin

Для будущих студентов курса "JavaScript Developer. Basic" подготовили перевод материала.

Также приглашаем всех желающих на открытый вебинар
Код как проект настройка окружения для разработки на JavaScript. На вебинаре участники вместе с экспертом рассмотрят основные инструменты, которые помогают делать код лучше и чище prettier, eslint, husky.


В наше время фронтенд-разработчики все еще тратят много времени на чрезмерную подготовку и настройку программного обеспечения. Babel воспринимается некоторыми как вынужденная необходимость, но я намерен показать вам, что это не так.

Ознакомившись с этой статьей, вы поймете:

  • как выяснить, какие браузеры действительно требуют дополнительной поддержки в каждом конкретном случае.

  • как использовать редактор Visual Studio Code, чтобы обойтись без Babel.

  • существует другая альтернатива программного обеспечения, чтобы сделать ту же работу быстрее.

Что такое Babel и какую проблему он решает?

Babel это компилятор, который преобразует ваш современный JavaScript для запуска в старых браузерах. Он также может выполнять и другие задачи, такие как преобразование синтаксиса JSX, но это не единственный инструмент для этого.

По мере развития браузеров добавляются новые функции API и ECMAScript. Различные браузеры развиваются с разной скоростью и расставляют акценты в качестве приоритетных для разных задач. Это ставит нас перед непростым выбором: как мы можем их все поддерживать и при этом использовать современные функции? Некоторые из них будут несовместимы.

Обычное решение заключается в том, чтобы использовать новейшие возможности и трансформировать их в более старый код, который будет понятен браузеру. Транспилирование (Transpiling сочетание двух слов: transforming преобразование и compiling компиляция) описывает специализированный тип компиляции. Она имеет различные значения в разных контекстах. В нашем случае также существуют две отдельные составляющие для переноса (транспилирования).

Разница между транспилированием (transpiling) и полифилингом (polyfilling)

Транспилирование (Transpiling) это процесс преобразования синтаксиса нового языка, который старые браузеры не могут понять, в старый синтаксис, который они распознают.

Приведем пример переноса оператора let:

// the new syntax `let` was added in ECMAScript 2015 aka ES6let x = 11;// `let` transpiles to the old syntax `var` if your transpiler target was ES5var x = 11;

Полифилинг (Polyfilling) это процесс добавления недостающих методов, свойств или API к старым браузерам путем предоставления собственной версии недостающего родного кода.

Это можно рассматривать как дополнение недостающих элементов. Например, вот полифил (polyfill) для isNaN:

// check if the method `isNaN` exists on the standard built-in `Number` objectif (!Number.isNaN) {  // if not we add our own version of the native method newer browsers provide  Number.isNaN = function isNaN(x) {    return x !== x;  };}

Наилучшим способом для получения полифилов является использование core-js.

Транспилирование и полифилинг иногда невозможны и могут значительно увеличить объем кода, лучше всего их вообще избегать, если это возможно. Поэтому альтернатива, которую мы будем рассматривать в первую очередь, является наиболее оптимальным решением.

Альтернатива 1: не поддерживать древние браузеры

Если бы пользователи просто обновили свои браузеры, мы могли бы избежать хлопот, связанных с транспилированием, и они могли бы наслаждаться усовершенствованными функциями и производительностью нового браузера. К сожалению, все не так просто.

Главный виновник крупные корпорации, которым приходится поддерживать старое программное обеспечение. Классическим примером является Internet Explorer, который с самого начала был помехой для веб-разработок.

Тем не менее, за последние годы многое изменилось в лучшую сторону. Теперь большинство существующих браузеров актуальны, то есть они постоянно обновляются. Microsoft продвигает свой современный браузер Edge, который, что удобно, использует тот же движок V8, как и Chrome, что означает сокращение количества поддерживаемых движков на один.

Чтобы определить, нужно ли поддерживать определенный браузер, задайте себе следующие вопросы.

1. Какие браузеры в настоящее время используют Ваши клиенты?

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

Если у вас не установлено аналитическое программное обеспечение, вы не будете знать, какие браузеры вам нужно поддерживать. Вы должны будете сделать обоснованное предположение. Если у вас есть корпоративные клиенты, гораздо больше шансов, что вам понадобится поддержка IE11 (Internet Explorer 11), чем если бы вы занимались маркетингом для фанатов web-literate (грамотное программирование) технологий.

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

Должна быть ясная финансовая причина, чтобы пойти на все эти хлопоты. Будет ли потеря тех клиентов, которые не могут получить доступ к вашему сайту или приложению, стоить дороже, чем поддержка браузера?

2. Какие современные функции браузера вы хотите использовать?

Использование современных функций языка и API (Application Programming Interfaces) браузера делает написание кода проще, быстрее и интереснее. Это также делает ваш код более удобным в обслуживании.

Если вам нравиться писать ES5 (ECMAScript) и использовать XMLHttpRequest(), тогда определенно не нужен Babel, но может потребоваться какая-нибудь специальная процедура.

3. Какие современные функции браузера поддерживают браузеры ваших клиентов?

Эти данные доступны через Can I use (могу ли я использовать), но это напрасная трата времени на их поиск вручную. Теперь, когда вы знаете названия браузеров, которые вы хотите поддерживать, поиск совместимых функций может быть автоматизирован с помощью удивительного приложения Browserlist (подробнее об этом в следующем разделе).

Альтернатива 2: Используйте eslint-plugin-compat

Вы можете вообще избежать всего процесса переноса (transpiling) и вместо этого позволить вашему редактору кода предупредить вас, если вы используете какие-либо функции, которые слишком сложны для браузеров ваших клиентов. Это самый простой вариант, потому что он:

  • исключает любую зависимость от транспилиров (transpilers). Возвращает вам практический контроль над рабочим кодом.

  • если имеется современная функция, без которой вы не можете жить, то ее можно использовать применив полифил (polyfill).

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

Создать тест

Прежде чем мы сможем разобраться в плюсах и минусах, надо убедиться, что наши альтернативы Babel могут выполнять ту же самую основную работу. Давайте сделаем небольшой тест.

Ниже приведен современный код, который должна поддерживать наша целевая среда после переноса (transpiled).

После переноса (transportation) для каждой функции есть console.assert (метод записи сообщений на консоли для пользователя), чтобы убедиться, что она работает, как положено. В случае eslint-plugin-compat вместо этого проверим, что несовместимый код помечен в linting (Linting это процесс, выполняемый программой linter, которая анализирует исходный код на определенном языке программирования и отмечает потенциальные проблемы, такие как синтаксические ошибки, отклонения от предписанного стиля кодирования или использование конструкций, о которых известно, что они небезопасны).

test.js

// test nullish coalescing - return right side when left side null or undefinedconst x = null ?? "default string";console.assert(x === "default string");const y = 0 ?? 42;console.assert(y === 0);// test optional chaining - return undefined on non existent property or methodconst adventurer = {  name: "Alice",  cat: {    name: "Dinah",  },};const dogName = adventurer.dog?.name;console.assert(dogName === undefined);console.assert(adventurer.someNonExistentMethod?.() === undefined);// use browser API fetch, to check lintingfetch("https://jsonplaceholder.typicode.com/todos/1")  .then((response) => response.json())  .then((json) => console.log(json));

Использование eslint env свойства с помощью eslint-plugin-compat

Нам нужен обходной путь для объединения функций языка и API браузера.

Вы можете использовать eslint (Eslint это утилита, проверяющая стандарты кодирования на JavaScript) для проверки синтаксиса языка. Для этого измените свойство env наes2020.

Для проверки совместимости API браузера используйте eslint-plugin-compat. Он использует ту же самую конфигурацию Browserlist и остальные инструменты, что и Babel.

Полную инструкцию можно найти в eslint-plugin-compat repo. Мы воспользуемся browserlist defaults как предустановками по умолчанию. Замените их по своему выбору, основанному на аналитике.

Что такое browserlist?

Browserlistавтоматически выбирает список браузеров, основываясь на различных критериях, которые Вы ему предоставляете.

Посмотрите список браузеров, поддерживаемых defaults для browserlist.

defaults использует быстрый доступ к таким версиям браузеров:

  • > 0,5 процента (версии браузеров, выбранные по глобальной статистике использования)

  • Последние две версии (каждого "живого (not dead)" браузера)

  • Firefox ESR (Extended Support Release)

  • Живые (not dead) (браузеры без официальной поддержки и обновлений в течение 24 месяцев).

Перейдите на GitHub, чтобы получить полный список запросов, доступных для выбора поддерживаемых браузеров.

Настройка eslint-plugin-compat для Visual Studio Code

Добавьте следующие пакеты в свой проект.

npm install --save-dev eslint eslint-plugin-compat

Добавьте следующее в package.json.

"browserslist": [    "defaults"  ]

Создайте следующий файл .eslintrc.json или добавьте эти настройки к существующим.

{  "extends": ["plugin:compat/recommended"],  "env": {    "browser": true,    "es2020": true  }}

Убедитесь, что у вас установлено расширение VS Code ESLint.

Теперь любой API браузера, несовместимый с конфигурацией browserlistв вашем package.json, отображается как ошибка linting. Вы можете отдельно контролировать, какую версию ECMAScript вы хотите поддержать, используя свойство env в файле .eslintrc.json.

Было бы неплохо, если бы eslint-plugin-compat автоматически добавил и возможности языка, но на данный момент это является нерешённой задачей.

IE 11 с выбранной настройкой

наш API fetch() помечен.

Поменяйте объект env на es6.

Вы сразу же увидите ошибку при попытке использовать nullish coalescing, который был запущен в составе Es2020.

Альтернатива 3: Используйте другое программное обеспечение для замены Babel

Прежде чем рассматривать альтернативы, давайте быстро рассмотрим, как использовать Babel.

Использование Babel для транспилирования (transpile) и полифилинга (polyfill)

Сначала создайте директорию мини-проекта и установите нужные нам взаимосвязи.

mkdir babel-testcd babel-testnpm init -ymkdir src distnpm install --save-dev @babel/core @babel/cli @babel/preset-envnpm install --save @babel/polyfill

Добавьте следующее в свой package.json.

"browserslist": "defaults",

Запишите файл test.js вsrc, а затем выполните следующую команду.

npx babel src --out-dir dist --presets=@babel/env

Наконец, запустите файл, чтобы проверить, что тесты все еще работают.

node dist/test.js

Ошибок ввода не должно быть, но будет сказано, что fetch is not defined, так как в Node.js нет метода fetch().

Вот результирующий транспилированный (transpiled) код. Обратите внимание на весь лишний мусор и хлам.

"use strict";var _ref, _, _adventurer$dog, _adventurer$someNonEx;// test nullish coalescing - return right side when left side null or undefinedvar x = (_ref = null) !== null && _ref !== void 0 ? _ref : "default string";console.assert(x === "default string");var y = (_ = 0) !== null && _ !== void 0 ? _ : 42;console.assert(y === 0); // test optional chaining - return undefined on non existent property or methodvar adventurer = {  name: "Alice",  cat: {    name: "Dinah",  },};var dogName =  (_adventurer$dog = adventurer.dog) === null || _adventurer$dog === void 0    ? void 0    : _adventurer$dog.name;console.assert(dogName === undefined);console.assert(  ((_adventurer$someNonEx = adventurer.someNonExistentMethod) === null ||  _adventurer$someNonEx === void 0    ? void 0    : _adventurer$someNonEx.call(adventurer)) === undefined,); // use browser API fetch, to check lintingfetch("https://jsonplaceholder.typicode.com/todos/1")  .then(function (response) {    return response.json();  })  .then(function (json) {    return console.log(json);  });

Преимущества и недостатки использования Babel

Преимущества:

  • Эта базовая установка была относительно несложной.

  • У Babel есть большое сообщество для поддержки и постоянных обновлений с 36.8k GitHub звездами на момент написания статьи.

Недостатки:

  • Медленное время компиляции

  • Множество зависимостей (dependencies), даже если они являются зависимостями (dev-dependencies). (установлено 269 пакетов)

  • 39М использованного дискового пространства, как сообщает du -sh

  • 5728 установленных файлов, о чем сообщает find . -тип f | wc -l

Использование swc для транспилирования (transpile) и полифилинга (polyfill)


Swc новый конкурент Babel. Он написан на языке программирования Rust и в 20 раз быстрее. Это может быть очень важно, если вы долго ждете, чтобы построить свой проект.

Чтобы все устроить:

mkdir swc-testcd swc-testnpm init -ymkdir src distnpm install --save-dev @swc/cli @swc/core browserslist

Добавьте следующее в свой package.json.

"browserslist": "defaults",

Запишите конфигурационный файл .swcrc в корневую директорию проекта.

{  "env": {    "coreJs": 3  },  "jsc": {    "parser": {      "syntax": "ecmascript"    }  }}

Запишите ваш тестовый файл в src, затем выполните следующую команду для переноса (transpile).

npx swc src -d dist

Запустите полученный файл, чтобы проверить, что тесты все еще работают.

node dist/test.js

В итоге swc-transpiled (транспилированный) файл, выглядит вот так:

var ref, ref1;var ref2;// test nullish coalescing - return right side when left side null or undefinedvar x = (ref2 = null) !== null && ref2 !== void 0 ? ref2 : "default string";console.assert(x === "default string");var ref3;var y = (ref3 = 0) !== null && ref3 !== void 0 ? ref3 : 42;console.assert(y === 0);// test optional chaining - return undefined on non existent property or methodvar adventurer = {  name: "Alice",  cat: {    name: "Dinah",  },};var dogName =  (ref = adventurer.dog) === null || ref === void 0 ? void 0 : ref.name;console.assert(dogName === undefined);console.assert(  ((ref1 = adventurer.someNonExistentMethod) === null || ref1 === void 0    ? void 0    : ref1.call(ref1)) === undefined,);// use browser API fetch, to check lintingfetch("https://jsonplaceholder.typicode.com/todos/1")  .then(function (response) {    return response.json();  })  .then(function (json) {    return console.log(json);  });

Преимущества и недостатки использования swc

Преимущества:

  • Гораздо меньше зависимостей (установлено 43 пакета)

Недостатки:

  • Меньшая пользовательская база и количество постоянных участников

Другие альтернативы: Google Closure Compiler и TypeScript

Я не включил Google Closure Compiler в качестве опции, потому что он, как это ни печально, сложен в использовании. Тем не менее, он может сделать хорошую работу по транспилированию (transpile) и полифилингу (polyfill). Если у вас есть свободное время, я рекомендую вам проверить его особенно если вы цените небольшой размер файла, так как встроенная функция минификации демонстрирует отличные результаты.

Вы также можете использовать TypeScript для переноса (transpile) и core-js для ручной полифил (polyfill) обработки, но это неуклюжее решение, которое может с легкостью создать больше проблем, чем решить их.

Заключение

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

При необходимости Вы можете использовать функцию linting, чтобы убедиться в их совместимости друг с другом. Это избавит Вас от лишних хлопот, связанных с созданием специального сборочного процесса и транспиляции (transpilation).

Если вы выберете автоматический перевод, то SWC будет намного быстрее, чем Babel, и будет содержать гораздо меньше зависимостей. Также есть возможность использовать Google Closure Compiler или TypeScript, но для их настройки потребуется немного больше усилий.

LogRocket: Полная видимость ваших веб-приложений

LogRocket это передовое решение для мониторинга приложений, позволяющее воспроизводить проблемы так, как если бы они возникали в вашем собственном браузере. Вместо того, чтобы гадать, почему происходят ошибки, или спрашивать пользователей на скриншотах и дампах логов, LogRocket позволяет воспроизводить сеанс, чтобы быстро понять, что пошло не так. Он отлично работает с любым приложением, независимо от фреймворка, и имеет плагины для записи дополнительного контекста из Redux, Vuex и @ngrx/store.

В дополнение к регистрации действий и состояния Redux, LogRocket записывает журналы консольных сообщений, ошибки JavaScript, следы стеков, сетевые запросы/ответы в формате заголовок + тело, метаданные браузера и пользовательские журналы. Кроме того при помощи DOM (Document Object Model) позволяет записывать страницы HTML и CSS, воссоздавая превосходные в пиксельном отношении видео даже для самых сложных одностраничных приложений.


Узнать подробнее о курсе "JavaScript Developer. Basic".

Смотреть открытый вебинар Код как проект настройка окружения для разработки на JavaScript.

Подробнее..

Идеальное Vue приложение на Typescript

04.02.2021 02:20:23 | Автор: admin

Пока Vue 3 официально еще не вышел, а продакшене в основном 2 версия - я хочу поговорить о типизации и о том, что она все еще не идеальна во Vue. И сегодня мы попробуем создать идеальное приложение с типизацией на typescript сделав упор на code style, пропагандируя vue style guide и прочие обычно не значащие вещи, которые были придуманы умными людьми!

Ремарка

Стоит учитывать, что автор пишет первый свой пост и это пагубно скажется на его качестве и возможно на качестве всего контента на Хабре!

Почему "идеальное"?

Недавно я осознал всю важность стайл-гайдов, очень уперся в качество кода, настройки автоформатирования (eslint) и многие другие вещи, такие как conventional commits, например. Помимо этого я понял, что мне очень нравится, когда мой код подходит под все международные стандарты и принципы, это ли не признание самого себя как неплохого разработчика (риторический вопрос)? Возможно, вы дошли до этого раньше меня и продвинулись еще дальше и увидите в статье недостатки - добро пожаловать в комментарии с объективной критикой.

Какие проблемы с типизацией у Vue?

Версия 2 принесла и популизировала typescript в компонентах и в хранилище (store), но оставила бреши в связи их между собой, store все еще не подсказывает типизацию в компонентах, и это плохо! Следить в ручную можно за чем угодно, но зачем, если можно это исправить и автоматизировать? Чтобы улучшить типизацию мы будем использовать vue-property-decorator для компонентов и vuex-smart-module для прокидывания типов из стора.

Создание проекта и его настройка

Тут все просто, сначала вызываем vue cli и выбираем галочки!

vue create habratest

Наш выбор - vue2, все features, Vue Router History Mode, Vue Class Components, и другие настройки как на скриншоте ниже. Тесты настраиваем по вкусу, в этой статье их касаться не будем.

Vue CLI настройки создания проектаVue CLI настройки создания проекта

Также я рекомендую в графе "Разнести конфиги всего и вся в разные файлы" ставить галочку.

Стили и красота, пока вся тяжесть человеческого прогресса грузится вам в node_modules

В этой статье не будет визуализации и красоты интерфейса, вы можете подключить любую библиотеку внутрь проекта и использовать ее. Мой выбор - vue-bootstrap для легких проектов и quasar для больших. А сегодня красота у нас в коде!

Настройка eslint

Первым делом идем менять настройки! Меняем extends на код ниже - это позволит eslint проверять ваш код более строго - в соответствии с Vue style guide - в соответствии с низшим приоритетом ошибок - recommended.

  extends: [    'plugin:vue/recommended',    '@vue/typescript/recommended'  ],

Это половина победы! Изменение eslint таким образом поможет вам строже соблюдать style guide и в существующем проекте, но будьте осторожны, нередко что-то может пойти не так.

Да, это даже во Vue cli шаблоне исправит пару ошибокДа, это даже во Vue cli шаблоне исправит пару ошибокЧто в eslint можно отлючить

Ничего. Это все поможет вам в написании кода и менять я ничего не рекомендую. Единственное правило, которое можно исключить из проверки - это директива v-html, которая нередко встречается в старой кодовой базе. Но подобное подчеркивание позволит собрать проект и будет лишним напоминанием для вас, так что лучше оставить.

Заодно давайте включим правила для отслеживания одинарных кавычек и удаления лишних точек с запятой - добавим в массив rules в этом же файле следующие строку:

"semi": [2, "never"],"quotes": [2, "single", { "avoidEscape": true }]

Установка и настройка "правильного" Vuex

npm install vuex-smart-module

Почитать про все библиотеки для типизации Vuex рекомендую тут, возможно другие варианты подойдут вашему проекту больше. Но я выбрал этот модуль, так как он:

  1. От автора vue-property-decorator, который ставится по умолчанию для class-style components;

  2. Максимально близок к обычной версии стора.

Идем src/main.ts и убираем store оттуда. Для типизации нам не нужно определение this.$store на прототипе, мы будем его импортировать.

Создаем в папке store директорию modules и в ней папку habrModule, в ней файлы: index.ts, actions.ts, getters.ts, mutations.ts, state.ts.

Папка должна выглядеть так, разнесение на модули - важный принцип декомпозиции проекта и поможет вам при увеличении объема кода проекта. (с) Ваш капитан

(!) Также я не использую в корне стора никаких стейтов и геттеров, если это понадобится - попробуйте придумать модуль для этого, например appSettings

Файл src/store/modules/habrModule/state.ts:

export default class HabrState {  value = 'hello';}

Файл src/store/modules/habrModule/getters.ts:

import { Getters } from 'vuex-smart-module'import HabrState from './state'export default class HabrGetters extends Getters<HabrState> {  /**   * Параметризированный greeting, не кэшируется Vuex   * @param name    * @example module.getters.greeting("Habr!")   */  greeting(name: string): string {    return this.state.value + ', ' + name  }  /**   * Не параметризированный greeting, кэшируется Vuex   * @example module.getters.greetingDefault   */  get greetingDefault(): string {    return this.getters.greeting('Habr!')  }}

Файл src/store/modules/habrModule/index.ts:

import { Module } from 'vuex-smart-module'import getters from './getters'import state from './state'const habr = new Module({  state: state,  getters: getters,})export default habr

Мы получили маленький, но гордый модуль! Осталось зарегистрировать его в store

Файл src/store/index.ts

import Vue from 'vue'import Vuex from 'vuex'import { Module, createStore } from 'vuex-smart-module'import habr from './modules/habrModule'Vue.use(Vuex)const root = new Module({  modules: {    habr,  },})const store = createStore(root)export default storeexport const habrModule = habr.context(store)

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

Чтобы использовать модуль - нужно импортировать его из стора. Далее он будет типизированным.

Пример компонента
<template>  <div class="home">    <img      alt="Vue logo"      src="../assets/logo.png"    >    <HelloComponent msg="Welcome to Your Vue.js + TypeScript App" />    {{ computedTest }}  </div></template><script lang="ts">import { Component, Vue } from 'vue-property-decorator'import { habrModule } from '@/store'@Component({  name: 'HomeView',  components: {    HelloComponent: () => import('@/components/HelloComponent.vue'),  },})export default class HomeView extends Vue {  get computedTest() {    return habrModule.getters.greetingDefault  }}</script>

И подсказочки будут работать!

И подсказочки работают!И подсказочки работают!

И вроде бы почти закончили! Осталось только...

Рефакторинг

  1. Идем в папке src/views и переименовываем там файлы в HomeView.vue и AboutView.vue, затем в src/components и переименуем там файл в HelloComponent.vue. Также дописываем им name в аннотацию компонента.

  2. Идем в src/router/index.ts и делаем импорт HomeView.vue динамическим - чтобы было одинаково все и везде, это рекомендация vue style guide.

  3. Поправляем поломавшиеся импорты.

  4. Запускаем автоматический линтер через npm run lint.

  5. Довольные идем пить кофе и отдыхать.

О чем в статье ни слова

Я постарался добить качество кода до хорошего уровня, следовать большинству заповедей Vue, а также добавил немного от себя, но о некоторых вещах я не рассказал и не использовал:

  1. Component-naming - Vue имеет некоторые правила касающиеся названия компонентов, которые не отслеживаются eslint.

    1. Например компоненты, которые используются лишь раз - следует называть c префиксом The, к примеру TheNavigationComponent.vue - так бы я назвал панель навигации, которая лежала бы в корне и больше никуда не импортировалась.

    2. Мой принцип названия и разделения между views/components: если компонент импортируется только в роутер - он View, иначе - Component (с опциональным The), суффиксы позволяют выполнять другую рекомендацию - названия компонентов не должны быть из одного слова (Navigation.vue - ALERT!), потому что могут совпадать с названиями html тегов по умолчанию (текущими и будущими).

    3. Названия компонентов в темплейтах: <MyComponent /> vs <my-component /> Vue разрешает и то и другое, но я рекомендую CamelCase для удобства (например - подсвечивается большинством ide).

  2. Разбиение хранилища на модули - опционально по стайл гайдам, но я приверженец делать его всегда.

  3. Динамические импорты компонентов - это по умолчанию, всегда так делайте (это Components: () => import(path) ), webpack умный и такие импорты в 90% случаях уменьшат вам время полной загрузки страницы, а в оставшихся 10% - ничего не поменяют, так что оно того стоит. Это просто, одинаково и удобно.

  4. Всегда в компонентах прописывайте имя (даже с учетом того, что оно опционально).

  5. Старайтесь названия файлов компонентов согласовывать с названием классов (и именами внутри).

  6. Вызовы к api - ТОЛЬКО из store, об этом вам скажет любой Vue разработчик.

От всего остальное вас должен спасти eslint и голова, но style guide почитайте! :)

Конец!

Я надеюсь вам понравилось, качество кода и стайл гайды - это интересно, а также порождает продуктивные дискуссии в командах, обсуждайте такие вещи, это принесет удовлетворение и иногда поднимет самооценку! Но без негатива!

Гитхаб получившегося приложения: github

Также все это получится с небольшими доработками запустить и на Vue 3, у меня получилось, но так как я в нем не до конца еще уверен и разобрался - статья про уходящий Vue 2.

P. S.

Буду рад любому развернутому фидбеку!

Было бы вам интересно почитать нечто подобное для "идеального" тестирования Vue приложений?

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru