6 Best Practices & Pro Tips bij gebruik van Angular CLI

Future is now ( door Sébastien Jermer)
Disclaimer: artikel is gericht op Angular CLI-versie MINDER DAN 6.0.0 die werd uitgebracht in april 2018, alles is vrijwel nog steeds geldig, het enige dat is gewijzigd zijn standaardvlaggen van prod build, neem een ​​kijkje op officiële Angular CLI ng build documentatie.
Volg Release Butler, een twitterbot die ik heb gemaakt om u te helpen op de hoogte te blijven van releases van Angular CLI, Angular en vele populaire frontend-bibliotheken ...

Het ontwikkelen van Angular-apps met Angular CLI is een zeer plezierige ervaring! Angular team heeft ons een geweldige CLI gegeven die de meeste dingen ondersteunt die nodig zijn voor elk serieus kant-en-klaar project.

Gestandaardiseerde projectstructuur met volledige testmogelijkheden (zowel unit- als e2e-testen), codesteigers, productiekwaliteit gebouwd met ondersteuning voor het gebruik van omgevingsspecifieke configuratie. Dat is een droom die uitkomt en veel bespaarde uren bij elke nieuwe projecten. Bedankt Angular-team!

Hoewel Angular CLI vanaf het begin goed werkt, zijn er enkele mogelijke configuratieverbeteringen en best practices die we kunnen gebruiken om onze projecten nog beter te maken!

Wat gaan we leren

  1. Best practices voor architectuur met Core, Shared en luie functiemodules
  2. Aliassen gebruiken voor app- en omgevingsmappen om schonere import te ondersteunen
  3. Waarom en hoe Sass en hoekig materiaal te gebruiken
  4. Hoe een goede productie op te zetten
  5. PhantomJS vaarwel zwaaien en in plaats daarvan Headless Chrome gebruiken (testen)
  6. Hoe ons project vrij te geven met automatisch gegenereerde changelog en correcte versiebump

1. Een beetje architectuur

OK, dus we hebben ons nieuwe nieuwe project gegenereerd met Angular CLI, maar wat nu? Moeten we onze services en componenten gewoon blijven genereren in enkele willekeurige mappen. Hoe structureren we ons project?

Een goede richtlijn om te volgen is om onze applicatie op te splitsen in ten minste drie verschillende modules - Core, Shared en Feature (we zullen waarschijnlijk echter meer dan één functiemodule nodig hebben).

CoreModule

Alle services die één en slechts één instance per applicatie moeten hebben (singleton services) moeten hier worden geïmplementeerd. Een typisch voorbeeld kan een authenticatieservice of een gebruikersservice zijn. Laten we een voorbeeld bekijken van de implementatie van CoreModule.

SharedModule

Alle "domme" componenten en leidingen moeten hier worden geïmplementeerd. Deze componenten importeren en injecteren geen services van kern- of andere functies in hun constructeurs. Ze moeten alle gegevens via attributen ontvangen in de sjabloon van de component die ze gebruikt. Dit komt allemaal neer op het feit dat SharedModule niet afhankelijk is van de rest van onze applicatie.

Het is ook de perfecte plek om componenten van hoekmateriaal te importeren en opnieuw te exporteren.

Hoe projectstructuur voor te bereiden met Angular CLI

We kunnen Core- en Shared-modules genereren direct na het maken van ons nieuwe project. Op die manier zijn we vanaf het begin voorbereid op het genereren van extra componenten en services.

Voer ng genereren module kern uit. Maak vervolgens het bestand index.ts in de kernmap en exporteer de CoreModule zelf opnieuw. We zullen extra openbare diensten opnieuw exporteren die tijdens de verdere ontwikkeling in de hele applicatie beschikbaar moeten zijn.

Als dat wordt gedaan, kunnen we hetzelfde doen voor de gedeelde module.

FeatureModule

We gaan meerdere functiemodules maken voor elke onafhankelijke functie van onze applicatie. Functiemodules mogen alleen services van CoreModule importeren. Als functiemodule A service vanuit functiemodule B moet importeren, overweeg dan die service naar de kern te verplaatsen.

In sommige gevallen is er behoefte aan services die alleen door sommige functies worden gedeeld en het zou niet veel zin hebben om ze naar de kern te verplaatsen. In dat geval kunnen we speciale gedeelde functiemodules maken, zoals verderop in dit bericht wordt beschreven.
Vuistregel is om te proberen functies te maken die niet afhankelijk zijn van andere functies, alleen van services die worden geleverd door CoreModule en componenten die worden geleverd door SharedModule.

Dit houdt onze code schoon, gemakkelijk te onderhouden en uit te breiden met nieuwe functies. Het vermindert ook de inspanningen die nodig zijn voor refactoring. Indien correct gevolgd, zijn we ervan overtuigd dat wijzigingen in één functie de rest van onze applicatie niet kunnen beïnvloeden of breken.

Trage voortgang

We moeten onze functiemodules indien mogelijk lui laden. Theoretisch zou slechts één functiemodule synchroon moeten worden geladen tijdens het opstarten van de app om de eerste inhoud weer te geven. Elke andere functiemodule moet lui worden geladen nadat de gebruiker de navigatie heeft geactiveerd.

2. Aliassen voor app en omgevingen

Aliasing van onze app- en omgevingsmappen zal ons in staat stellen om schone importen te implementeren die consistent zullen zijn in onze applicatie.

Overweeg hypothetische, maar gebruikelijke situatie. We werken aan een component die zich drie mappen diep in een functie A bevindt en we willen service importeren vanuit de kern die zich twee mappen diep bevindt. Dit zou ertoe leiden dat de importverklaring er ongeveer zo uitziet als import {SomeService} uit '../../../core/subpackage1/subpackage2/some.service'.

Absoluut niet de schoonste import ooit ...

En wat nog erger is, elke keer dat we de locatie van een van die twee bestanden willen veranderen, breekt onze importverklaring. Vergelijk dat met een veel kortere import {SomeService} uit "@ app / core". Ziet er beter uit, niet?

Om aliassen te kunnen gebruiken, moeten we baseUrl en padeneigenschappen toevoegen aan ons tsconfig.json-bestand zoals dit ...

We voegen ook @env-alias toe om vanuit elke locatie in onze applicatie gemakkelijk toegang te hebben tot omgevingsvariabelen met dezelfde import {environment} uit de "@ env / environment" -instructie. Het werkt voor alle gespecificeerde omgevingen omdat het automatisch het juiste omgevingsbestand zal oplossen op basis van --env vlag doorgegeven aan ng build commando.

Met onze paden kunnen we nu omgevingen en services zoals deze importeren ...

Het is je misschien opgevallen dat we entiteiten (zoals SomeSingletonService in het bovenstaande voorbeeld) rechtstreeks vanuit de @ app / core importeren in plaats van @ app / core / some-package / some-singleton.service. Dit is mogelijk dankzij het opnieuw exporteren van elke openbare entiteit in het hoofdbestand index.ts. We maken één index.ts-bestand per pakket (map) en ze zien er ongeveer zo uit ...

In de meeste apps hoeven componenten en services van een bepaalde functiemodule meestal alleen toegang te hebben tot services van de CoreModule en componenten van SharedModule. Soms is dit misschien niet voldoende om een ​​specifieke business case op te lossen en hebben we ook een soort 'gedeelde functiemodule' nodig die functionaliteit biedt voor een beperkte subset van andere functiemodules.

In dit geval zullen we eindigen met zoiets als import {SomeService} uit '@ app / shared-feature'; Dus net als bij core, is shared-feature ook toegankelijk via @app alias.

Module afhankelijkheden volgen boomstructuur die erg lijkt op de bekende componentenboom

3. Sass gebruiken

Sass is een preprocessor voor stijlen die ondersteuning biedt voor mooie dingen zoals variabelen (hoewel CSS binnenkort ook variabelen krijgt), functies, mixins ... Noem maar op ...

Sass is ook vereist om de officiële Angular Material Components-bibliotheek effectief te gebruiken met zijn uitgebreide themamogelijkheden. Het is veilig om aan te nemen dat het gebruik van Sass de standaardkeuze is voor de meeste projecten.

Om Sass te gebruiken moeten we ons project genereren met behulp van Angular CLI ng nieuw commando met --style scss vlag. Hiermee wordt het grootste deel van de benodigde configuratie ingesteld. Een ding dat niet standaard wordt toegevoegd, is stylePreprocessorOptions met includePaths en we kunnen het zelf instellen met verplichte root-waarden "./" en optionele "./themes".

Dit helpt onze editor om geïmporteerde symbolen te vinden en verbetert de ontwikkelaarservaring met code-voltooiing van Angular Material-variabelen en hulpprogramma's.

Wanneer u Angular Material-apps een thema geeft, is het een goede gewoonte om themadefinities uit te pakken in een afzonderlijke themamap, één thema per bestand.
Volg mij op Twitter om op de hoogte te blijven van de nieuwste blogposts en interessante frontend-dingen

4. De “PROD” build

Project gegenereerd door Angular CLI wordt alleen geleverd met een zeer eenvoudig ng build-script uit de doos. Om artefacten van productiekwaliteit te genereren, moeten we zelf een beetje aanpassen.

We voegen "build: prod": "ng build --target production --build-optimizer --vendor-chunk" toe aan onze package.json-scripts.

Doelproductie

Deze is een parapluvlag die standaard codering en veel nuttige buildvlaggen mogelijk maakt. Het komt overeen met het gebruik van de volgende ...

  • --environment prod —gebruik environment.prod.ts bestand voor omgevingsvariabelen
  • --aot - schakel Ahead-of-Time compilatie in. Dit wordt een standaardinstelling in toekomstige versies van Angular CLI, maar voor nu moeten we dit handmatig inschakelen
  • - output-hashing alles - hash-inhoud van de gegenereerde bestanden en voeg hash toe aan de bestandsnaam om het cachegeheugen van de browser te vergemakkelijken (elke wijziging in de inhoud van het bestand zal resulteren in een andere hash en daarom wordt de browser gedwongen een nieuwe versie van het bestand te laden)
  • --extract-css true - pak alle css uit in een afzonderlijk stylesheet-bestand
  • --sourcemaps false - schakel het genereren van bronkaarten uit
  • --named-chunks false - schakel het gebruik van voor mensen leesbare namen uit voor chunk en gebruik in plaats daarvan getallen

Andere nuttige vlaggen

  • --build-optimizer - nieuwe functie die resulteert in kleinere bundels maar veel langere bouwtijden dus wees voorzichtig! (moet in de toekomst ook standaard worden ingeschakeld)
  • --vendor-chunk - extraheer alle leveranciers (bibliotheek) code in afzonderlijke chunk

Controleer ook officiële documenten op andere beschikbare configuratievlaggen die nuttig kunnen zijn in uw individuele project.

5. Phantom JS is dood! Lang leve Headless Chrome!

PhantomJS is een zeer bekende headless browser die defacto DE OPLOSSING was voor het uitvoeren van frontend-tests op CI-servers en veel dev-machines.

Hoewel het redelijk OK is, bleef de ondersteuning voor moderne ECMAScript-functies achter. Meer nog, het niet-standaard gedrag veroorzaakte hoofdpijn bij veel gelegenheden waarbij tests zonder problemen lokaal konden worden doorlopen, maar ze braken toch de CI-omgeving.

Gelukkig hoeven we er niet meer mee om te gaan!

Headless Chrome - De Frontend-test Renaissance is begonnen!

Zoals de officiële documentatie zegt ...

Headless Chrome wordt geleverd in Chrome 59. Het is een manier om de Chrome-browser in een headless-omgeving uit te voeren. In wezen, Chrome draaien zonder Chrome! Het brengt alle moderne webplatformfuncties van Chromium en de Blink-rendering-engine naar de opdrachtregel.
Super goed! Dus hoe kunnen we het gebruiken in ons Angular CLI-project?

We voegen de vlag --browser ChromeHeadless toe aan onze testopdracht, zodat we eindigen met "test": "ng test --browser ChromeHeadless --single-run" en "watch": "ng test --browser ChromeHeadless" in ons pakket. json scripts. Vrij eenvoudig, ha!

6. Gebruik gestandaardiseerde commit berichten & automatische changelog generator

Het is altijd geweldig om een ​​snel overzicht te hebben van de nieuwe functies en bugfixes van het project waarin we geïnteresseerd zijn.

Laten we onze gebruikers hetzelfde gemak bieden!

Handmatig een changelog schrijven zou een uiterst vervelende foutgevoelige taak zijn, dus het is het beste om dat proces in plaats daarvan te automatiseren. Er zijn veel beschikbare tools die het werk kunnen doen, maar laten we ons concentreren op de standaardversie.

Deze tool genereert en werkt automatisch het CHANGELOG.md-bestand bij met alle commits volgens de specificatie van de conventionele commits en bepaalt correct de nieuwe versie van ons project.

Conventionele commit definieert verplicht type, optioneel (scope): gevolgd door de commit-melding. Het is ook mogelijk om optionele body en footer toe te voegen, beide gescheiden door een lege regel. Laten we eens kijken hoe dat er in de praktijk uitziet door een voorbeeld van een volledige commit-melding van de bibliotheek van het ngx-model te controleren.

fix (afhankelijkheid): meerdere versies van rxj's in één project (TS90010)
BREAKING CHANGE: rxjs is nu peerDependency in plaats van afhankelijkheid
sluit # 1

Standaardversie zal de GROTE versie van het project correct stoten vanwege de aanwezigheid van het BREAKING CHANGE sleutelwoord in de commit-instantie.

De gegenereerde CHANGELOG.md ziet er dan ongeveer zo uit….

Voorbeeld van CHANGELOG.md-bestand gegenereerd door bibliotheek met standaardversie

Ziet er lief uit! Dus hoe kunnen we dit gebruiken in ons project?

We beginnen met het installeren van npm install -D standaardversie om het op te slaan in onze devDependencies en voegen "release": "standard-version" toe aan onze package.json-scripts.

We kunnen ook git push en npm publish toevoegen om het hele proces te automatiseren. In dit geval zullen we eindigen met "release": "standaardversie && git push - volg-tags origin master && npm publish".

Merk op dat we && hebben gebruikt om onze commando's aan elkaar te koppelen die platformafhankelijk zijn en alleen werken op Unix-gebaseerde systemen (dus ook op Windows met Cygwin, Gitbash of nieuw Win10-subsysteem voor Linux).

BONUS: Gebruik bronwortel (Intellij IDEA, alleen Webstorm)

Intellij IDEA vindt standaard niet altijd alle paden, wat resulteert in veel rode foutmarkeringen en ondersteuning voor kreupele code. Gelukkig is de oplossing heel eenvoudig. Selecteer gewoon de map src en markeer deze als bron voor bronnen.

Markeer de map src als bron voor bronnen

Super goed! Je bent aan het einde gekomen!

Ik hoop dat je enkele van deze tips en praktische tips nuttig vond! Steun dit artikel met uw om deze tips onder een breder publiek te verspreiden!

Een hoekig project starten? Bekijk Angular NgRx Material Starter!
Hoekige NgRx-materiaalstarter met ingebouwde best practices, thema's en nog veel meer!

Bekijk ook enkele andere interessante Angular-berichten ...

En vergeet nooit, de toekomst is rooskleurig
Uiteraard de mooie toekomst ( door Sven Scheuermeier)