6 beste fremgangsmåter og pro-tips når du bruker Angular CLI

Future is now ( av Sébastien Jermer)
Ansvarsfraskrivelse: Artikkelen er fokusert på Angular CLI-versjonen MINDRE enn 6.0.0 som ble utgitt i april 2018, alt er ganske mye fortsatt gyldig, det eneste som endret er standardflagg for prod build, ta en titt på offisielle Angular CLI ng build dokumentasjon.
Følg Release Butler, en twitter-bot jeg opprettet for å hjelpe deg å holde deg oppdatert med utgivelser av Angular CLI, Angular og mange populære frontend-biblioteker ...

Å utvikle Angular-apper med Angular CLI er en veldig hyggelig opplevelse! Angular team ga oss fantastiske CLI som støtter det meste av det som trengs for et seriøst prosjekt ut av boksen.

Standardisert prosjektstruktur med fulle testfunksjoner (både enhets- og e2e-testing), kodestillas, produksjonskvalitetsbygging med støtte for bruk av miljøspesifikk konfigurasjon. Det er en drøm som går i oppfyllelse og mange lagrede timer på alle nye prosjekter. Takk Angular team!

Mens Angular CLI fungerer bra fra start, er det noen potensielle konfigurasjonsforbedringer og beste fremgangsmåter vi kan bruke for å gjøre prosjektene våre enda bedre!

Hva skal vi lære

  1. Beste praksis for arkitektur med Core-, Shared- og latelastede Feature-moduler
  2. Bruke aliaser for app- og miljømapper for å støtte renere import
  3. Hvorfor og hvordan du bruker Sass og kantete materialer
  4. Slik konfigurerer du god produksjonsoppbygging
  5. Hvordan vinke PhantomJS farvel og bruke Headless Chrome i stedet (testing)
  6. Slik frigjør vi prosjektet med automatisk generert changelog og riktig versjonsstump

1. Litt arkitektur

OK, så vi genererte vårt nye ferske prosjekt ved å bruke Angular CLI, men hva nå? Bør vi bare fortsette å generere våre tjenester og komponenter i noen tilfeldige mapper. Hvordan strukturerer vi prosjektet vårt?

En god retningslinje å følge er å dele opp applikasjonen vår i minst tre forskjellige moduler - Core, Shared and Feature (vi trenger trolig mer enn en funksjonsmodul skjønt).

CoreModule

Alle tjenester som må ha én og bare én forekomst per applikasjon (singleton services) bør implementeres her. Typisk eksempel kan være autentiseringstjeneste eller brukertjeneste. La oss se på et eksempel på implementering av CoreModule.

SharedModule

Alle de "stumme" komponentene og rørene bør implementeres her. Disse komponentene importerer og injiserer ikke tjenester fra kjerne eller andre funksjoner i konstruktørene sine. De skal motta alle data om attributter i malen til komponenten som bruker dem. Alt oppsummerer det faktum at SharedModule ikke har noen avhengighet av resten av applikasjonen vår.

Det er også det perfekte stedet å importere og eksportere komponenter fra Angular Material.

Hvordan forberede prosjektstruktur ved bruk av Angular CLI

Vi kan generere Core- og Shared-moduler rett etter opprettelsen av vårt nye prosjekt. På den måten vil vi være forberedt på generering av tilleggskomponenter og tjenester helt fra starten.

Kjør ng generere modulkjerne. Deretter oppretter du index.ts-filen i kjernemappen og eksporterer selve CoreModule. Vi vil eksportere ytterligere offentlige tjenester som bør være tilgjengelige i hele applikasjonen under videreutvikling.

Når vi gjør det, kan vi gjøre det samme for delt modul.

FeatureModule

Vi skal lage flere funksjonsmoduler for hver uavhengig funksjon i applikasjonen vår. Funksjonsmoduler skal bare importere tjenester fra CoreModule. Hvis funksjonsmodul A trenger å importere tjenester fra funksjonsmodul B, bør du vurdere å flytte denne tjenesten til kjernen.

I noen tilfeller er det behov for tjenester som bare deles av noen funksjoner, og det vil ikke være mye fornuftig å flytte dem til kjernen. I så fall kan vi lage spesielle delte funksjonsmoduler som beskrevet senere i dette innlegget.
Tommelfingerregel er å prøve å lage funksjoner som ikke avhenger av andre funksjoner bare på tjenester levert av CoreModule og komponenter levert av SharedModule.

Dette vil holde koden vår ren, enkel å vedlikeholde og utvide med nye funksjoner. Det reduserer også innsatsen som trengs for refactoring. Hvis det følges riktig, vil vi være sikre på at endringer i en funksjon ikke kan påvirke eller ødelegge resten av applikasjonen vår.

LazyLoading

Vi bør lat laste inn funksjonsmodulene våre når det er mulig. Teoretisk sett skal bare én funksjonsmodul lastes synkront under oppstart av appen for å vise det første innholdet. Hver annen funksjonsmodul bør lastes lat etter at brukeren har utløst navigasjon.

2. Aliaser for app og miljøer

Hvis vi kaster apper og miljøer, kan vi implementere ren import som vil være konsekvent gjennom hele applikasjonen.

Vurder hypotetisk, men vanlig situasjon. Vi jobber med en komponent som er plassert tre mapper dypt i en funksjon A og vi ønsker å importere tjenester fra kjernen som ligger to mapper dypt. Dette vil føre til at importuttalelse ser ut som import {SomeService} fra '../../../core/subpackage1/subpackage2/some.service'.

Definitivt ikke den reneste importen noensinne ...

Og det som er enda verre, når som helst vi ønsker å endre plassering av en av disse to filene, vil importoppgaven vår bryte. Sammenlign det med mye kortere import {SomeService} fra "@ app / core". Ser bedre ut, ikke sant?

For å kunne bruke aliaser, må vi legge til baseUrl- og banegenskaper til tsconfig.json-filen som denne ...

Vi legger også til @env alias for å enkelt kunne få tilgang til miljøvariabler fra hvor som helst i applikasjonen vår ved å bruke samme import {miljø} fra uttalelsen "@ env / miljø". Det vil fungere for alle spesifiserte miljøer fordi det automatisk vil løse riktig miljøfil basert på - env ​​flagg som er sendt til ng build kommando.

Med banene våre på plass kan vi nå importere miljø og tjenester som dette ...

Du har kanskje lagt merke til at vi importerer enheter (som SomeSingletonService i eksemplet ovenfor) direkte fra @ app / core i stedet for @ app / core / some-package / some-singleton.service. Dette er mulig takket være å eksportere alle offentlige enheter i hovedindeksen.ts-filen. Vi lager en index.ts-fil per pakke (mappe), og de ser noe slik ut ...

I de fleste apper vil komponenter og tjenester for en bestemt funksjonsmodul vanligvis bare ha tilgang til tjenester fra CoreModule og komponenter fra SharedModule. Noen ganger kan dette ikke være nok til å løse spesielle forretningssaker, og vi vil også trenge en slags "delt funksjonsmodul" som gir funksjonalitet for et begrenset undersett av andre funksjonsmoduler.

I dette tilfellet vil vi ende opp med noe som import {SomeService} fra '@ app / shared-feature'; Så på samme måte som kjernen, får du tilgang til delt funksjon også ved å bruke @app alias.

Modulavhengigheter følger trestruktur som ligner veldig på det velkjente komponenttreet

3. Bruke Sass

Sass er en preprocessor for stiler som gir støtte for fancy ting som variabler (selv om css vil få variabler snart også), funksjoner, mixins ... Du heter det ...

Sass er også pålagt å effektivt bruke offisielle Angular Material Components-bibliotek med dets omfattende temafunksjoner. Det er trygt å anta at bruk av Sass det er standardvalget for de fleste prosjekter.

For å bruke Sass må vi generere vårt prosjekt ved å bruke Angular CLI ng ny kommando med --style scss flagg. Dette setter opp det meste av den nødvendige konfigurasjonen. En ting som ikke er lagt til som standard er stylePreprocessorOptions med includePaths, og vi kan sette det opp selv med obligatorisk root "./" og valgfri "./themes" verdier.

Dette hjelper redaktøren vår med å finne importerte symboler og forbedrer utvikleropplevelsen med kodefylling av Angular Material-variabler og verktøyfunksjoner.

Når du angir apper med Angular Material, er det en god praksis å trekke ut temadefinisjoner i en egen temamappe, ett tema per fil.
Følg meg på Twitter for å bli varslet om de nyeste blogginnleggene og interessante frontend-ting

4. "PROD" -bygget

Prosjekt generert av Angular CLI kommer bare med et veldig enkelt ng build-skript ut av boksen. For å generere gjenstander av produksjonsgrad må vi gjøre litt tilpassing selv.

Vi legger til "build: prod": "ng build - målproduksjon - build-optimizer --vendor-chunk" til pakke.json-skriptene våre.

Målproduksjon

Denne er et paraplyflagg som muliggjør kodeminifisering og mange nyttige bygge-flagg som standard. Det tilsvarer å bruke følgende ...

  • - miljøprodukt - bruk miljø.prod.ts-fil for miljøvariabler
  • --ot - muliggjøre kompilering foran tid. Dette vil bli en standardinnstilling i fremtidige versjoner av Angular CLI, men for nå må vi aktivere dette manuelt
  • --output-hashing alt - hashinnholdet i de genererte filene og legg hasj til filnavnet for å lette hurtigbufring av nettleseren (enhver endring i filinnholdet vil føre til forskjellig hasj, og nettleseren blir derfor tvunget til å laste inn en ny versjon av filen)
  • --extract-css true - trekke ut alle cssene i egen stilark
  • - Sourcemaps falsk - deaktiver generasjon av kildekart
  • - navngitte biter falske - deaktiver ved bruk av menneskelige lesbare navn på biter og bruk tall i stedet

Andre nyttige flagg

  • - build-optimizer - ny funksjon som resulterer i mindre bunter, men mye lengre byggetider, så bruk med forsiktighet! (bør også være aktivert som standard i fremtiden)
  • --vendor-chunk - trekke ut alle leverandørkoder (bibliotek) i egen del

Sjekk også offisielle dokumenter for andre tilgjengelige konfigurasjonsflagg som kan være nyttige i ditt individuelle prosjekt.

5. Phantom JS er død! Lenge leve hodeløst Chrome!

PhantomJS er en veldig kjent hodeløs nettleser som var defacto THE SOLUTION for å kjøre frontend-tester på CI-servere og mange dev-maskiner.

Selv om det var ganske OK, ble støtten til moderne ECMAScript-funksjoner hengende. Mer er det at det ikke-standard oppførsel forårsaket hodepine ved mange anledninger når tester passerte lokalt uten problem, men de brøt fortsatt CI-miljøet.

Heldigvis trenger vi ikke å takle det lenger!

Headless Chrome - Frontend testing Renaissance har begynt!

Som den offisielle dokumentasjonen sier ...

Hodeløs Chrome leveres i Chrome 59. Det er en måte å kjøre Chrome-nettleseren i et hodeløst miljø. I hovedsak kjører du Chrome uten krom! Den bringer alle moderne nettplattformfunksjoner levert av Chromium og Blink-rendering-motoren til kommandolinjen.
Flott! Så hvordan kan vi bruke det i vårt Angular CLI-prosjekt?

Vi legger til --browser ChromeHeadless flagg til testkommandoen vår, så vi ender opp med "test": "ng test --browser ChromeHeadless --single-run" og "watch": "ng test --browser ChromeHeadless" i pakken vår. json-manus. Ganske enkelt, ha!

6. Bruk standardiserte engasjementsmeldinger og automatisk changelog-generator

Det er alltid bra å ha en rask oversikt over hva som er de nye funksjonene og feilrettingene til prosjektet vi er interessert i.

La oss gi våre brukere samme bekvemmelighet!

Å skrive changelog manuelt ville være ekstremt kjedelig feilutsatt oppgave, så det er best å automatisere prosessen i stedet. Det er mange tilgjengelige verktøy som kan gjøre jobben, men la oss fokusere på standardversjonen.

Dette verktøyet genererer og oppdaterer automatisk CHANGELOG.md-fil med alle forpliktelser etter spesifikasjon av konvensjonelle forpliktelser og bestemmer riktig versjon av prosjektet vårt på riktig måte.

Konvensjonell forpliktelse definerer obligatorisk type, valgfri (omfang): etterfulgt av forpliktelsesmeldingen. Det er også mulig å legge til valgfri kropp og bunntekst, begge atskilt med en blank linje. La oss se hvordan ser det ut i praksis ved å sjekke et eksempel på fullstendig engasjementsmelding til ngx-modellbiblioteket.

fix (avhengighet): flere versjoner av rxjs i ett prosjekt (TS90010)
BREAKING CHANGE: rxjs er nå peer-avhengighet i stedet for avhengighet
stenger nr. 1

Standardversjonen vil riktig støte den store versjonen av prosjektet på grunn av tilstedeværelsen av BREAKING CHANGE søkeord i forpliktelsesorganet.

Den genererte CHANGELOG.md vil da se slik ut ....

Eksempel på CHANGELOG.md-fil generert av standardversjonsbibliotek

Ser søt ut! Så hvordan kan vi bruke dette i prosjektet vårt?

Vi starter med å installere npm install -D standard-versjon for å lagre den i våre avhengigheter og legge til "release": "standard-versjon" til package.json-skriptene våre.

Vi kan også legge til git push og npm publish for å automatisere hele prosessen. I dette tilfellet vil vi ende opp med "release": "standardversjon & & git push - follow-tags origin master && npm publish".

Merk at vi brukte && til å lenke kommandoene våre som er plattformavhengig og fungerer bare på Unix-baserte systemer (så også på Windows med Cygwin, Gitbash eller nytt Win10-undersystem for Linux).

BONUS: Bruk ressursrot (Intellij IDEA, bare webstorm)

Intellij IDEA vil ikke alltid finne alle stiene som standard, noe som vil resultere i mange røde feilmerker og støtte for forkrøplet kode. Heldigvis er løsningen veldig enkel. Bare velg src-mappen og merk den som en kilderot.

Merk src-mappen som Sources Root

Flott! Du klarte det til slutt!

Jeg håper du fant noen av disse tipsene og beste fremgangsmåtene nyttige! Støtt denne artikkelen med for å spre disse tipsene til et bredere publikum!

Starter du et vinkelprosjekt? Sjekk Angular NgRx Material Starter!
Angular NgRx Material Starter med innebygd beste praksis, tema og mye mer!

Ta også en titt på andre interessante kantete innlegg ...

Og glem aldri, fremtiden er lys
Åpenbart den lyse fremtiden ( av Sven Scheuermeier)