Angular UI útválasztás és komponensek

Angular UI Router lassan integrálja az Angular komponensekhez való útválasztás támogatását. Ebben a bejegyzésben arról lesz szó, hogy ez miért hasznos, és hogyan lehet mind az Angular UI Router 0.x.x, mind az 1.0.0.0-beta.x verziók segítségével elvégezni.

Háttér

Az Angular komponensek bevezetésével az 1.5-ös verzióban a viselkedések és nézetek önálló, újrafelhasználható készletének koncepciója könnyebben definiálhatóvá vált, mint korábban a direktívákban. Ezek a változások a következők: a hatókör absztrahálása, a vezérlőkhöz való explicit kötődés, életciklus-horgok biztosítása a vezérlőben, valamint néhány más dolog.

Ez lehetővé tette teljes nézetek és alkalmazások jobb komponenssé tételét. Ezzel együtt jött a felismerés, hogy egy weboldal egy komponens, amely komponensekből áll.

Ezzel együtt a komponensekhez való útválasztás kívánatos viselkedéssé vált.

Okos és buta komponensek

Mielőtt belemerülnénk az UI Router használatába a komponensekhez való útválasztáshoz, meg kell beszélnünk az intelligens és buta komponensek fogalmát.

Az intelligens komponens olyan, amely nagyon is tisztában van az API-val és a nézetet vezérlő adatokkal. Ez azt jelenti, hogy a vezérlőjében jellemzően a komponens inicializálásakor szolgáltatáshívást hajt végre. Tudja, hogy mi szükséges a híváshoz, és milyen választ kell várnia az API-tól.

A másik oldalon vannak buta komponensek, amelyek tudják, hogy mit kell tenni egy átadott objektummal vagy értékkel, és milyen interakciókért felelősek. Jellemzően nem lép kölcsönhatásba semmilyen szolgáltatással. A legtöbb interakció egy visszahívást eredményez egy szülő komponenshez, hogy az információt visszaadja egy intelligens komponens
általi felhasználásra, vagy pusztán a megjelenítési változásokhoz kapcsolódik.

Az újrafelhasználhatóság érdekében jellemzően a buta komponensek a leginkább újrafelhasználhatóak (gondoljunk a fejlécekkel, navigációs sávokkal, kiválasztó dobozokkal stb. ellátott konténerekre). Az intelligens komponensek nagyszerűek a teljes alkalmazások magas szintről történő felépítéséhez, de nem nagyon testreszabhatók.

A legjobb módja annak, hogy egy komponenst butává tegyünk, ha eltávolítjuk az API-hívásokat a vezérlőkből, és megtaláljuk a módját annak, hogy az adatokat valamilyen kötésen keresztül szolgáltassuk. Ez akkor hasznos, ha már rendelkezünk ugyanazokkal az adatokkal, amelyekre egy intelligens komponensnek szüksége van, de nem akarjuk kétszer megkeresni érte a szervert.

Az alkalmazás komponensként való megírása

A komponensalapú alkalmazások felé való elmozdulással együtt járt az elmeváltás azzal kapcsolatban, hogy hogyan tekintünk az alkalmazásokra. Teljes alkalmazások tekinthetők komponensnek. Ennek valóban vannak gyakorlati felhasználási esetei. Ha például az alkalmazásunkat komponensként írjuk meg, akkor foghatunk egy önálló webes alkalmazást, és potenciálisan egy hibrid webes konténerbe helyezhetjük, és mobilalkalmazást készíthetünk belőle.

Az alkalmazás komponensként való megírásának legjobb módja, ha kihasználjuk az UI Routerben az egymásba ágyazott nézetek előnyeit. Ez időnként kihívást jelenthet, de nagy rugalmasságot tesz lehetővé a komponensek
az alkalmazás állapota alapján történő cseréjében.

Komponensek használata az állapotdefinícióban sablon használatával

A routolható komponensek első integrációja az volt, hogy az állapotdefiníció templateUrl tulajdonsága helyett a template tulajdonságot használtuk helyette. Egy példa erre a
következő lenne:

Ez nyilvánvalóan működik, de amikor minden egyes állapotot egy olyan HTML elemmel kell deklarálni, amely egyszerűen egyetlen HTML elem, attribútumok nélkül, akkor kezd fárasztóvá válni.

Ezzel a komponenssel kapcsolatos összes logika és megjelenítés elszigetelt és újrafelhasználható. Ha például úgy döntünk, hogy a myComponent-t egy navigációs sablonba csomagoljuk, akkor ezt már megtehetjük anélkül, hogy egy sablonból új komponenst kellene generálnunk, ha ugyanazt az állapotot így állítottuk volna be:

Komponensekhez való kötődés

Hogyan írjunk egy teljes alkalmazást buta komponensként, amikor sok útvonalunknak szolgáltatáshívásokat kell végrehajtania a felhasználó által megjeleníteni kívánt információk megjelenítéséhez?

Egy lehetséges válasz erre az, hogy a komponens működéséhez szükséges adatokat az útvonalból oldjuk fel, majd a komponens kötésein keresztül kötjük be a komponensbe. Erre kétféle megközelítés létezik:

1. Készítsünk egy intelligens komponenst, amely egy buta komponenst burkol be. Az intelligens komponens egyetlen célja a szolgáltatáshívás és a megfelelő kötés a buta komponenshez.
2. Az UI routerben biztosított feloldási funkciót használja az adatok feloldásához közvetlenül a buta komponenshez.

Mindkét lehetőségnek van néhány nyilvánvaló kompromisszuma. Az intelligens komponenscsomagolással egy további komponens karbantartására van szükség. Az UI Router segítségével történő komponensfeloldás esetén az útválasztó képességéhez köti magát, és a kivételkezelés kezelése is nehezebb.

Ezzel együtt az UI Router kötésein keresztül útválasztó komponensek létrehozása rendkívül egyszerű, és az UI Router elég erős és nagyszerű funkcionalitást biztosít ahhoz, hogy ha a projektben van, akkor valószínűleg ott is marad az alkalmazás teljes újraírásáig.

Az UI Router stabil kiadásában (0.x.x) egy komponenshez való kötődéshez az UI Router létrehoz egy $resolve objektumot abban a kontextusban, amelyet a ui-view tartalmának összeállításához használt.

Az állapotdefiníció template tulajdonságában lévő komponens deklarációhoz való kötődéshez használható.

Ez lehetővé teszi számunkra, hogy eltávolítsuk a UserService függőséget a user komponensből. Azoknál az intelligens komponenseknél, amelyek egyszerűen csak egy szolgáltatáshívást végeznek, majd megjelenítik az információt, tulajdonképpen egy egész vezérlőt is kiiktathatunk.

Komponensekhez való kötődés – 1.0.0-beta.x

A [email protected] kiadásával az component tulajdonságot adtuk hozzá az állapotdefiníció objektumához. Ez lehetővé teszi a fejlesztő számára, hogy közvetlenül az angular modulban definiált komponenshez kötődjön. Ez kiküszöböli az egyetlen elemet tartalmazó sablon szükségességét, ahogyan azt korábban láthattuk.