Septembre 2018
Volume 33, numéro 9
Cet article a fait l'objet d'une traduction automatique.
Le programmeur au travail - Comment être MEAN : Routage Angular
Par Ted Neward | Septembre 2018
.jpg "Ted Neward")
Bienvenue à nouveau, MEANers.
À ce stade, en dépit de toutes que nous avons accompli, tous les éléments essentiellement réalisés entièrement dans l’étendue d’une « page ». Bien que cela a de sens pour certaines applications à page unique (SPA), les utilisateurs d’applications Web, même les applications Web plus sophistiquées (ou les utilisateurs plus sophistiquées) suivent généralement une certains des principes du Web, telles que l’accessibilité via une URL. Autrement dit, j’ai dois-je être en mesure de « jump » à certaines parties de l’application en entrant simplement l’URL appropriée dans le navigateur, ou créez un signet une page alors que je suis sur celui-ci et ainsi de suite. La possibilité de naviguer « dans « l’application est caractérisé qui distingue l’application Web à partir de l’application de bureau ou mobile, et il est une fonctionnalité importante qui doit être pris en charge.
Dans une application Web plus ancienne et plus traditionnelle, ceci est géré par la nature même de l’ASP.NET traditionnel (ou les servlets Java ou Ruby sur Rails ou PHP ou...) application : Tout est une page Web séparée et distincte qui a fabriqué sur le serveur, puis envoyé au client pour le rendu. Au sein d’une application à page unique, toutefois, la plupart (si pas toutes) du rendu est effectué entièrement côté client et vous uniquement revenez en arrière sur le serveur lorsque vous avez besoin de données ou avez pour appeler un comportement qui doit rester mis sur le serveur (par exemple, la modification des données dans une base de données partagée ou peut-être appeler un service Web distinct masquage disparaître derrière le pare-feu sur l’utilisateur).
Par conséquent, dans la plupart des frameworks SPA, telles que Angular, un mécanisme différent est requis afin de fournir le type de « portée » ou « segmentation » fournissent des limites de la page. En bref, vous avez besoin d’un outil ou le mécanisme permettant de modifier des « pages » au sein de l’application SPA, essentiellement débarrassés de tous les composants sont en cours d’affichage et en les remplaçant par un autre ensemble de composants, afin qu’à l’utilisateur, il semble que vous avez modifié des pages, mais, sans avoir à effectuer l’aller-retour HTTP qu’accédant à une nouvelle page normalement implique. Au sein d’Angular, ce mécanisme est appelé « routage », et il est la responsabilité du routeur Angular. (Et vous, bien sûr).
Principes de base de routage
Pour mieux comprendre le fonctionnement du routage, supposons un style maître-détail standard de l’application : La première page affiche une liste d’éléments dans lequel je suis intéressé (par exemple, les haut-parleurs lors d’une conférence) par une sorte de synthèse (tel que selon le nom et prénom). Lorsqu’un utilisateur souhaite « Explorer » dans un affichage plus détaillé d’un élément unique, ils avant de cliquer sur cet élément dans la liste et je vais afficher une vue plus détaillée. En termes de Angular, cela signifie que je veux possèdent deux composants pour travailler avec : un SpeakerListComponent, pour afficher les haut-parleurs par nom et un SpeakerComponent, pour afficher les détails complets de ce conférencier. Il est procédé maître-détail relativement standard, et plus important encore, il est l’agrafage centrale un nombre incalculable d’applications d’entreprise. Naturellement, il sommes autres façons (voire plus) de la création d’une interface utilisateur de l’entreprise, mais cela sert à obtenir le point de core entre, je dois déterminer comment router à partir de la SpeakerListComponent vers un SpeakerComponent donné et passer le haut-parleur sélectionné dans alors que j’y suis.
Un emplacement naturel pour commencer le routage est avec la collection d’itinéraires eux-mêmes. Il est courant de choix de la page d’accueil de l’application à la vue « maître » (la liste des haut-parleurs), nous allons donc commencer par qui. Comme le routage est généralement quelque chose qui est à l’échelle de l’application ou au moins module à l’échelle, en général, les routes sont définies dans le fichier App.module.TS, en construisant un objet itinéraires importé du module « @angular/routing » :
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent }
];
Notez que les itinéraires essentiellement la même apparaissent tel qu’il apparaîtrait dans d’autres technologies Web, ASP.NET MVC ou même Ruby sur Rails. Itinéraires sont, fondamentalement, un mappage d’un chemin d’URL (sans la barre oblique) à un composant qui doit être affiché. Par conséquent, dans ce cas particulier, lorsqu’un utilisateur accède à « 4200/haut-parleurs, » ils serez récompensés avec la liste des intervenants lors de la conférence.
Pourquoi elles, j’ai aimerions le chemin d’accès « / » pour rediriger vers l’itinéraire « haut-parleurs », afin qu’arrivant à la « page d’accueil » serait rediriger automatiquement à la liste des intervenants, nous allons donc ajouter qui :
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent },
{ path: '', redirectTo: '/speakers', pathMatch: 'full' }
];
Bien sûr, l’autre chose qui est souvent nécessaire est une sorte de page « Désolé ! » à afficher que si l’utilisateur accède à une URL qui n’existe pas sur votre site, vous devez également un itinéraire « générique » qui affiche le PageNotFoundComponent vous avez le stagiaire des builds dans l’été :
const appRoutes: Routes = [
{ path: 'speakers', component: SpeakerlistComponent },
{ path: '', redirectTo: '/speakers', pathMatch: 'full' },
{ path: '**', component: PageNotFoundComponent }
];
Notez que l’itinéraire de caractère générique ne vraiment en aucune manière différent, outre le « ** « chemin d’accès, mais il est délibérément placé à la fin de la table d’itinéraires. Il s’agit par conception, étant donné que les itinéraires sont évaluées haut en bas, avec la première correspondance « gagnante ». Par conséquent, si l’itinéraire génériques était en haut, vous vous souhaitez toujours afficher travaillent du stagiaire summer, peu importe si l’utilisateur a navigué vers un itinéraire correct ou non.
En dernier lieu, j’ai besoin configurer un itinéraire pour afficher un haut-parleur individuel, et la manière classique pour ce faire consiste à donner à chaque intervenant un page/itinéraire qui utilise une sorte d’identificateur unique qui s’y rapportent, quelque chose comme « / haut-parleur/1 » pour le haut-parleur portant l’ID 1. Configurer cet itinéraire vous paraîtront familière à toute personne avec n’importe quel vous êtes familiarisé avec ASP.NET MVC ou Rails, là encore, car vous utilisez un paramètre de préfixe de deux-points nom comme espace réservé pour la valeur réelle passée :
const appRoutes: Routes = [
{ path: 'speaker/:id', component: SpeakerComponent },
{ path: 'speakers', component: SpeakerlistComponent },
{ path: '', redirectTo: '/speakers', pathMatch: 'full' },
{ path: '**', component: PageNotFoundComponent }
];
La seule véritable question restant sur ce sujet est la façon dont le SpeakerComponent Obtient le paramètre « id » ; C’est précisément un fascinant récit relatant.
ActivatedRoutes
Lorsque le routage entre en action et apporte un composant à l’écran, un objet ActivatedRoute contient des informations sur l’itinéraire utilisé, y compris les paramètres à l’itinéraire (tel que le « : id » utilisé précédemment). Comme la plupart des choses dans Angular, un ActivatedRoute est un objet injectable, vous pouvez donc poser pour celui-ci dans le constructeur de la SpeakerComponent savoir quels haut-parleurs à afficher, comme indiqué dans Figure 1.
Figure 1 demandant un ActivatedRoute dans le constructeur
@Component({
selector: 'app-speaker',
templateUrl: './speaker.component.html',
styleUrls: ['./speaker.component.css']
})
export class SpeakerComponent implements OnInit {
@Input() speaker : Speaker
constructor(private speakerService: SpeakerService,
private route: ActivatedRoute) {
}
ngOnInit() {
const speakerId = this.route.snapshot.params['id'];
this.speaker = this.speakerService.getSpeakerById(speakerId);
}
}
Le ActivatedRoute est fortement encapsulée dans des entités observables, qui est un peu plus que je souhaite aborder ici, donc je me contenterais dire que ce obtention d’un « instantané » de l’itinéraire est le moyen le plus simple de se procurer des paramètres passés dans ; à partir de là, je demande pour le paramètre « id » et « 1 » dans « / speaker/1 » sont retransmises à moi pour une utilisation avec le SpeakerService.
Le ActivatedRoute peut fonctionner par le biais d’un nombre de différentes parties de l’URL, par ailleurs, au cas où vous vous demandiez si l’itinéraire peut être mappé par les parties de l’URL ou fragments ou même des paramètres de requête. La réponse est Oui, le ActivatedRoute peut vous donner accès à d’autres parties de l’URL que vous souhaiterez peut-être paramétrer, et cette réponse est, bien sûr, consultez la documentation d’Angular pour tous les détails. En fait, les itinéraires peuvent réellement incorporer des données arbitraires dans le cadre de l’itinéraire et résoudre ces données juste avant l’activation de l’itinéraire, mais qui est un peu loin dans votre personnalisation de ce que j’ai la place pour aborder cette fois-ci.
Liens et les prises de routeur
Ce qui manque encore ? Deux parties : choix de l’emplacement dans l’interface utilisateur que le routeur obtient pour effectuer sa magie et la liaison entre la liste principale et les composants de détail. Les deux se produisent dans les fichiers de modèle, plutôt que le code TypeScript.
Tout d’abord, le meilleur moyen pour le routeur apparaissent est généralement à la racine de l’application elle-même. Autrement dit, le composant d’application définira plus souvent où les composants du routeur doivent apparaître. En fait, généralement le composant d’application aura « l’espace » du routeur entouré par un composant d’en-tête au-dessus de lui, un composant de pied de page en dessous, et ainsi de suite. « Espace » du routeur est défini par la balise « routeur outlet », et il est presque toujours vide, à l’intérieur est où les composants routés seront affiche, et mon app.component.html ressemblera à ceci :
<div style="text-align:center">
<h1>
Welcome to {{ title }}!
</h1>
</div>
<h2>Welcome to our conference</h2>
<router-outlet></router-outlet>
<h6>No speakers are actually going to appear, so...</h6>
Certes, le site Web de conférence peut faire avec une modernisation, mais je laisse cela pour un concepteur Web. La clé ici est que la paire de balise « routeur outlet » sera remplacée par le SpeakerlistComponent ou le SpeakerComponent, selon l’itinéraire est utilisé.
L’autre chose qui doit être effectuée consiste à placer les liens dans le SpeakerlistComponent, afin que les utilisateurs peuvent cliquer sur le nom de l’orateur et dirigés vers la page de détails. Le moyen le plus simple pour ce faire est de fournir simplement les valeurs href standard-problème balises d’ancrage dans le modèle de la SpeakerlistComponent, comme suit :
<div>
<div *ngFor="let speaker of speakers">
<a href="/speaker/{{speaker.id}}">
{{speaker.firstName}} {{speaker.lastName}}</a>
</div>
</div>
Et avec qui, nous avons une application maître-détail de base.
Pour résumer
Il est beaucoup plus pour découvrir sur le routage, il est un sujet beaucoup plus complexe que je peux couvrir entièrement ici. Par exemple, vous pouvez également spécifier un paramètre « données » (statique) arbitraire lors de la définition de la collection d’itinéraires, ce qui peut ensuite être récupérée dans l’objet de routage activé, ou vous pouvez définir ce que Angular appelle un « resolve guard, » qui peut être utilisé pour effectuer certaines (traitement comme récupérer les données pour le haut-parleur sélectionné) alors que l’interface utilisateur est toujours en cours de construction. Comme toujours, la documentation d’Angular comporte des détails de toutes les instructions pour ceux qui souhaitent en savoir plus.
Toutefois, pour l’instant, nous avons notre approche maître-détail fonctionne et il est temps pour nous de façons de partie pour le mois. Dans le prochain épisode, nous allons parler de l’utilisation de prise en charge d’Angular pour les tests automatisés pour tester ce pompage. En attendant, bon codage !
Ted Newardest un polytechnology basée à Seattle et consultant, conférencier et mentor, en train de travailler en tant que le directeur de l’ingénierie et des Relations de développeur à Smartsheet.com. Il a écrit une multitude d’articles, créés et co-écrit une dizaine d’ouvrages et participe partout dans le monde. Vous pouvez le contacter ted@tedneward.com ou lire son blog à l’adresse blogs.tedneward.com.
Je remercie l’expert technique suivant : Garvice Eakins (Smartsheet.com)