Angular UI Routing and Components

Angular UI Router har långsamt integrerat stöd för routing till Angular-komponenter. I det här inlägget diskuteras varför det är användbart och hur man gör det med hjälp av både Angular UI Router 0.x.x och 1.0.0-beta.x-versionerna.

Bakgrund

Med introduktionen av Angular-komponenter i version 1.5 blev konceptet med en fristående, återanvändbar uppsättning beteenden och vyer enklare att definiera än vad som tidigare gjordes i direktiv. Dessa förändringar inkluderar: abstraktion av scope, explicit bindning till controllers, tillhandahållande av livscykelkrokar i controllern, samt några andra saker.

Detta möjliggjorde en bättre komponentisering av hela vyer och applikationer. Med det kom insikten att en webbsida är en komponent som består av komponenter.

Med det sagt blev routing till en komponent ett önskat beteende.

Smart vs Dumb Components

För att fördjupa sig i användandet av UI Router för att dirigera till komponenter bör begreppet smarta och dumma komponenter diskuteras.

En smart komponent är en komponent som är mycket medveten om API:et och data som driver en vy. Detta innebär att den i sin controller vanligtvis gör ett tjänstekall vid initialisering av komponenten. Den vet vad som krävs för att göra anropet och vilket svar den ska förvänta sig från API:et.

Å andra sidan finns det dumma komponenter som vet vad de ska göra med ett överlämnat objekt eller värde och vilka interaktioner den är ansvarig för. Den interagerar vanligtvis inte med några tjänster. De flesta interaktioner resulterar i en callback till en överordnad komponent för att skicka tillbaka information som ska användas
av en smart komponent eller är enbart relaterade till visningsändringar.

För återanvändbarhetens skull är dumma komponenter typiskt sett de mest återanvändbara (tänk på behållare med rubriker, navigeringsfält, valboxar etc.). Smarta komponenter är bra för att bygga fullständiga program från en hög nivå, men de är inte särskilt anpassningsbara.

Det bästa sättet att göra en komponent stum är att ta bort API-anropen från styrenheterna och hitta ett sätt att tillhandahålla dessa data via någon form av bindning. Detta är användbart om du redan har samma data som en smart komponent behöver, men inte vill göra två träffar till servern för den.

Skrivning av en applikation som en komponent

Med övergången till komponentbaserade applikationer skedde ett tankeskifte relaterat till hur vi ser på applikationer. Hela program kan ses som en komponent. Detta har faktiskt praktiska användningsområden. Om vi till exempel skriver vår applikation som en komponent kan vi ta en fristående webbapplikation och eventuellt placera den i en hybridwebbcontainer och göra en mobilapplikation av den.

Det bästa sättet att skriva en applikation som en komponent är att dra nytta av nested views i UI Router. Detta kan ibland vara en utmaning, men det ger stor flexibilitet när det gäller att byta ut komponenter baserat
på applikationens tillstånd.

Användning av komponenter i tillståndsdefinitionen med hjälp av mall

Den första integrationen med routabla komponenter var att, i stället för att använda en templateUrl-egenskap på tillståndsdefinitionen, använda template-egenskapen, i stället. Ett exempel på detta skulle vara som
följer:

Oppenbart fungerar detta, men när varje enskilt tillstånd deklareras med ett HTML-element som helt enkelt är ett enda HTML-element utan attribut börjar det bli tråkigt.

Givetvis är all logik och visning relaterad till den komponenten isolerad och återanvändbar. Om du till exempel bestämmer dig för att linda in myComponent i en navigeringsmall kan du nu göra det utan att behöva generera en ny komponent från en mall hade du ställt in samma tillstånd på följande sätt:

Bindning till komponenter

Hur skriver vi en hel applikation som en stum komponent, när många av våra rutter måste göra tjänsteanrop för att visa information som en användare vill visa?

Ett möjligt svar på detta är att lösa de data som krävs för att komponenten ska fungera från rutten och sedan binda in dem i komponenten via komponentens bindningar. Det finns två tillvägagångssätt för att göra detta:

1. Skapa en smart komponent som omsluter en dum komponent. Det enda syftet med den smarta komponenten är att göra ett tjänstekall och binda korrekt till den dumma komponenten.
2. Använd resolve-funktionen som tillhandahålls i UI-routern för att lösa data direkt till den dumma komponenten.

Det finns några uppenbara kompromisser med båda alternativen. Med en smart komponentomslagare har du ytterligare en komponent att underhålla. För att lösa till komponenten med hjälp av UI Router binder du dig till routerns förmåga, och det är också svårare att hantera undantagshantering.

Med detta sagt är det extremt enkelt att skapa routabla komponenter via UI Routers bindningar, och UI Router är tillräckligt kraftfull och ger bra funktionalitet till den grad att om den finns i ditt projekt kommer den troligen att stanna kvar där fram till dess att en fullständig omskrivning av en applikation görs.

För att binda till en komponent i den stabila utgåvan av UI Router (0.x.x) skapar UI Router ett $resolve-objekt i den kontext som användes för att kompilera innehållet i ui-view.

Detta kan användas för att binda till en komponentdeklaration i template-egenskapen i tillståndsdefinitionen.

Detta gör det möjligt för oss att ta bort UserService-beroendet från user-komponenten. För de smarta komponenter som helt enkelt gör ett tjänstekall och sedan visar informationen kan vi faktiskt också eliminera en hel controller.

Binda till komponenter – 1.0.0.0-beta.x

Med lanseringen av [email protected] lades component-egenskapen till i tillståndsdefinitionsobjektet. Detta gör det möjligt för utvecklaren att binda direkt till en komponent enligt definitionen i angularmodulen. Det eliminerar behovet av att ha en mall som innehåller ett enda element som vi hade sett tidigare.