Les deux Promiseset Observablesnous fournissent des abstractions qui nous aident à gérer la nature asynchrone de nos applications. La différence entre eux a été clairement mise en évidence par @ Günter et @Relu.
Puisqu'un extrait de code vaut mille mots, parcourez l'exemple ci-dessous pour les comprendre plus facilement.
Merci @Christoph Burgdorf pour cet article génial
Angular utilise Rx.js Observables au lieu de promesses pour traiter avec HTTP.
Supposons que vous créez une fonction de recherche qui devrait instantanément vous montrer les résultats que vous tapez. Cela vous semble familier, mais cette tâche comporte de nombreux défis.
- Nous ne voulons pas toucher le point de terminaison du serveur chaque fois que l'utilisateur appuie sur une touche, cela devrait l'inonder d'une tempête de
HTTPdemandes. Fondamentalement, nous ne voulons le frapper qu'une fois que l'utilisateur a arrêté de taper au lieu de chaque frappe.
- Ne frappez pas le point de terminaison de recherche avec les mêmes paramètres de requête pour les requêtes suivantes.
- Traitez les réponses en panne. Lorsque nous avons plusieurs demandes en vol en même temps, nous devons tenir compte des cas où elles reviennent dans un ordre inattendu. Imaginez que nous tapons d'abord ordinateur , arrêt, une demande sort, nous tapons voiture , arrêt, une demande sort. Nous avons maintenant deux demandes en vol. Malheureusement, la demande qui porte les résultats pour l' ordinateur revient après la demande qui porte les résultats pour la voiture .
La démo se composera simplement de deux fichiers: app.tset wikipedia-service.ts. Dans un scénario réel, nous diviserions très probablement les choses plus haut, cependant.
Vous trouverez ci-dessous une implémentation basée sur Promise qui ne gère aucun des cas de bord décrits.
wikipedia-service.ts
import { Injectable } from '@angular/core';
import { URLSearchParams, Jsonp } from '@angular/http';
@Injectable()
export class WikipediaService {
constructor(private jsonp: Jsonp) {}
search (term: string) {
var search = new URLSearchParams()
search.set('action', 'opensearch');
search.set('search', term);
search.set('format', 'json');
return this.jsonp
.get('http://en.wikipedia.org/w/api.php?callback=JSONP_CALLBACK', { search })
.toPromise()
.then((response) => response.json()[1]);
}
}
Nous injectons le Jsonpservice pour faire une GETdemande contre l'API Wikipedia avec un terme de recherche donné. Notez que nous appelons toPromisepour passer d'un Observable<Response>à un Promise<Response>. Finalement, vous vous retrouvez avec un Promise<Array<string>>comme type de retour de notre méthode de recherche.
app.ts
// check the plnkr for the full list of imports
import {...} from '...';
@Component({
selector: 'my-app',
template: `
<div>
<h2>Wikipedia Search</h2>
<input #term type="text" (keyup)="search(term.value)">
<ul>
<li *ngFor="let item of items">{{item}}</li>
</ul>
</div>
`
})
export class AppComponent {
items: Array<string>;
constructor(private wikipediaService: WikipediaService) {}
search(term) {
this.wikipediaService.search(term)
.then(items => this.items = items);
}
}
Pas beaucoup de surprise ici non plus. Nous injectons notre WikipediaServiceet exposons sa fonctionnalité via une méthode de recherche au modèle. Le modèle se lie simplement à la saisie et aux appels search(term.value).
Nous déroulons le résultat de la promesse que la méthode de recherche du WikipediaService renvoie et l'exposons comme un simple tableau de chaînes au modèle afin que nous puissions le *ngForparcourir et créer une liste pour nous.
Voir l'exemple d' implémentation basée sur Promise sur Plunker
Où les observables brillent vraiment
Modifions notre code pour ne pas marteler le point de terminaison à chaque frappe, mais envoyer une demande à la place uniquement lorsque l'utilisateur a arrêté de taper pendant 400 ms
Pour dévoiler ces super pouvoirs, nous devons d'abord obtenir un Observable<string>qui porte le terme de recherche que l'utilisateur tape. Au lieu de se lier manuellement à l'événement keyup, nous pouvons tirer parti de la formControldirective d'Angular . Pour utiliser cette directive, nous devons d'abord importer le ReactiveFormsModuledans notre module d'application.
app.ts
import { NgModule } from '@angular/core';
import { BrowserModule } from '@angular/platform-browser';
import { JsonpModule } from '@angular/http';
import { ReactiveFormsModule } from '@angular/forms';
@NgModule({
imports: [BrowserModule, JsonpModule, ReactiveFormsModule]
declarations: [AppComponent],
bootstrap: [AppComponent]
})
export class AppModule {}
Une fois importé, nous pouvons utiliser formControl à partir de notre modèle et lui attribuer le nom "term".
<input type="text" [formControl]="term"/>
Dans notre composant, nous créons une instance de FormControlfrom @angular/formet l'exposons en tant que champ sous le terme de nom sur notre composant.
Dans les coulisses, le terme expose automatiquement une Observable<string>propriété as à valueChangeslaquelle nous pouvons souscrire. Maintenant que nous avons un Observable<string>, surmonter l'entrée utilisateur est aussi simple que d'appeler debounceTime(400)notre Observable. Cela retournera une nouvelle Observable<string>qui n'émettra une nouvelle valeur que si aucune nouvelle valeur n'est venue depuis 400 ms.
export class App {
items: Array<string>;
term = new FormControl();
constructor(private wikipediaService: WikipediaService) {
this.term.valueChanges
.debounceTime(400) // wait for 400ms pause in events
.distinctUntilChanged() // ignore if next search term is same as previous
.subscribe(term => this.wikipediaService.search(term).then(items => this.items = items));
}
}
Ce serait une perte de ressources d'envoyer une autre demande de terme de recherche pour laquelle notre application affiche déjà les résultats. Tout ce que nous avons à faire pour obtenir le comportement souhaité est d'appeler l' distinctUntilChangedopérateur juste après avoir appelédebounceTime(400)
Voir l'exemple d' implémentation observable sur Plunker
Pour traiter les réponses hors service, veuillez consulter l'article complet
http://blog.oughttram.io/angular/2016/01/06/taking-advantage-of-observables-in-angular2.html
Pour autant que j'utilise Http dans Angular, je conviens que dans les cas d'utilisation normaux, il n'y a pas beaucoup de différence lors de l'utilisation d'Observable sur Promise. Aucun des avantages n'est vraiment pertinent ici dans la pratique. J'espère que je pourrai voir un cas d'utilisation avancée à l'avenir :)
Apprendre encore plus
