Směrování uživatelského rozhraní Angular a komponenty

Směrovač uživatelského rozhraní Angular pomalu integruje podporu směrování do komponent Angular. V tomto příspěvku se budeme zabývat tím, proč je to užitečné a jak to provést pomocí verzí Angular UI Router 0.x.x a 1.0.0-beta.x.

Pozadí

Se zavedením komponent Angular ve verzi 1.5 se koncept samostatné, opakovaně použitelné sady chování a pohledů stal snáze definovatelným než dříve prováděné direktivy. Mezi tyto změny patří: abstrakce oboru, explicitní vazba na kontroléry, poskytování háčků životního cyklu do kontroléru a také několik dalších věcí.

To umožnilo lépe komponovat celé pohledy a aplikace. S tím přišlo uvědomění, že webová stránka je komponenta složená z komponent.

Při tom se směrování na komponentu stalo žádoucím chováním.

Chytré vs. hloupé komponenty

Předtím, než se budeme zabývat použitím UI Routeru pro směrování na komponenty, je třeba probrat koncept chytrých a hloupých komponent.

Chytrá komponenta je taková, která si je velmi dobře vědoma API a dat řídících pohled. To znamená, že ve svém kontroléru typicky provádí volání služby při inicializaci komponenty. Ví, co je potřeba k provedení volání a jakou odpověď má od API očekávat.

Na druhé straně existují hloupé komponenty, které vědí, co mají dělat s předaným objektem nebo hodnotou a za jaké interakce jsou zodpovědné. Typicky neinteraguje s žádnými službami. Většina interakcí vede ke zpětnému volání nadřazené komponenty, která předá informace zpět nahoru, aby je mohla použít
chytrá komponenta, nebo se týká čistě změn zobrazení.

Z důvodu opakovaného použití jsou hloupé komponenty typicky nejpoužitelnější (představte si kontejnery se záhlavím, navigační lišty, výběrová pole atd.). Chytré komponenty jsou skvělé pro vytváření plnohodnotných aplikací z vysoké úrovně, ale nejsou příliš přizpůsobitelné.

Nejlepším způsobem, jak udělat z komponenty hloupou, je odstranit volání API z řadičů a najít způsob, jak tato data poskytovat prostřednictvím nějaké vazby. To je užitečné, pokud již máte stejná data, která chytrá komponenta potřebuje, ale nechcete kvůli nim provádět dva zásahy na server.

Psaní aplikace jako komponenty

S přechodem na komponentové aplikace došlo k myšlenkovému posunu souvisejícímu s tím, jak se na aplikace díváme. Na celé aplikace lze pohlížet jako na komponenty. To má skutečně praktické využití. Například pokud napíšeme aplikaci jako komponentu, můžeme vzít samostatnou webovou aplikaci a případně ji vložit do hybridního webového kontejneru a vytvořit z ní mobilní aplikaci.

Nejlepším způsobem, jak napsat aplikaci jako komponentu, je využít vnořené pohledy v uživatelském rozhraní Router. To může být někdy náročné, ale umožňuje to velkou flexibilitu při výměně komponent na základě
stavu aplikace.

Použití komponent v definici stavu pomocí šablony

První integrace s routovatelnými komponentami spočívala v tom, že místo použití vlastnosti templateUrl na definici stavu se místo toho použila vlastnost template. Příklad by vypadal takto:

Očividně to funguje, ale když je každý stav deklarován pomocí prvku HTML, který je jednoduše jediným prvkem HTML bez atributů, začíná to být únavné.

Díky tomu je veškerá logika a zobrazení související s touto komponentou izolované a opakovaně použitelné. Pokud se například rozhodnete zabalit myComponent do navigační šablony, můžete to nyní udělat, aniž byste museli generovat novou komponentu ze šablony, kdybyste takto nastavili stejný stav:

Vazba na komponenty

Jak napsat celou aplikaci jako hloupou komponentu, když mnoho našich tras potřebuje volat služby pro zobrazení informací, které chce uživatel zobrazit?

Jednou z možných odpovědí je vyřešit data potřebná pro fungování komponenty z trasy a pak je svázat do komponenty prostřednictvím vazeb komponenty. Existují dva přístupy, jak to udělat:

  1. Vytvořit inteligentní komponentu, která obaluje hloupou komponentu. Jediným účelem chytré komponenty je provést volání služby a správně se svázat s hloupou komponentou.
  2. Použít funkci resolve poskytovanou v routeru uživatelského rozhraní k přeložení dat přímo do hloupé komponenty.

U obou možností jsou zřejmé určité kompromisy. V případě obalu chytré komponenty získáte další komponentu, kterou budete muset udržovat. V případě překladu na komponentu pomocí směrovače UI se svazujete schopnostmi směrovače a je také obtížnější spravovat zpracování výjimek.

Přesto je vytváření směrovatelných komponent pomocí vazeb směrovače UI velmi jednoduché a směrovač UI je dostatečně výkonný a poskytuje skvělou funkčnost do té míry, že pokud je ve vašem projektu, pravděpodobně tam zůstane až do úplného přepsání aplikace.

Pro vazbu na komponentu ve stabilní verzi UI Routeru (0.x.x) vytvoří UI Router objekt $resolve v kontextu, který použil pro kompilaci obsahu ui-view.

Tento objekt lze použít pro vazbu na deklaraci komponenty ve vlastnosti template definice stavu.

To nám umožní odstranit závislost UserService z komponenty user. U těch inteligentních komponent, které jednoduše provedou volání služby a poté zobrazí informace, můžeme vlastně odstranit i celý řadič.

Vazba na komponenty – 1.0.0-beta.x

S vydáním [email protected] byla do objektu definice stavu přidána vlastnost component. Ta umožňuje vývojáři vázat se přímo na komponentu definovanou na modulu angular. Odpadá tak nutnost mít šablonu obsahující jediný prvek, jak jsme se s tím setkávali v minulosti.

.

Leave a Reply