6 най-добри практики и съвети при използване на Angular CLI

Бъдещето е сега ( от Sébastien Jermer)
Отказ от отговорност: Статията е фокусирана върху Angular CLI версия ПО-МАЛКО ОТ 6.0.0, която беше пусната през април 2018 г., всичко е почти все още валидно, единственото нещо, което се промени, са флаговете по подразбиране на prod build, моля, погледнете официалния Angular CLI ng build документация.
Следвайте изданието Butler, бот на Twitter, който създадох, за да ви помогна да бъдете в крак с изданията на Angular CLI, Angular и много популярни библиотеки на фронтенд ...

Разработването на Angular приложения с Angular CLI е много приятно изживяване! Екип на екипа ни предостави невероятен CLI, който поддържа повечето неща, необходими за всеки сериозен проект извън кутията.

Стандартизирана структура на проекта с пълни възможности за тестване (както тестване на единици, така и e2e), кодово скеле, изграждане на производствен клас с поддръжка за използване на специфична за околната среда конфигурация. Това е сбъдната мечта и много спестени часове за всеки нов проект. Благодаря ви Angular екип!

Въпреки че Angular CLI работи чудесно от стартирането, има някои потенциални подобрения в конфигурацията и най-добри практики, които можем да използваме, за да направим нашите проекти още по-добри!

Какво ще научим

  1. Най-добри практики за архитектура с Core, Shared и мързеливо заредени Feature модули
  2. Използване на псевдоними за папки с приложения и среда за поддържане на по-чист внос
  3. Защо и как да използваме Sass и Angular Material
  4. Как да настроите доброто изграждане на продукцията
  5. Как да махнете PhantomJS довиждане и вместо това да използвате Chrome без глава (тестване)
  6. Как да освободим нашия проект с автоматично генериран журнал за промени и коректен bump на версия

1. Малко архитектура

Добре, така генерирахме новия си нов проект, използвайки Angular CLI, но какво сега? Трябва ли просто да продължим да генерираме нашите услуги и компоненти в някои случайни папки. Как да структурираме нашия проект?

Една добра насока, която трябва да следваме, е да разделим нашето приложение на поне три различни модула - Core, Shared и Feature (вероятно ще ни трябва повече от един функционален модул).

CoreModule

Всички услуги, които трябва да имат един и само един екземпляр за приложение (единични услуги), трябва да бъдат реализирани тук. Типичен пример може да бъде услуга за удостоверяване или обслужване на потребителя. Нека разгледаме пример за внедряване на CoreModule.

SharedModule

Всички "тъпи" компоненти и тръби трябва да бъдат внедрени тук. Тези компоненти не импортират и не инжектират услуги от основните или други функции в техните конструктори. Те трябва да получават всички данни, макар и атрибути в шаблона на компонента, използвайки ги. Всичко това обобщава факта, че SharedModule няма зависимост от останалата част от нашето приложение.

Освен това е идеалното място за импортиране и реекспортиране на компоненти за ъгловите материали.

Как да подготвим структурата на проекта, използвайки Angular CLI

Ние можем да генерираме Core и Shared модули веднага след създаването на нашия нов проект. По този начин ще бъдем подготвени за генериране на допълнителни компоненти и услуги още от самото начало.

Изпълнете ядрото на генериране на модул. След това създайте файл index.ts в основната папка и реекспортирайте самия CoreModule. Ще реекспортираме допълнителни обществени услуги, които трябва да бъдат налични в цялото приложение по време на по-нататъшно развитие.

Като се прави, можем да направим същото и за споделения модул.

FeatureModule

Ще създадем множество функционални модули за всяка независима функция на нашето приложение. Модулите с функции трябва да импортират услуги само от CoreModule. Ако функционалният модул A трябва да импортира услуга от функционален модул B, помислете за преместване на тази услуга в ядро.

В някои случаи има нужда от услуги, които се споделят само от някои функции и не би било много смисъл да ги премествате в ядрото. В този случай можем да създадем специални модули за споделени функции, както е описано по-долу в тази публикация.
Правилото на палеца е да се опитате да създадете функции, които не зависят от други функции, само от услуги, предоставяни от CoreModule, и компоненти, предоставени от SharedModule.

Това ще поддържа нашия код чист, лесен за поддръжка и разширяване с нови функции. Освен това намалява усилията, необходими за рефакторинг. Ако го следваме правилно, ще сме сигурни, че промените в една функция не могат да засегнат или да разрушат останалата част от нашето приложение.

LazyLoading

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

2. Псевдоними за приложение и среда

Изплащането на нашите папки за приложения и среда ще ни позволи да реализираме чист внос, който ще бъде последователен в цялото ни приложение.

Помислете за хипотетична, но обичайна ситуация. Работим върху компонент, който е разположен три папки дълбоко във функция A и искаме да импортираме услуга от ядрото, което е разположено в две папки. Това ще доведе до импортиране на декларация, изглеждаща като import {SomeService} от '../../../core/subpackage1/subpackage2/some.service'.

Определено не е най-чистият внос някога ...

И което е още по-лошо, всеки път, когато искаме да променим местоположението на който и да е от тези два файла, нашият декларация за внос ще се счупи. Сравнете това с много по-кратък импорт {SomeService} от „@ app / core“. Изглежда по-добре, нали?

За да можем да използваме псевдоними, ние трябва да добавим свойствата baseUrl и paths към нашия файл tsconfig.json като този…

Освен това добавяме псевдоним @env, за да можем лесно да имаме достъп до променливите на средата от всяко място в нашето приложение, използвайки същия import {Environment} от оператора "@ env / Environment". Той ще работи за всички посочени среди, тъй като автоматично ще разреши правилния файл на средата въз основа на --env флаг, предаден на ng build команда.

С нашите пътища вече можем да импортираме среда и услуги като тази ...

Може би сте забелязали, че внасяме субекти (като SomeSingletonService в примера по-горе) директно от @ app / core вместо @ app / core / some-package / some-singleton.service. Това е възможно благодарение на реекспортирането на всяко публично образувание в основния файл index.ts. Създаваме един файл index.ts на пакет (папка) и те изглеждат така ...

В повечето приложения компонентите и услугите на конкретен функционален модул обикновено трябва да имат достъп само до услугите от CoreModule и компоненти от SharedModule. Понякога това може да не е достатъчно за решаване на конкретен бизнес случай и ние също ще се нуждаем от някакъв „модул за споделена функция“, който предоставя функционалност за ограничен подмножество от други модули за функции.

В този случай ще завършим с нещо като импортиране {SomeService} от „@ app / shared-feature“; Така подобно на ядрото, достъпът до споделената функция също се осъществява чрез псевдоним @app.

Модулните зависимости следват дървовидната структура, която изглежда много подобна на добре познатото дърво на компоненти

3. Използване на Sass

Sass е препроцесор на стилове, който предлага поддръжка за фантазии като променливи (въпреки че css скоро ще получи и променливи), функции, комбинации ... Наименувате го ...

Sass също е необходим за ефективно използване на официалната библиотека за компоненти на Angular Material Components с широките си възможности за тематизиране. Сигурно е да се предположи, че използването на Sass е изборът по подразбиране за повечето проекти.

За да използваме Sass, ние трябва да генерираме нашия проект, използвайки Angular CLI ng команда с --style scss flag. Това настройва повечето от необходимата конфигурация. Едно нещо, което не е добавено по подразбиране, е stylePreprocessorOptions с includePaths и можем да го настроим сами със задължителни коренни стойности „./“ и по избор „./themes“.

Това помага на нашия редактор да намери импортирани символи и подобрява опита на разработчиците с попълването на кода на променливи Angular Material и полезни функции.

Когато тематизирате приложения за ъглови материали, е добра практика да извличате определенията на темите в отделна папка с теми, по една тема на файл.
Следвайте ме в Twitter, за да получавате известия за най-новите публикации в блога и интересни неща във фронта

4. Сградата „PROD“

Проектът генериран от Angular CLI идва само с много прост скрипт за изграждане на кутии извън кутията. За да генерираме артефакти от производствен клас, трябва сами да направим малко персонализиране.

Към нашите скриптове package.json добавяме „build: prod“: „ng build - target target production --build-optimizer --vendor-chunk“.

Целево производство

Този флаг е чадър, който дава възможност за промяна на кода и много полезни флагчета за изграждане по подразбиране. Това е еквивалентно на използването на следното…

  • --environment prod - използвайте Environment.prod.ts файл за променливи на околната среда
  • --aot - разрешава компилация преди време. Това ще стане настройка по подразбиране в бъдещите версии на Angular CLI, но засега трябва да активираме това ръчно
  • - изход-хеширане на всички - хеш съдържание на генерираните файлове и добавяне на хеш към името на файла, за да се улесни busting cache на браузъра (всяка промяна в съдържанието на файл ще доведе до различен хеш и следователно браузърът е принуден да зареди нова версия на файла)
  • --extract-css true - извлечете всички css в отделен файл със стилов лист
  • --sourcemaps false - забранява генерирането на изходни карти
  • --named-chunks false - деактивирайте използването на човешки четими имена за парче и вместо това използвайте числа

Други полезни знамена

  • - build-optimizer - нова функция, която води до по-малки пакети, но много по-дълги времена на изграждане, така че използвайте с повишено внимание! (също трябва да бъде активирано по подразбиране в бъдеще)
  • --vendor-chunk - извлечете целия код на доставчик (библиотека) в отделен парче

Също така проверете официалните документи за други налични флагове за конфигурация, които могат да бъдат полезни във вашия индивидуален проект.

5. Phantom JS е мъртъв! Живейте безглав хром!

PhantomJS е много известен безглав браузър, който беше по подразбиране РЕШЕНИЕТО за провеждане на тестове за интерфейс на CI сървъри и много машини за разработка.

Макар и да е добре, поддръжката на модерните функции на ECMAScript изостава. Нещо повече, това нестандартно поведение причинява главоболие в много случаи, когато тестовете минават локално без проблем, но въпреки това нарушават CI средата.

За щастие, не е нужно да се занимаваме вече с това!

Хром без глава - Тестът на Frontend Ренесанс започна!

Както се казва в официалната документация ...

Chrome без глава се доставя в Chrome 59. Това е начин да стартирате браузъра Chrome в среда без глава. По същество работи Chrome без хром! Той носи всички съвременни функции на уеб платформата, предоставени от Chromium и механизма за изобразяване на Blink в командния ред.
Страхотен! И така, как можем да го използваме в нашия проект Angular CLI?

Към нашата тестова команда добавяме флаг --browser ChromeHeadless, така че завършваме с „test“: „ng test --browser ChromeHeadless --single-run“ и „watch“: „ng test --browser ChromeHeadless“ в нашия пакет. json скриптове Доста просто, ха!

6. Използвайте стандартизирани съобщения за ангажиране и автоматичен генератор на смяна

Винаги е чудесно да имаме бърз преглед на това, какви са новите функции и корекции на грешки в проекта, който ни интересува.

Нека предоставим на нашите потребители същото удобство!

Писането на журнал за промени ръчно би било изключително досадна задача, предразположена към грешки, така че е най-добре вместо това да се автоматизира този процес. Има много налични инструменти, които могат да ви свършат работа, но нека се съсредоточим върху стандартната версия.

Този инструмент автоматично генерира и актуализира CHANGELOG.md файл с всички ангажименти следвайки спецификацията на Conventional Commits и правилно определя новата версия на нашия проект.

Конвенционалният ангажимент определя задължителен тип, незадължителен (обхват): последван от съобщението за ангажиране. Възможно е също да добавите незадължително тяло и долен колони, и двете разделени с празен ред. Нека да видим как изглежда това на практика, като проверим пример за съобщение за пълно ангажиране на библиотеката на ngx-модел.

fix (зависимост): множество версии на rxjs в един проект (TS90010)
BREAKING CHANGE: rxjs вече е peerDependency вместо зависимост
се затваря # 1

Стандартната версия правилно ще избие ОСНОВНА версия на проекта поради наличието на ключова дума BREAKING CHANGE в органа за ангажиране.

След това генерираният CHANGELOG.md ще изглежда нещо подобно…

Пример за CHANGELOG.md файл, генериран от библиотека със стандартна версия

Изглежда сладко! И така, как можем да използваме това в нашия проект?

Започваме с инсталирането на npm install -D стандартна версия, за да я запишем в нашите devDependitions и добавим „release“: „standard-version“ към нашите скриптове package.json.

Можем също да добавим git push и npm публикуване, за да автоматизираме целия процес. В този случай ще завършим с "release": "стандартна версия && git push - master-origin origin && npm публикуване".

Обърнете внимание, че използвахме && за веригиране на нашите команди, което зависи от платформата и работи само на базирани на Unix системи (така също и на Windows с Cygwin, Gitbash или нова подсистема Win10 за Linux).

БОНУС: Използвайте ресурсен корен (Intellij IDEA, само Webstorm)

Intellij IDEA не винаги ще намери всички пътища по подразбиране, което ще доведе до множество червени маркировки за грешки и поддръжка за попълване на кода. За щастие, решението е много просто. Просто изберете папката src и я маркирайте като корен на източници.

Маркирайте папката src като корен на източници

Страхотен! Направихте го докрай!

Надявам се да намерите някои от тези съвети и най-добри практики за полезни! Моля, подкрепете тази статия с вашия , за да разпространите тези съвети към по-широка аудитория!

Стартиране на проект Angular? Вижте ъглов стартер NgRx за материали!
Ъглов стартиращ материал за NgRx с вградени най-добри практики, тематизиране и много повече!

Също така, не се колебайте да проверите някои други интересни ъглови публикации ...

И никога не забравяйте, бъдещето е светло
Очевидно светлото бъдеще ( от Свен Шеермайер)