Routage Angular UI et composants
Angular UI Router a lentement intégré le support du routage vers les composants Angular. Ce post discutera pourquoi cela est utile, et comment le faire en utilisant les deux versions Angular UI Router 0.x.x et 1.0.0-beta.x.
Background
Avec l’introduction des composants Angular dans la version 1.5, le concept d’un ensemble autonome et réutilisable de comportements et de vues est devenu plus facile à définir que ce qui était fait auparavant dans les directives. Ces changements comprennent : l’abstraction de la portée, la liaison aux contrôleurs de manière explicite, la fourniture de crochets de cycle de vie dans le contrôleur, ainsi que quelques autres choses.
Cela a permis une meilleure componentialisation de vues et d’applications entières. Avec cela est venu la réalisation qu’une page Web est un composant composé de composants.
Cela étant dit, le routage vers un composant est devenu un comportement désiré.
Smart vs Dumb Components
Avant de plonger dans l’utilisation de UI Router pour router vers des composants, le concept de composants intelligents et muets doit être discuté.
Un composant intelligent est un composant qui est très conscient de l’API et des données conduisant une vue. Cela signifie que dans son contrôleur, il fait généralement un appel de service lors de l’initialisation du composant. Il sait ce qui est nécessaire pour faire l’appel et la réponse qu’il doit attendre de l’API.
D’autre part, il y a des composants muets qui savent quoi faire avec un objet ou une valeur passée et quelles interactions il est responsable. Il n’interagit généralement avec aucun service. La plupart des interactions se traduisent par un rappel à un composant parent pour faire remonter des informations qui seront utilisées
par un composant intelligent ou sont liées purement aux changements d’affichage.
Pour des raisons de réutilisation, les composants muets sont typiquement les plus réutilisables (pensez aux conteneurs avec des en-têtes, des barres de navigation, des boîtes de sélection, etc). Les composants intelligents sont parfaits pour construire des applications complètes à partir d’un haut niveau, mais ils ne sont pas très personnalisables.
La meilleure façon de rendre un composant muet est de supprimer les appels API des contrôleurs et de trouver un moyen de fournir ces données via une sorte de liaison. Ceci est utile si vous avez déjà les mêmes données qu’un composant intelligent a besoin, mais que vous ne voulez pas faire deux visites au serveur pour cela.
Écrire une application comme un composant
Avec le passage aux applications à composants, il y a eu un changement d’esprit lié à la façon dont nous voyons les applications. Des applications entières peuvent être vues comme un composant. Cela a effectivement des cas d’utilisation pratiques. Par exemple, si nous écrivons notre application comme un composant, nous pouvons prendre une application web autonome et potentiellement la mettre dans un conteneur web hybride et en faire une application mobile.
La meilleure façon d’écrire une application comme un composant est de profiter des vues imbriquées dans UI Router. Cela peut être un défi, parfois, mais il permet une grande flexibilité dans le remplacement des composants basés
sur l’état de l’application.
Utilisation des composants dans la définition de l’état en utilisant Template
La première intégration avec les composants routables était de, au lieu d’utiliser une propriété templateUrl
sur la définition de l’état, était d’utiliser la propriété template
, à la place. Un exemple de ceci serait comme
suivant:
Evidemment, cela fonctionne, mais lorsque chaque état est déclaré avec un élément HTML qui est simplement un élément HTML unique sans attributs, cela commence à devenir fastidieux.
Grâce à cela, toute la logique et l’affichage liés à ce composant sont isolés et réutilisables. Si, par exemple, vous décidez d’envelopper myComponent
dans un modèle de navigation, vous pouvez maintenant le faire sans avoir à générer un nouveau composant à partir d’un modèle avait vous configurer le même état comme tel:
Binding to Components
Comment écrire une application complète comme un composant muet, alors que beaucoup de nos routes doivent faire des appels de service pour afficher les informations qu’un utilisateur veut voir ?
Une réponse possible à cela est de résoudre les données nécessaires au fonctionnement du composant à partir de la route, puis de les lier au composant via les liaisons du composant. Il existe deux approches pour faire cela :
- Créer un composant intelligent qui enveloppe un composant muet. Le seul but du composant intelligent est de faire un appel de service et de se lier correctement au composant muet.
- Utiliser la fonctionnalité de résolution fournie dans le routeur d’interface utilisateur pour résoudre les données directement au composant muet.
Il y a des compromis évidents pour les deux options. Avec un wrapper de composant intelligent, vous avez un composant supplémentaire à maintenir. Pour la résolution vers le composant en utilisant UI router, vous vous attachez à la capacité du routeur, et il est également plus difficile de gérer la gestion des exceptions.
Cela étant dit, la création de composants routables via les bindings de UI Router est extrêmement simple, et UI Router est assez puissant et fournit de grandes fonctionnalités au point que, s’il est dans votre projet, il y restera probablement jusqu’à une réécriture complète d’une application.
Pour se lier à un composant dans la version stable de UI Router (0.x.x), UI Router crée un objet $resolve
dans le contexte qu’il a utilisé pour compiler le contenu du ui-view
.
Cela peut être utilisé pour se lier à une déclaration de composant dans la propriété template
de la définition d’état.
Cela nous permet de supprimer la dépendance UserService du composant user
. Pour ces composants intelligents qui font simplement un appel de service puis affichent l’information, nous pouvons réellement éliminer un contrôleur entier, aussi bien.
Binding to Components – 1.0.0-beta.x
Avec la sortie de [email protected]
, la propriété component
a été ajoutée à l’objet de définition d’état. Cela permet au développeur de se lier directement à un composant tel que défini sur le module angulaire. Cela élimine le besoin d’avoir un modèle contenant un seul élément comme nous l’avions vu dans le passé.
Leave a Reply