een van de dingen die werd geïntroduceerd in Angular 6 was de mogelijkheid om bibliotheken te maken en te bouwen met de Angular CLI.

toen ik deze functie voor het eerst gebruikte was ik blij met hoe eenvoudig het was, want hoewel het technisch mogelijk was om bibliotheken te maken met eerdere versies van Angular, was het een totaal frustrerende en droevige ervaring.

In dit artikel laat ik u de belangrijkste elementen zien van het ontwikkelen van Hoekbibliotheken:

  • veelvoorkomende use cases voor Hoekbibliotheken.
  • een bibliotheek maken met behulp van De hoekige CLI.
  • snellere ontwikkeling van hoekige bibliotheken met NPM link.
  • uw bibliotheek publiceren.

de volledige demo code voor de bibliotheek die we aanmaken is hier te vinden.

Use cases for Angular libraries

uit mijn ervaring zijn er 2 veelvoorkomende use cases voor Angular libraries:

  1. bouwen van een herbruikbare componentbibliotheek voor het delen tussen applicaties.
  2. functionaliteit voor Shared service layer opbouwen-bijv. een client voor het werken met een externe gegevensbron zoals een API.

hoewel er veel gevallen zijn waarin een hoekige bibliotheek een goede pasvorm is voor een project, is het de moeite waard om te overwegen of uw use case Een van deze is, omdat het enige onderhoud overhead introduceert. Vergeet niet dat u altijd functionaliteit kunt schrijven als onderdeel van een gedeelde hoekmodule binnen uw applicatie en deze indien nodig in een bibliotheek kunt uitpakken.

een Hoekbibliotheekproject aanmaken

We zullen een Hoekbibliotheek maken, evenals een demo-toepassing om deze bibliotheek te gebruiken. We kunnen deze maken met de volgende commando ‘ s:

ng new example-component-library --create-application=falsecd example-component-libraryng generate library example-component-libraryng generate application example-component-library-app

het gebruik van de --create-application=false voorkomt dat Angular een toepassing maakt met de naam ‘example-component-library’, wat de naam is die we aan de bibliotheek zelf willen geven en niet de testtoepassing, zoals hier wordt uitgelegd.

als we nu in de werkruimte kijken die we zojuist hebben gemaakt, kunnen we zien dat er een projects map is die een submap bevat voor elk van de bibliotheek (voorbeeld-component-library) en de toepassing (voorbeeld-component-library-app) die we zojuist hebben gegenereerd. Er is ook een derde map met een E2E test project, die we kunnen negeren.

laten we nu onze bibliotheek bouwen en zien wat er gebeurt:

ng build --project=example-component-library

als we in de dist-map kijken, zullen we zien dat onze bibliotheek is gebouwd en dat we binnen de build-map een aantal verschillende mappen hebben met de toepassing in verschillende moduleformaten die geschikt zijn voor verschillende gebruikers, evenals een map met TypeScript-definities.

  • bundles-UMD-moduleformaat.
  • esm5-module formaat dat voornamelijk es5 gebruikt, maar ook de import / export syntaxis van es6.
  • esm2015-moduleformaat dat gebruik maakt van es2015 / es6.
  • fesm5-afgeplatte versie van esm5.
  • fesm2015-afgeplatte versie vanpeerDependencies esm2015.
  • lib-TypeScript definities voor de bibliotheek.

Dit formaat wordt Angular Package Format genoemd, en het is het formaat dat wordt gebruikt als de uitvoer van ng-packagr, het gereedschap dat Angular CLI gebruikt om bibliotheken te transpileren.

Structuring your Angular library project

De inhoud van de bibliotheek ziet er momenteel als volgt uit:

mapstructuur Initial

verwijder eerst de bestaande example-component-library module -, component-en service-bestanden-deze hebben we niet nodig.

vervolgens voegen we een component, een pipe en een directive toe. We zullen een patroon volgen van het toevoegen van één component per module-dit zal een verbruikende toepassing toestaan om alleen de modules van de bibliotheek te importeren waarin het geà nteresseerd is, en dan voor alle andere modules om boomgeschud te worden tijdens het bouwproces. Ik beveel dit te doen, want het zal echt een verschil maken voor de grootte van uw applicatie bundels als de bibliotheek groeit.

ng generate module components/foong generate component components/foong generate module pipes/barng generate pipe pipes/bar/barng generate module directives/bazng generate directive directives/baz/baz

na dit te hebben gedaan zou onze bibliotheek de volgende mapstructuur moeten hebben:

mapstructuur definitief

natuurlijk kan deze structuur worden aangepast op basis van de voorkeur van u of uw team, maar de belangrijke dingen om in gedachten te houden zijn:

  • heb één component per module om boomschudden van de ongebruikte modules/componenten.

    De uitzondering hierop zijn componenten die altijd samen gebruikt worden, moeten in dezelfde module bewaard worden – bijvoorbeeld. Als je tabs implementeerde, zouden een TabGroupComponent en TabItemComponent in dezelfde module leven.

  • probeer vatimport binnen een hoekige bibliotheek te vermijden of te beperken

    in Hoekige 6 zijn er problemen met vatimport in bibliotheken en De hoekige AOT build. Deze kwesties lijken te worden vastgesteld in Hoek 7, maar ik nog steeds regelmatig in verwarrende kwesties als gevolg van vat import en dus steun deze aanbeveling van het gebruik van slechts 1 niveau van vat import (of gewoon het vermijden van hen volledig).

vervolgens moeten we elk van de componenten die we hebben gemaakt toevoegen aan de exports van de module:

import { CommonModule } from '@angular/common';import { FooComponent } from './foo.component';import { NgModule } from '@angular/core';@NgModule({ declarations: , imports: , exports: })export class FooModule { }

we werken nu public_api.ts om alle bestanden in de bibliotheek die we willen blootstellen aan een verbruikende toepassing te exporteren:

/* * Public API Surface of example-component-library */export * from './lib/components/foo/foo.module';export * from './lib/components/foo/foo.component';export * from './lib/pipes/bar/bar.module';export * from './lib/pipes/bar/bar.pipe';export * from './lib/directives/baz/baz.module';export * from './lib/directives/baz/baz.directive';

nu hoeven we alleen nog de bibliotheek opnieuw op te bouwen, en het zal klaar zijn om de bibliotheek vanuit een toepassing te gebruiken.

ng build --project=example-component-library

het gebruik van onze hoekige bibliotheek

tijdens de ontwikkeling is de beste manier om onze bibliotheek te gebruiken het gebruik van NPM link. Hiermee kunnen we een symbolische koppeling maken van een map in de map knooppuntmodules van onze verbruikende toepassing naar de gecompileerde toepassing in de map dist van de bibliotheek.

cd dist/example-component-librarynpm link

We kunnen een Hoekprojectaan deze bibliotheek koppelen vanaf elke locatie op onze lokale machine. Vanuit de hoofdmap van het project:

npm link example-component-library

als we nu de bibliotheek uitvoeren met de watch-vlag, en tegelijkertijd ng serve in een ander terminalvenster uitvoeren.

ng build --project=example-component-libraryng serve

Dit stelt ons in staat om een toepassing en (een of meer) gekoppelde bibliotheken tegelijkertijd te ontwikkelen, en de app opnieuw te compileren met elke wijziging in de broncode van de bibliotheek.

in productie

voor productie zullen we onze bibliotheek publiceren naar npm, en deze vervolgens in de toepassing laten installeren met npm install.

eerst moet u een NPM-account aanmaken. Log nu in vanaf de opdrachtregel:

npm login

vanuit de projectmap:

cd dist/example-component-librarynpm publish

ons pakket is nu gepubliceerd op NPM (publiekelijk), en we kunnen het installeren door het toe te voegen aan de package.json afhankelijkheden en :

"dependencies": { ... "example-component-library": "~0.0.1"}

bibliotheekafhankelijkheden

als uw bibliotheek afhankelijkheden heeft, moeten deze worden opgegeven als dependencies of peerDependencies in de package.json van uw bibliotheek zelf (en niet de package.json in de root van het project). Bijvoorbeeld, in het geval van onze eenvoudige bibliotheek, hebben we alleen de volgende afhankelijkheden:

"peerDependencies": { "@angular/common": "^7.1.0", "@angular/core": "^7.1.0"}

hoek wordt opgegeven als een peerDependency in plaats van een dependency om te voorkomen dat de verbruikende toepassing meerdere, conflicterende versies van Hoek installeert. Dit artikel bevat goede informatie over peerDependencies en wanneer deze gebruikt moeten worden.

conclusie

we hebben gezien hoe we een bibliotheek met Hoekcomponenten kunnen maken die kan worden gebruikt door meerdere verschillende Hoekapplicaties, evenals hoe we kunnen werken met bibliotheken in ontwikkeling en ze kunnen publiceren voor productie. Hieronder heb ik een lijst van de middelen die ik nuttig heb gevonden voor het leren over hoekige bibliotheken mezelf, en voor het schrijven van dit artikel.

Geef een antwoord

Het e-mailadres wordt niet gepubliceerd.