Octobre 2017
Volume 32, numéro 10
Cet article a fait l'objet d'une traduction automatique.
La plage de travail programmeur - comment être moyenne : Angular et Fetch
Par Ted Neward | Octobre 2017
Bienvenue à nouveau, MEANers.
Dans mon dernier article, j’ai écrit, « un des besoins courants d’une application angulaire consiste à obtenir ou de mettre à jour des données à partir d’emplacements pas dans le navigateur, ce qui est habituellement partout. » J’ai ensuite montré de passer pour un autre plusieurs milliers de mots sans rien faire jamais réellement sur HTTP.
Pour être juste, l’objectif de cette colonne a été préparer le code pour pouvoir récupérer des données à partir d’une API HTTP en plaçant le code de la requête HTTP à l’intérieur d’un service angulaire. Étant donné que je n’avais pas examiné un service angulaire avant que le point, tout d’abord nécessaires pour travailler avec les principes fondamentaux de quoi ressemble un service angulaire et comment l’utiliser à partir de divers composants aurez peut-être besoin. Hélas, tout ce travail gauche me avec aucune place pour atteindre l’objectif réel : les données résidant dans les points de terminaison API HTTP.
Il est temps de résoudre cela. Nous allons allez extraire des données.
Haut-parleur API
Avant tout tout d’abord, j’ai besoin d’une API HTTP qui je peux atteints avec des demandes. Quelque part en qui pieux de l’ancien MSDN Magazine problèmes, il est la dernière version de l’API côté serveur que j’ai créé un an. Si vous l’Explorer réellement, vous trouverez qu'une API qui fournit des « Personnes, « pas de haut-parleurs. Incroyable comment les objectifs d’un projet peuvent « dérive » au fil du temps, non ?
Étant donné a été de ce serveur moyen simple et le fait que les seules différences entre hier et aujourd'hui serait les objets retournés, je pourrais facilement modifier le code pour transmettre des objets haut-parleur (définis dans la dernière colonne) et les deux sens. Mais ce qui signifie une opportunité finale de souligner à quelque chose d’autre côté de : la Communauté Node.js a une multitude de « infrastructures de pile moyenne », notamment Sails.js (sailsjs.com) et j’ai travaillé avec appelé bouclage (strongloop.com), entre autres. La plupart de ces infrastructures sont « intégrés à « désactiver les mêmes outils que j’ai utilisé un an (Express, MongoDB, etc.) pour construire une API HTTP côté serveur, tout en collant les choses un peu plus étroitement et peinture placage beau en haut. Ou bien, vous pouvez rassembler un point de terminaison d’API de Web ASP.NET MVC. L’implémentation côté serveur n’a d’importance tant qu’elle masque derrière HTTP.
La première chose consiste à afficher un aperçu de l’interface de l’API, les URL à utiliser, les verbes à utiliser avec les URL, les paramètres attendus et le format de la réponse JSON retourné. Étant donné qu’il s’agit d’un service très simple, il est facile d’imaginer que leur aspect, il est donc inutile d’énumérer les formellement ici. (Entrez simplement GET / haut-parleurs pour la liste complète des haut-parleurs, obtenir sur/haut-parleurs : id pour récupérer un intervenant particulière et ainsi de suite.)
SpeakerService
Si vous vous souvenez de ma dernière colonne, le module chargé de l’extraction de données a été appelé SpeakerService. Étant donné que le point d’ensemble du service est d’encapsuler immédiatement les détails de l’extraction et de stockage des haut-parleurs, vous pouvez supposer que la plupart (si pas toutes) du travail, que je vais afficher ici est contenue il.
Lorsque je laissée choses heure de la dernière, SpeakerService dessinait résultats à partir d’une constante en mémoire :
@Injectable()
export class SpeakerService {
constructor() { }
getSpeakers() : Array<Speaker> {
return SPEAKERS;
}
getSpeaker(id: number) : Speaker {
return SPEAKERS.find(speaker => speaker.id === id);
}
}
Le service finalement devra fournir des fonctionnalités de mise à jour et suppression, mais pour l’instant nous allons simplement fonctionne avec les opérations de lecture. Notez comment, dans chaque cas, la méthode « get » retourne un objet immédiat, soit le haut-parleur de lui-même, ou un tableau de haut-parleurs. Pour une opération en mémoire, il est assez raisonnable, mais pour une opération qui doit avoir lieu via la pile TCP/IP, il n’est pas. Opérations sur le réseau de temps, et forcer l’appelant d’attendre jusqu'à ce que l’opération de réseau est terminée, en supposant qu’il est toujours : place une charge excessive sur le développeur de créer le serveur frontal, parce que le serveur frontal a maintenant à une certaine manière que l’interface utilisateur reste réactive pendant que bloqué en attente de la réponse. Dans d’autres plateformes de l’interface utilisateur, la solution historiquement, pour que l’interface utilisateur à incorporer plusieurs threads, forçant le développeur de l’interface utilisateur pour prendre en compte pour l’écart. Dans Node.js, toutefois, la meilleure approche est à nouveau pas un objet réel, mais la promesse que l’une s’afficheront — par la suite. Ils sont appelés, logiquement, promesses.
Le concept de court d’une promesse est qu’il s’agit d’un espace réservé, un objet qui, à un moment donné dans le futur, contiendra le résultat souhaité. Mais, jusqu'à ce que cela se produit, l’exécution peut continuer sans le résultat réel. Fondamentalement, une promesse est un objet autour d’un rappel qui génère la valeur que vous le souhaitez, appelé un « programme de résolution ». (En fait, une promesse est encapsulée autour de deux rappels de ce type, l’autre est appelée « rejecter », dans le cas où la promesse ne peut pas répondre à ses obligations.)
Étant donné que le trafic HTTP est par définition lente, qu'il appartient me pour modéliser le service, par conséquent, au moins jusqu'à ce que vous mettez le trafic réseau. Combinaison de commutateur à promesses avec un léger retard de deux secondes pour retourner les données suffisante. Figure 1 montre le code modifié.
Figure 1, le Service avec l’espace réservé de promesse de modélisation
@Injectable()
export class SpeakerService {
constructor() { }
getSpeakers(): Promise<Array<Speaker>> {
return new Promise((resolve, reject) => {
setTimeout( () => {
resolve(SPEAKERS);
}, 2000);
});
}
getSpeaker(id: number): Promise<Speaker> {
return new Promise((resolve, reject) => {
setTimeout( () => {
resolve(SPEAKERS.find(speaker => speaker.id === id));
}, 2000);
});
}
}
Ce code simule un délai de deux secondes avant de servir des données sur le réseau, mais les développeurs qui souhaitent plus étroitement simulent des conditions de réseau peut lever une défaillance aléatoire dans la combinaison, en choisissant d’appeler rejeter une fois toutes les 20 appels ou donc.
Upvotes, etc.
Sur le côté du composant, les modèles et la logique doivent être ajustées légèrement pour accepter les promesses au lieu des données réelles. Qui s’effectue en fait le plus simple que Ceci dit, comme indiqué dans Figure 2.
Figure 2 utilisation des valeurs de l’orateur
@Component({
selector: 'app-root',
templateUrl: './app.component.html',
styleUrls: ['./app.component.css']
})
export class AppComponent {
title = 'SpeakerApp';
speaker: Speaker = new Speaker();
constructor(private speakerSvc: SpeakerService) {
this.speakerSvc.getSpeaker(1).then( (data) => {
this.speaker = data;
});
}
}
Deux principales apportée ici : Tout d’abord, le champ haut-parleur a été initialisé à une valeur vide de l’orateur, afin que lorsque angulaire évalue d’abord les modèle du composant, il est toujours un objet haut-parleur avec lequel travailler. En second lieu, le constructeur est modifié pour utiliser la promesse renvoyée en fournissant un appel de méthode puis, qui prend les données à transmettre par la promesse et rendre utiliser. Dans ce cas, cela signifie que l’enregistrement du constructeur dans le champ des haut-parleurs du composant. Le modèle reste inchangé et, si « ng service » est en cours d’exécution en arrière-plan, recharger les page de rendements quelque chose obtenir des informations. La page s’affiche, mais la partie « voix » du composant Upvote reste vide... de deux secondes. La valeur extraite s’affiche entièrement comme si par magie.
Il s’agit de la beauté d’une promesse : angulaire comprend que lorsque la valeur change, il doit restituer de nouveau cette partie du modèle DOM qui a changé et le fait automatiquement. Doux.
Haut-parleur, O haut-parleur, où les Art Thou, haut-parleur ?
Mais je suis toujours extraire des données localement. Comment ennuyeuse. Temps pour revenir à la SpeakerService, puis effectuer des appels via HTTP. Cela signifie que quelques modifications : importation HttpModule (l’équipe angulaire choisi pour sortir de « core »), faisant référence à la HttpService et rendre l’utilisation de celui-ci dans le SpeakerService. Notez que (logiquement) le HttpService utilise promesses, par conséquent, le décalage subtil dans le rend les API SpeakerService à l’aide de la HttpService assez simple, en tant que Figure 3 illustre.
Figure 3 à l’aide de la HttpService
@Injectable()
export class SpeakerService {
private speakersUrl = "http://localhost:3000/api/Speakers";
constructor(private http : Http) { }
getSpeaker(id: number): Promise<Speaker> {
return this.http.get(`${this.speakersUrl}/${id}`)
.toPromise()
.then(response => {
let raw: any = response.json();
let speaker = new Speaker();
speaker.firstName = raw.FirstName;
speaker.lastName = raw.LastName;
speaker.votes = new Upvote(raw.Votes);
speaker.id = raw.id;
return speaker;
});
}
La raison de l’appel à toPromise devient plus claire dans une partie ultérieure, lorsque je présenterai Observables. Pour l’instant, cet appel est nécessaire pour convertir l’objet retourné pour une utilisation en tant qu’une promesse. Notez que pour rendre le code dans Figure 3 fonctionne, une importation plus est nécessaire. Pour le remettre dans la pour Promise (méthode), vérifiez que vous ajoutez le code suivant en haut du fichier :
Importer ' rxjs/ajouter/opérateur/toPromise' ;
Il peut sembler étrange que la SpeakerService est « transformer » l’objet JSON retourné à partir de l’API en un objet local de l’orateur, mais il s’agit en fait une tâche assez courante. Le JSON publié par une API n’est pas souvent assez droite « forme » pour une utilisation par l’interface utilisateur, et par conséquent, il doit être envoyés dans le concept local des éléments que le type doit ressembler. Dans ce cas particulier, je suis en supposant que le service renvoie les haut-parleurs avec un champ en majuscules des noms (inhabituel moins que vous ne le pensez) et étape supplémentaire pour transformer le champ « Voix » dans un objet Upvote. Alors que certains systèmes « pile complète » essaiera il dans la mesure est une définition de schéma qui peut être partagée entre le client et le serveur, il est généralement plus sûr de supposer qu’il n’est pas et « ajustement » pour les données reçues pour la transformer en quelque chose de l’interface utilisateur recherche la plus aisée.
Dans certains cas, ce « réglage » se compose de quitter une certaine quantité de données sur le sol, ou « aplatissement » pour faciliter son utilisation, ou une autre transformation. Par exemple, si le serveur envoie les objets de « Haut-parleur » et « communiquer » avec retour distincts, le Service de l’orateur souhaitera peut-être « aplatir » que dans le seul objet haut-parleur que j’utilise, collecte toutes les voix pour chaque conversation dans le répertoire du présentateur en une seule valeur scalaire.
Continuez et enregistrer. En supposant que vous avez un serveur en cours d’exécution sur localhost sur le port 3000, vous devez voir tous les éléments de travail comme il le faisait avant du retourner à l’aide de HTTP. (Si vous n’avez pas un serveur en cours d’exécution sur localhost, n’hésitez pas à modifier l’URL dans le SpeakerService à http://msdn-mean.azurewebsites.net/, c'est-à-dire où j’ai stationné l’API haut-parleur qui vient d’être remis. Hésitez pas à parcourir l’ensemble complet des points de terminaison API à l’aide de la « / explorer « adresse URL, si vous le souhaitez, qui est une interface utilisateur généré par Swagger, qui vient en dehors de la zone lorsque vous travaillez avec une boucle.)
Synthèse
HttpModule (et son objet de service correspondant, HTTP) a certainement de prise en charge de place et les publications et tous les autres adéquation HTTP offre, mais celles seront traités une fois que j’ai ajouté la possibilité de modifier et ajouter de nouveaux haut-parleurs dans l’application angulaire. Dans notre exemple, nous devons développer ce frontal un peu plus, en affichant une liste de tous les haut-parleurs et puis permettant à l’utilisateur Explorer une valeur spécifique, l’approche « maître / détail » classique qui utilisent de nombreuses applications (et les abus). Pour ce faire, je dois parler comment angulaire gère le « routage » (pour déplacer entre les composants, comme s’ils étaient des « pages » dans l’application) et « forms » (permettant d’effectuer la saisie de données). Mais tout ce qui se trouve en attente pour la prochaine fois. Entre-temps... bon codage !
Ted Newardest consultant de polytechnology de basée à Seattle, haut-parleur et un responsable, chargée en tant que le directeur des Relations de développeur à Smartsheet.com. Il a écrit une multitude d’articles, créés et coauteur une dizaine d’ouvrages et fonctionne dans le monde entier. Contacter à l’adresse ted@tedneward.com ou lire son blog à adresse blogs.tedneward.com.
Grâce à l’expert technique ayant révisé cet article : James Bender