Entrambi Promisese Observablesci forniscono astrazioni che ci aiutano a gestire la natura asincrona delle nostre applicazioni. La differenza tra loro è stata chiaramente evidenziata da @ Günter e @Relu.
Poiché uno snippet di codice vale più di mille parole, passa attraverso l'esempio seguente per capirle più facilmente.
Grazie @Christoph Burgdorf per il fantastico articolo
Angular utilizza Rx.js Observables invece di promesse per gestire HTTP.
Supponiamo che tu stia creando una funzione di ricerca che dovrebbe mostrarti immediatamente i risultati durante la digitazione. Sembra familiare ma ci sono molte sfide che derivano da questo compito.
- Non vogliamo colpire l'endpoint del server ogni volta che l'utente preme un tasto, dovrebbe inondarli di una tempesta di
HTTPrichieste. Fondamentalmente, vogliamo colpirlo solo quando l'utente ha smesso di digitare invece che ad ogni pressione di un tasto.
- Non colpire l'endpoint di ricerca con gli stessi parametri di query per le richieste successive.
- Gestisci le risposte fuori ordine. Quando abbiamo più richieste in volo contemporaneamente, dobbiamo tenere conto dei casi in cui ritornano in un ordine imprevisto. Immagina di digitare prima il computer , fermarsi, una richiesta esce, digitare l' auto , fermarsi, una richiesta esce. Ora abbiamo due richieste in volo. Sfortunatamente, la richiesta che porta i risultati per computer ritorna dopo la richiesta che porta i risultati per auto .
La demo consisterà semplicemente in due file: app.tse wikipedia-service.ts. In uno scenario del mondo reale, molto probabilmente divideremmo le cose più in alto.
Di seguito è riportata un'implementazione basata su Promise che non gestisce nessuno dei casi limite descritti.
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]);
}
}
Stiamo iniettando il Jsonpservizio per effettuare una GETrichiesta all'API di Wikipedia con un determinato termine di ricerca. Si noti che chiamiamo toPromiseper passare da Observable<Response>a a Promise<Response>. Alla fine si finisce con un Promise<Array<string>>come tipo di ritorno del nostro metodo di ricerca.
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);
}
}
Anche qui non c'è molta sorpresa. Iniettiamo la nostra WikipediaServiceed esponiamo la sua funzionalità tramite un metodo di ricerca al modello. Il modello si lega semplicemente al keyup e alle chiamate search(term.value).
Scartiamo il risultato della Promessa che il metodo di ricerca di WikipediaService ritorna e lo espone come un semplice array di stringhe al modello in modo da poterlo *ngForscorrere e costruire un elenco per noi.
Vedi l'esempio dell'implementazione basata su Promise su Plunker
Dove gli osservabili brillano davvero
Cambiamo il nostro codice per non martellare l'endpoint con ogni sequenza di tasti, ma inviamo invece una richiesta solo quando l'utente ha smesso di digitare per 400 ms
Per svelare tali superpoteri dobbiamo prima ottenere un termine Observable<string>che contenga il termine di ricerca digitato dall'utente. Invece di associarlo manualmente all'evento keyup, possiamo trarre vantaggio dalla formControldirettiva di Angular . Per utilizzare questa direttiva, dobbiamo prima importare ReactiveFormsModulenel nostro modulo applicativo.
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 {}
Una volta importato, possiamo usare formControl dal nostro modello e impostarlo sul nome "termine".
<input type="text" [formControl]="term"/>
Nel nostro componente, creiamo un'istanza di FormControlfrom @angular/forme la esponiamo come un campo sotto il termine del nome sul nostro componente.
Dietro le quinte, il termine espone automaticamente una Observable<string>proprietà come a valueChangescui possiamo abbonarci. Ora che abbiamo un Observable<string>, superare l'input dell'utente è facile come chiamare debounceTime(400)il nostro Observable. Ciò restituirà un nuovo Observable<string>che emetterà un nuovo valore solo quando non ci sono stati nuovi valori per 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));
}
}
Sarebbe uno spreco di risorse inviare un'altra richiesta per un termine di ricerca per cui la nostra app mostra già i risultati. Tutto quello che dobbiamo fare per raggiungere il comportamento desiderato è chiamare l' distinctUntilChangedoperatore subito dopo aver chiamatodebounceTime(400)
Vedi l'esempio di implementazione osservabile su Plunker
Per gestire le risposte fuori ordine, consulta l'articolo completo
http://blog.thoughtram.io/angular/2016/01/06/taking-advantage-of-observables-in-angular2.html
Per quanto sto usando Http in angolare, sono d'accordo che nei casi d'uso normali non c'è molta differenza quando si usa Observable over Promise. Nessuno dei vantaggi è davvero rilevante qui in pratica. Spero di vedere qualche caso d'uso avanzato in futuro :)
Per saperne di più
