Jaka jest różnica między obietnicami a obserwowalnymi?


1395

Jaka jest różnica między Promisei Observablew Angular?

Przykład na każdym z nich byłby pomocny w zrozumieniu obu przypadków. W jakim scenariuszu możemy użyć każdego przypadku?


23
Proponuję ci przeczytać ten post; Obietnica Angular2 vs obserwowalna
erolkaya84


3
Wszystkim, którzy czytają to pytanie i odpowiedzi - jako osoba zaangażowana w oba światy od opiekuna, mówcy i długoletniego użytkownika PO, zachęcam do zapoznania się z oficjalnymi dokumentami RxJS i dokumentacją MDN na temat obietnic. Osobiście uważam, że odpowiedzi tutaj są całkowicie mylące i niepoprawne i wierzę, że są one, choć dobre intencje ludzi próbujących pomóc, bardzo szkodliwe.
Benjamin Gruenbaum

1
Proponuję ci przeczytać ten kątowy oficjalny dokument angular.io/guide/comparing-observables
fgul

I dlatego linki są uważane za niedopuszczalne jako odpowiedzi.
Dave

Odpowiedzi:


1547

Obietnica

PromiseObsługuje pojedyncze zdarzenie , gdy an asynchroniczny finalizuje działania lub nie.

Uwaga: istnieją Promisebiblioteki obsługujące anulowanie, ale Promisejak dotąd ES6 nie.

Zauważalny

Na Observable jest jak Stream(w wielu językach) i pozwala przekazać zero lub więcej zdarzeń, w których wywołanie zwrotne jest wywoływane dla każdego zdarzenia.

Często Observablejest preferowany, Promiseponieważ zapewnia funkcje Promisei nie tylko. ZObservable nie ma znaczenia, czy chcesz obsłużyć 0, 1, czy wiele zdarzeń. W każdym przypadku możesz użyć tego samego interfejsu API.

Observablema również tę zaletę, Promiseże można ją anulować . Jeśli wynik żądania HTTP do serwera lub innej kosztownej operacji asynchronicznej nie jest już potrzebny, oznacza SubscriptiontoObservable pozwala anulować subskrypcję, a a Promiseostatecznie wywoła sukces lub niepowodzenie wywołania zwrotnego, nawet jeśli nie potrzebujesz powiadomienia lub wynik, który zapewnia.

Obserwowalne zapewnia operatorom jak map,forEach , reduce, ... podobne do tablicy

Istnieją również potężne operatory, takie jak retry()lub replay()..., które często są bardzo przydatne.


180
Czy jest więc dobry powód, aby używać Obietnicy zamiast Obserowalnej w pojedynczej obudowie wywołania zwrotnego, czy też należy używać Observables, ponieważ mogą one również działać w ten sposób? Zasadniczo, czy dobrą praktyką jest „obserwowanie wszystkich rzeczy”, czy też Obietnica nadal ma swoje miejsce?
Josh Werts

75
Jeśli chcesz użyć stylu reaktywnego, po prostu używaj obserwowalnych wszędzie. Jeśli masz obserwowalne, tylko możesz łatwo komponować. Jeśli je wymieszasz, nie będzie już tak czyste. Jeśli nie zależy ci na reaktywnym stylu, możesz użyć obietnicy w przypadku pojedynczych wydarzeń, w których nie obchodzi Cię możliwość anulowania i obserwowania strumieni wydarzeń.
Günter Zöchbauer

35
@ GünterZöchbauer Hej - Nie mam argumentów przeciwko Observable lub programowaniu funkcjonalnemu. Po prostu stwierdzam, że uważam, że ludzie, którzy wpadają na Obserwowalne głównie przez http w NG2, nie mają żadnego prawdziwego powodu, aby używać Obserwowalnych zamiast Obietnic, aby wykonywać połączenia. Nie tracą nic praktycznego, stosując obietnice. Operatory debounce i retry są nieistotne - możesz debunować za pomocą ng-debounce, a jeśli oczekuje się, że połączenie się nie powiedzie, na ogół jest problem z kodem. Jedyny czas, jaki potrzebowałem do pracy z ponawianiem połączeń, to zapytanie o niestabilne interfejsy API innych firm dla HVT.
VSO

92
Ale proszę, nie zapominaj o tym Promise, wraz z async/ awaitsprawia, że ​​twój kod znów jest płaski! W większości sytuacji oraz w projektach, które nie zajmują się naukami o rakietach, nie ma potrzeby pisania tych okropnych funkcji zagnieżdżonych za pomocą niepotrzebnie skomplikowanych łańcuchów metod. Możesz używać async/ awaitdzisiaj z transpilatorami, jak TypeScripti pisać rzeczywisty, czytelny dla człowieka płaski kod bez żadnej płyty rxjsgłównej. Prawdopodobnie nadal będziesz potrzebować rxjsczasami w wybranych sytuacjach, ponieważ naprawdę ma wiele rzeczy do zaoferowania.
evilkos

15
Ta odpowiedź jest myląca, obserwowalny nie jest jak strumień, jest jak funkcja zwracająca strumień .
Benjamin Gruenbaum

333

Zarówno Promisesi Observablesdostarczyć nam abstrakcjami, które pomagają nam radzić sobie z asynchronicznym naturę naszych aplikacji. Różnicę między nimi wyraźnie wskazali @ Günter i @Relu.

Ponieważ fragment kodu jest wart tysiąca słów, przejrzyj poniższy przykład, aby je łatwiej zrozumieć.

Dzięki @Christoph Burgdorf za wspaniały artykuł


Angular używa Rx.js Observables zamiast obietnic do obsługi HTTP.

Załóżmy, że budujesz funkcję wyszukiwania, która powinna natychmiast wyświetlać wyniki podczas pisania. Brzmi znajomo, ale z tym zadaniem wiąże się wiele wyzwań.

  • Nie chcemy trafić na punkt końcowy serwera za każdym razem, gdy użytkownik naciśnie klawisz, powinien zalać go burzą HTTP żądań. Zasadniczo chcemy go nacisnąć tylko wtedy, gdy użytkownik przestanie pisać zamiast z każdym naciśnięciem klawisza.
  • Nie trafiaj punktu końcowego wyszukiwania za pomocą tych samych parametrów zapytania dla kolejnych żądań.
  • Radzenie sobie z reakcjami poza kolejnością. Gdy mamy wiele żądań w locie w tym samym czasie, musimy uwzględnić przypadki, w których wracają w nieoczekiwanej kolejności. Wyobraźmy sobie, że najpierw wpisujemy komputer , zatrzymujemy się, żądanie gaśnie, wpisujemy samochód , zatrzymujemy się, żądanie gaśnie. Teraz mamy dwa żądania podczas lotu. Niestety żądanie, które przenosi wyniki dla komputera, wraca po żądaniu, które przenosi wyniki dla samochodu .

Demo będzie się po prostu składało z dwóch plików: app.tsi wikipedia-service.ts. Jednak w prawdziwym świecie najprawdopodobniej podzielilibyśmy rzeczy dalej.


Poniżej znajduje się implementacja oparta na obietnicach , która nie obsługuje żadnego z opisanych przypadków krawędzi.

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]);
  }
}

Wstrzykiwamy Jsonpusługę, aby zgłosić GETżądanie przeciwko API Wikipedii przy użyciu określonego wyszukiwanego hasła. Zauważ, że my nazywamy toPromisew celu uzyskania od Observable<Response>Do Promise<Response>. Ostatecznie otrzymamy Promise<Array<string>>jako typ zwrotu naszej metody wyszukiwania.

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);
  }
}

Tu też nie ma niespodzianki. Wstrzykiwamy naszą WikipediaServicei udostępniamy jej funkcjonalność za pomocą metody wyszukiwania do szablonu. Szablon po prostu wiąże się z keyup i wywołaniamisearch(term.value) .

Rozpakowujemy wynik obietnicy, że metoda wyszukiwania WikipediaService zwraca i udostępniamy szablonowi jako prostą tablicę ciągów, abyśmy mogli mieć*ngFor go przejrzeć i stworzyć dla nas listę.

Zobacz przykład implementacji opartej na obietnicach w firmie Plunker


Gdzie obserwatorzy naprawdę świecą

Zmieńmy nasz kod, aby nie wbijał punktu końcowego przy każdym naciśnięciu klawisza, ale zamiast tego wysyłał żądanie tylko wtedy, gdy użytkownik przestał pisać na 400 ms

Aby odsłonić takie super moce, najpierw musimy uzyskać taki, Observable<string>który zawiera wyszukiwane hasło, które wpisuje użytkownik. Zamiast ręcznego wiązania się ze zdarzeniem keyup, możemy skorzystać z formControldyrektywy Angulara . Aby skorzystać z tej dyrektywy, musimy najpierw zaimportować ją ReactiveFormsModuledo naszego modułu aplikacji.

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 {}

Po zaimportowaniu możemy użyć formControl z naszego szablonu i nadać mu nazwę „term”.

<input type="text" [formControl]="term"/>

W naszym komponencie tworzymy instancję FormControlz@angular/form i udostępniamy ją jako pole pod nazwą terminu na naszym komponencie.

Za kulisami termin automatycznie ujawnia Observable<string>właściwość as valueChanges, którą możemy subskrybować. Teraz, gdy mamy Observable<string>, pokonanie danych wejściowych użytkownika jest tak proste, jak wywołanie debounceTime(400)naszego Observable. Zwróci to nową Observable<string>, która wyemituje nową wartość tylko wtedy, gdy nie pojawią się nowe wartości przez 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));
  }
}

Stratą zasobów byłoby wysłanie kolejnej prośby o wyszukiwany termin, dla którego nasza aplikacja już pokazuje wyniki. Wszystko, co musimy zrobić, aby osiągnąć pożądane zachowanie, to zadzwonić do distinctUntilChangedoperatora zaraz po tym, jak zadzwoniliśmydebounceTime(400)

Zobacz przykład Obserwowalnej implementacji na Plunkerze

Aby poradzić sobie z odpowiedziami na zamówienie, sprawdź pełny artykuł http://blog.thoughtram.io/angular/2016/01/06/taking-oughage-of-observables-in-angular2.html

O ile używam Http w Angular, zgadzam się, że w normalnych przypadkach użycia nie ma dużej różnicy przy użyciu Observable over Promise. Żadna z zalet nie ma tu tak naprawdę znaczenia w praktyce. Mam nadzieję, że zobaczę jakiś zaawansowany przypadek użycia w przyszłości :)


Ucz się więcej


31
Nie do końca kupuję decyzję o przekształceniu usługi HTTP w Observable. Każde wyjaśnienie opiera się na tym samym przykładzie: Wyszukiwanie według terminu. Ale ten dotyczy obsługi zdarzeń przeglądarki. Chciałbym usłyszeć, jaką zaletą jest zastosowanie go w przypadku asynchronicznych żądań HTTP.
Alex Pollan

1
Czy decyzja była przypadkowa, aby uniknąć mieszanych wzorców?
Alex Pollan

6
@AlexPollan, istnieje dobre wytłumaczenie korzyści z usługi http zwracającej obserwowalne w tym podcastie z Benem Leshem: devchat.tv/js-jabber/… . Ostatecznie, główną zaletą jest to, że możesz anulować obserwowalne, a przypadek użycia tego opisany w powyższym linku - choć nieco wymyślony - polega na tym, że jeśli wołasz wiele apis i dbasz tylko o pierwszą odpowiedź, bez względu na to, które z apis, do którego dzwoniłeś, w pierwszej kolejności wraca do ciebie, możesz anulować prośby do innych.
nikolasleblanc

2
@nikolasleblanc, jestem pewien, że możesz do tego użyć $ q.race ()?
jameslouiz

2
@AlexPollan, zaletą jest to, że usługa HTTP oparta na obserwowalnych ułatwia anulowanie żądań HTTP w trakcie lotu. Warunek wyścigu w odpowiedzi trungk18 można rozwiązać, po prostu wypisując się z obserwowalnego HTTP przed złożeniem kolejnego żądania. SwitchMap RXJS może być używany do żądań HTTP wyzwalanych przez inne obserwowalne (np. ValueChanges). W przypadku samodzielnych obserwowalnych HTTP możesz ręcznie zrezygnować z subskrypcji i ponownie ją zasubskrybować.
Stevethemacguy

234

Zarówno obietnice, jak i obserwowalne pomogą nam pracować z funkcjami asynchronicznymi w JavaScript. W wielu przypadkach są bardzo podobne, jednak nadal istnieją między nimi pewne różnice, obietnice są wartościami, które zostaną rozwiązane w asynchronoussposób podobny do wywołań http . Z drugiej strony, obserwowalne zajmują się sekwencją zdarzeń asynchronicznych . Główne różnice między nimi wymieniono poniżej:

obietnica:

  • mając jeden rurociąg
  • zwykle używaj tylko z asynchronicznym zwracaniem danych
  • niełatwe do anulowania

zauważalny:

  • można anulować
  • są z natury wiarygodne, takie jak ponawianie i ponawianie, kiedy
  • przesyłaj strumieniowo dane w wielu potokach
  • mając operacje tablicowe, takie jak mapa, filtr itp
  • mogą być tworzone z innych źródeł, takich jak zdarzenia
  • są to funkcje, które można subskrybować później

Ponadto stworzyłem dla Ciebie obraz graficzny, aby wizualnie pokazać różnice:

Obraz obietnic i obserwacji


4
obiecaj „nie łatwo anulować”, czy można je anulować?
Pardeep Jain,

10
tak, istnieje również sposób na ich anulowanie ... niektórzy ludzie używają biblioteki bluebird lub stron trzecich ... również używając biblioteki Q w Angular istnieją sposoby, aby ją anulować ... ale jak powiedziałem, niezbyt przydatne
Alireza

Posiadanie jednego rurociągu ma czasem zalety, np. w APP_INITIALIZER, jeśli masz wiele potoków, nigdy nie może zakończyć się czasem lub zakończyć wiele razy.
windmaomao

6
anulowanie a Promisejest niewłaściwym sposobem myślenia o tym, co obiecuje. Promise„S odpowiedzialność tylko do sukcesu lub niepowodzenia rączki w kompatybilnym sposób asynchroniczny .. Jeśli chcesz, aby anulować żądanie http anulować żądanie, a nie obietnica, i sprawiają, że wynik odwołania albo spełniają lub odrzucić obietnicę. jsfiddle.net/greggman/ea0yhd4p
gman

2
@gman Dokładnie. Obietnica stanowi po prostu pewną przyszłą wartość . To nie nie reprezentuje operację, która generuje wartość . Nie możesz anulować wartości. Nie można ponowić wartości. To tylko wartość. Może, ale nie musi być obecny , i może nigdy nie istnieć, ponieważ wystąpił wyjątek, ale to wszystko.
Yona Appletree

75

Obietnice

  1. Definicja: Pomaga uruchamiać funkcje asynchronicznie i używać ich zwracanych wartości (lub wyjątków), ale tylko raz po uruchomieniu .
  2. Nie leniwy
  3. Nie można anulować (istnieją biblioteki Promise obsługujące anulowanie, ale jak dotąd ES6 Promise). Dwie możliwe decyzje to
    • Odrzucać
    • Rozwiązać
  4. Nie można ponowić (obietnice powinny mieć dostęp do oryginalnej funkcji, która zwróciła obietnicę możliwości ponownej próby, co jest złą praktyką)

Obserwowalne

  1. Definicja: Pomaga uruchamiać funkcje asynchronicznie i wykorzystywać ich zwracane wartości w ciągłej sekwencji ( wiele razy ) po .
  2. Domyślnie jest leniwy, ponieważ emituje wartości w miarę upływu czasu.
  3. Ma wiele operatorów, co upraszcza kodowanie.
  4. Jeden operator ponawiania mogą być wykorzystane, aby ponowić próbę jeśli zajdzie taka potrzeba, również jeśli musimy ponowić obserwowalny na podstawie pewnych warunkach retryWhen mogą być użyte.

    Uwaga : Lista operatorów wraz z ich interaktywnymi diagramami jest dostępna tutaj na RxMarbles.com


67

W odpowiedziach brakuje jednej wady Obserwowalnych. Obietnice pozwalają korzystać z funkcji asynchronicznych / oczekujących ES7. Za ich pomocą możesz pisać kod asynchroniczny, tak jakby to było synchroniczne wywołanie funkcji, więc nie potrzebujesz już wywołań zwrotnych. Jedyną możliwością, aby Obserwatorzy to zrobili, jest przekonwertowanie ich na Obietnice. Ale po przekonwertowaniu ich na obietnice możesz ponownie mieć tylko jedną wartość zwracaną:

async function getData(){
    const data = await observable.first().toPromise();
    //do stuff with 'data' (no callback function needed)
}

Dalsza lektura: Jak mogę poczekać na Rx Observable?


21
Dziwiło mnie również, dlaczego nikt nie wskazał tego zabójczego atutu obietnic - prostota i przejrzystość dzięki asynchronizacji / czekaniu. Zmieniłem na Obietnice tylko ze względu na możliwość pisania płaskiego kodu. Prosta logika biznesowa i kod interakcji interfejsu użytkownika nie powinny wyglądać jak nauka o rakietach i być zanieczyszczone przez zagnieżdżone piekło reaktywnych rozszerzeń. Ponadto async / await jest nie tylko w przyszłości, możesz go używać w aplikacjach produkcji publicznej za pomocą transpilatorów. Używam TypeScript 2.3 i jest niesamowity, jak prawdziwy język.
evilkos

Fajnie, ale myślę w sposób reaktywny i wszystko w przypadku RxOperatorów może nie jest to funkcja
zabójcza

37

Obietnice i Obserwowalne obsługują tylko wywołanie asynchroniczne.

Oto różnice między nimi:

Zauważalny

  1. Emituje wiele wartości w pewnym okresie czasu
  2. Nie jest wywoływany, dopóki nie zasubskrybujemy Observable
  3. Można anulować za pomocą metody unsubscribe ()
  4. Udostępnia mapę, forEach, filtrowanie, zmniejszanie, ponawianie i ponawianie, gdy operatorzy

Obietnica

  1. Emituje tylko jedną wartość na raz

  2. Wywołuje usługi bez .then i .catch

  3. Nie można anulować

  4. Nie zapewnia żadnych operatorów


2
Co dokładnie masz na myśli, mówiąc, że obietnica emituje tylko jedną wartość, a obserwowalna emituje wiele
Abel

2
Obietnica w ogóle nie emituje wartości - obietnica jest wartością w czasie. Obietnice multiemisji, które są cenne dla wielu subskrybentów - gdy już dotrzymasz obietnicy, masz już wartość. Obserwowalny jest jak funkcja , subskrybowanie go wywołuje akcję.
Benjamin Gruenbaum,

1
@BenjaminGruenbaum Wciąż nie rozumiem wielu subskrybentów. Proszę podać link lub przykład. Dzięki
Deepak Patidar

2
observable1.subscribe (subscriber1), observable1.subscribe (subscriber2) - wywołuje to wielokrotnie funkcję .
Benjamin Gruenbaum,

2
Proszę edytować swój post i pokazać rzeczywisty tekst zamiast screenów. Inni nie mogą kopiować i wklejać z twoich zdjęć, a także nie mogą pomóc w naprawie wielu błędów gramatycznych. Zobacz tutaj, aby uzyskać szczegółowe informacje. Dziękuję Ci.
Pang

25

Mimo że odpowiedź jest późna, podsumowałem poniżej różnice,

Zauważalny:

  1. Obserwowalne to tylko to, functionco bierze an observeri zwraca a function Observer: an object with next, error.
  2. Obserwator pozwala subscribe/unsubscribeswojemu strumieniowi danych wysyłać następną wartość obserwatorowi, notifyobserwatorowi o tym errorsi informować go ostream completion
  3. Obserwator zapewnia function to handle next value , błędy i koniec strumienia (zdarzenia interfejsu użytkownika, odpowiedzi HTTP, dane z gniazdami sieciowymi).
  4. Pracuje z multiple values czasem
  5. Jest cancel-able/retry-ablei obsługuje operatorów takich jakmap,filter,reduce itp.
  6. Tworzenie obserwowalnego może być - Observable.create()- zwraca Obserwowalne, które może wywoływać metody na - Observer Observable.from()- konwertuje tablicę lub iterowalne na - Observable Observable.fromEvent()- konwertuje zdarzenie na Obserwowalne - Observable.fromPromise()- konwertuje obietnicę na Obserwowalne - Observable.range()- zwraca sekwencję liczb całkowitych w określonym zakresie

Obietnica :

  1. Obietnica reprezentuje zadanie, które zakończy się w przyszłości;

  2. Obietnice stają się resolved by a value;

  3. Obietnice są odrzucane przez wyjątki;

  4. Nie cancellablei to wracaa single value

  5. Obietnica ujawnia funkcję (then)

    - następnie zwraca nowy promise;

    -zezwolenia na attachmentto zostaną wykonane na podstawie state ;

    - handlersmają guaranteedzostać wykonane w order attached;


20

Właśnie poradziłem sobie z problemem, w którym Obietnice były najlepszym rozwiązaniem, i dzielę się nim tutaj dla każdego, kto natknie się na to pytanie w przypadku, gdy jest ono przydatne (to była dokładnie odpowiedź, której szukałem wcześniej):

W projekcie Angular2 mam usługę, która przyjmuje niektóre parametry i zwraca listę wartości, aby wypełnić menu rozwijane w formularzu. Podczas inicjowania komponentu formularza muszę wywoływać tę samą usługę wiele razy z różnymi parametrami, aby zdefiniować wiele różnych menu rozwijanych, jednak jeśli po prostu ustawię w kolejce wszystkie zmienne w celu wywołania usługi, tylko ostatnia powiedzie się i błąd reszty na zewnątrz. Usługa pobierająca z bazy danych mogła obsłużyć tylko jedno żądanie na raz.

Jedynym sposobem na pomyślne wypełnienie wszystkich zmiennych menu rozwijanego było wywołanie usługi w sposób, który uniemożliwił przetworzenie nowego żądania aż do ostatniego żądania, a mechanizm Promise / .then rozwiązał problem.

  fetchValueList(listCode): Promise<any> {
      return this.dataSvc.getValueList(listCode, this.stateSvc.currentContext, this.stateSvc.currentLanguageCode)
          .map(response => response.json())
          .toPromise();
  }

  initializeDropDowns() {
      this.fetchValueList('First-Val-List')
          .then(data => {
              this.firstValList = data;
              return this.fetchValueList('Second-Val-List')
          }).then(data => {
              this.secondValList = data;
              return this.fetchValueList('Third-Val-List')
          }).then(data => {
              this.thirdValList = data;
          })  }

Zdefiniowałem funkcje w komponencie, a następnie wywołałem initializeDropDowns () w ngOnInit.

Funkcja fetchValueList zwraca obietnicę, więc pierwsze wywołanie przechodzi pierwszy listCode, a po rozwiązaniu obietnicy zwracana wartość znajduje się w zmiennej danych w bloku .then, w której możemy przypisać ją do zmiennej this.firstValList. Ponieważ funkcja zwróciła dane, wiemy, że usługa się zakończyła i można bezpiecznie wywoływać ponownie z drugim listCode, zwracana wartość znajduje się w zmiennej danych w następnym bloku .then i przypisujemy ją do zmiennej this.secondValList.

Możemy to połączyć tyle razy, ile jest to wymagane, aby zapełnić wszystkie zmienne, aw ostatnim bloku kodu po prostu pomijamy instrukcję return i blok się kończy.

Jest to bardzo szczególny przypadek użycia, w którym mamy jedną usługę, która musi być wywoływana wiele razy podczas inicjowania komponentu, i gdzie usługa musi zakończyć pobieranie i zwrócić wartość, zanim będzie mogła zostać ponownie wywołana, ale w tym przypadku metoda Obietnica / .tąd była idealna.


3
Z pewnością jest to również możliwe w przypadku obserwowalnych (wyższych rzędów). Możesz na przykład użyć scan()do zbudowania strumienia sekwencji obserwowalnych. Jednak twoje podejście może być bardziej wyraźne i łatwiejsze do zrozumienia.
lex82

1
Możesz zamienić „następnie” na „switchMap” i zrobić dokładnie to samo z obserwowalnymi.
Dr. C. Hilarius

1
Problem z switchMap, jak rozumiem, polega na tym, że uruchomi wszystkie żądania równolegle i poczeka, aż wszystkie się zwrócą, a następnie zwróci wartości do funkcji wywołującej, podczas gdy w mojej sytuacji mam pojedynczy serwer, którego nie mogę zadzwoń wiele razy równolegle (ponieważ serwer porzuci niedokończone żądania, gdy pojawią się nowe), więc musiałem upewnić się, że każde połączenie z usługą bazy danych zostało zakończone przed rozpoczęciem nowego połączenia, a Obietnica / wtedy wydawała się najlepsza i być może jedyny sposób na rozwiązanie tego.
Stephen R. Smith

1
Dlaczego nie użyłeś połączonej MergeMap? O ile rozumiem twój kod, ten jest dość prosty i działa tak dobrze, jak twój przykład. @ StephenR.Smith
Ore

1
@Ore Czy możesz dodać przykładowy kod rozwiązania tego samego problemu, co inna odpowiedź? Byłby to dobry punkt odniesienia i może być dobrą okazją do refaktoryzacji w przyszłości. Wymagane jest, aby każdy kod nie mógł wywoływać równolegle usługi zaplecza, musi zadzwonić, poczekać na wartość zwrotną i ponownie zadzwonić.
Stephen R. Smith,

20

Uważam, że wszystkie pozostałe odpowiedzi powinny wyjaśnić twoje wątpliwości. Niemniej jednak chciałem tylko dodać, że obserwowalne są oparte na programowaniu funkcjonalnym i uważam, że bardzo przydatne są funkcje, które się z tym wiążą, takie jak mapa, mapa, redukcja, zip. Spójność, którą osiąga sieć, szczególnie gdy zależy od żądań API, stanowi brutalną poprawę.

Zdecydowanie polecam tę dokumentację , ponieważ jest to oficjalna dokumentacja reactiveX i uważam, że jest najbardziej przejrzysta.

Jeśli chcesz zagłębić się w obserwowalne, proponuję ten 3-częściowy post: http://blog.danlew.net/2014/09/15/grokking-rxjava-part-1/

Chociaż jest przeznaczony dla RxJava, koncepcje są takie same i bardzo dobrze wyjaśnione. W dokumentacji reactiveX masz odpowiedniki dla każdej funkcji. Musisz poszukać RxJS.


18

Obietnica:

  • Podaj jedną przyszłą wartość;
  • Nie leniwy;
  • Nie można anulować;

Zauważalny:

  • Emituje wiele wartości w czasie;
  • Leniwy;
  • Anulowalne;
  • Obsługuje mapowanie, filtrowanie, zmniejszanie i podobne operatory

Możesz użyć obietnic zamiast obserwowalnych podczas wywoływania HTTP w Angular, jeśli chcesz.


16

Przegląd:

  • Zarówno obietnice, jak i obserwowalne pomagają nam radzić sobie z operacjami asynchronicznymi. Mogą wywoływać określone połączenia zwrotne, gdy wykonywane są te operacje asynchroniczne.
  • Obietnica może obsłużyć tylko jedno zdarzenie, Obserwowalne dotyczą strumieni wydarzeń w czasie
  • Obietnic nie można anulować, gdy są w toku
  • Dane emitowane przez obserwowalne dane można przekształcać za pomocą operatorów

Zawsze możesz użyć obserwowalnego do radzenia sobie z zachowaniem asynchronicznym, ponieważ obserwowalny ma całą funkcjonalność, którą oferuje obietnica (+ dodatkowe). Czasami jednak ta dodatkowa funkcjonalność oferowana przez Observables nie jest potrzebna. W takim przypadku dodatkowym kosztem byłoby zaimportowanie biblioteki, aby mogła z nich korzystać.

Kiedy stosować Obietnice:

Użyj obietnic, gdy masz jedną operację asynchroniczną, której wynik chcesz przetworzyć. Na przykład:

var promise = new Promise((resolve, reject) => {
  // do something once, possibly async
  // code inside the Promise constructor callback is getting executed synchronously

  if (/* everything turned out fine */) {
    resolve("Stuff worked!");
  }
  else {
    reject(Error("It broke"));
  }
});

//after the promise is resolved or rejected we can call .then or .catch method on it

promise.then((val) => console.log(val))      // logs the resolve argument
       .catch((val) => console.log(val));    // logs the reject argument

Tak więc obietnica wykonuje kod, który rozwiązuje lub odrzuca. W przypadku wywołania rozwiązania lub odrzucenia obietnica przechodzi ze stanu oczekującego do stanu rozstrzygniętego lub odrzuconego . Po rozwiązaniu stanu obietnicy then()wywoływana jest metoda. Kiedy stan obietnicy zostanie odrzucony,catch() wywoływana jest metoda

Kiedy stosować Obserwowalne:

Użyj Obserwowalnych, gdy z upływem czasu istnieje strumień (danych), z którym musisz sobie poradzić. Strumień jest sekwencją elementów danych, które są udostępniane w miarę upływu czasu . Przykłady strumieni to:

  1. Zdarzenia użytkownika, np. Zdarzenia kliknięcia lub keyup. Użytkownik generuje zdarzenia (dane) w czasie.
  2. Websockets, po tym jak klient nawiązuje połączenie WebSocket z serwerem, z czasem wypycha dane.

W Observable sam określa się, kiedy nastąpiło następne zdarzenie , kiedy wystąpił błąd lub kiedy Observable został zakończony . Następnie możemy zasubskrybować ten obserwowalny, który go aktywuje, aw tym abonamencie możemy przekazać 3 oddzwaniania (nie zawsze trzeba przekazywać wszystkie). Jedno wywołanie zwrotne należy wykonać w celu pomyślnego zakończenia, jedno wywołanie zwrotne w przypadku błędu i jedno wywołanie zwrotne w celu zakończenia. Na przykład:

const observable = Rx.Observable.create(observer => {
  // create a single value and complete
  observer.onNext(1);
  observer.onCompleted();
});

source.subscribe(
  x => console.log('onNext: %s', x),   //  success callback
  e => console.log('onError: %s', e),  //  error callback
  () => console.log('onCompleted')     //  completion callback
 );

// first we log: onNext: 1
//  then we log: onCompleted

Podczas tworzenia obserwowalnego wymaga funkcji zwrotnej, która dostarcza obserwatora jako argumentu. Na tej obserwatora, to wtedy można nazwać onNext, onCompleted, onError. Następnie, gdy Obserwowalny jest zasubskrybowany, wywoła odpowiednie wywołania zwrotne przekazane do subskrypcji.


9

Obietnica - Podaj jedną przyszłą wartość. Nie leniwy . Nie można anulować. Odrzuci lub rozwiąże.

Obserwowalny - zapewnia wiele przyszłych wartości. Leniwy . Możliwość anulowania. Zapewnia inne metody mapy na żywo, filtrowania, zmniejszania.


8

Najpierw obietnica kontra zauważalne podobieństwo

  1. Oba służą do obsługi kodu asynchronicznego.
  2. Poszukaj przykładu z obietnicą. Konstruktor Promise przekazuje funkcję odwołania referencyjnego, która zostanie wywołana, gdy zostanie wywołana z pewną wartością po zakończeniu jakiegoś zadania asynchronicznego.

const promise = new Promise(resolve => {
  setTimeout(() => {
    resolve("Hello from a Promise!");
  }, 2000);
});

promise.then(value => console.log(value));

  1. Obserwowalny przykład teraz. Tutaj również przekazujemy funkcję obserwowalnym, obserwatorowi do obsługi zadania asynchronicznego. W przeciwieństwie do rozwiązania zawartego w obietnicy ma on następującą metodę i subskrybuje zamiast niej.

  2. Więc oba obsługują zadania asynchroniczne. Zobaczmy teraz różnicę.


const observable = new Observable(observer => {
  setTimeout(() => {
    observer.next('Hello from a Observable!');
  }, 2000);
});

observable.subscribe(value => console.log(value));

Obietnica a zauważalna różnica

Obietnica

  1. Rozwiązuje lub odrzuca pojedynczą wartość i może obsłużyć zadanie asynchroniczne pojedynczej wartości na raz.
  2. Obietnica po rozwiązaniu wartości asynchronicznej, którą wypełnia, nie może być już dłużej używana. Jest to jednorazowe użycie i tutaj jest ona niewystarczająca.
  3. Nie można anulować
  4. Brak obsługi rxjs dla operatorów.

Zauważalny

  1. zdolność do emitowania wielu wartości asynchronicznych.
  2. Służy do obsługi strumienia zdarzeń lub wartości. Rozważ, że masz szereg różnych zadań lub wartości i chcesz, aby za każdym razem, gdy wstawiana jest do nich wartość, powinna być obsługiwana automatycznie. Za każdym razem, gdy wpychasz wartość do tej tablicy, wszyscy jej subskrybenci otrzymają automatycznie najnowszą wartość.
  3. Obserwowalne są przydatne do obserwowania zmian danych wejściowych, powtarzanych interwałów, wartości rozgłoszeniowych do wszystkich elementów potomnych, powiadomień wypychanych przez gniazdo sieciowe itp.
  4. Można anulować za pomocą metody anulowania subskrypcji w dowolnym momencie.
  5. Jeszcze jedną dobrą częścią, która obiecuje, jest wsparcie dla operatorów rxjs. Masz wielu operatorów potoków, którzy głównie mapują, filtrują, przełączają mapy, łączą najnowsze itp., Aby przekształcać obserwowalne dane przed subskrybowaniem.

wprowadź opis zdjęcia tutaj



6

Zarówno obietnice, jak i obserwowalne pomagają nam radzić sobie z operacjami asynchronicznymi. Mogą wywoływać określone połączenia zwrotne, gdy wykonywane są te operacje asynchroniczne.

Angular używa Observables, który pochodzi z RxJS zamiast obietnic dotyczących obsługi HTTP

Below are some important differences in promises & Observables.

różnica między obietnicami a obserwowalnymi


1
Dane w tabeli wydają się niepoprawne, tytuł należy zamienić
Derrick.X

1
Proszę edytować swój post i pokazać rzeczywistą zawartość jako tekst zamiast screenów. Inni nie mogą kopiować ani wklejać z twoich zdjęć. Zobacz tutaj, aby uzyskać szczegółowe informacje. Dziękuję Ci.
Pang

6

Obietnica emituje pojedyncze zdarzenie, gdy działanie asynchroniczne kończy się lub kończy się niepowodzeniem.

Obserwowalny jest jak Strumień (w wielu językach) i pozwala przekazać co najmniej zero lub więcej zdarzeń, w których wymagane jest wywołanie zwrotne dla każdego zdarzenia.

Często obserwowalny jest lepszy od Promise, ponieważ daje najważniejsze obietnice i więcej. W Observable nie ma znaczenia, czy chcesz obsłużyć 0, 1, czy różne zdarzenia. Możesz użyć podobnego API dla każdego przypadku.

Obietnica: obietnica emituje jedną wartość

Na przykład:

const numberPromise = new Promise((resolve) => {
    resolve(5);
    resolve(10);
});

numberPromise.then(value => console.log(value));
// still prints only 5

Zauważalny: emituje wiele wartości w pewnym okresie czasu

Na przykład:

  const numberObservable = new Observable((observer) => {
        observer.next(5);
        observer.next(10);
    });

numberObservable.subscribe(value => console.log(value));
// prints 5 and 10

możemy myśleć o obserwowalnym strumieniu, który emituje wiele wartości w danym okresie czasu i dla każdego emitowanego elementu wywoływana jest ta sama funkcja zwrotna, więc za pomocą obserwowalnego możemy używać tego samego interfejsu API do obsługi danych asynchronicznych. czy dane te są przesyłane jako pojedyncza wartość czy wiele wartości w pewnym przedziale czasu.

Obietnica:

  • Obietnica nie jest leniwa
  • Obietnicy nie można anulować

Zauważalny:

  • Obserwowalny jest Leniwy. „Obserwowalny” jest powolny. Nie jest wywoływany, dopóki go nie zasubskrybujemy.
  • Obserwowalne można anulować za pomocą metody unsubscribe ()
  • Dodatek Observable zapewnia wielu potężnym operatorom, takim jak mapowanie, wyszukiwanie, filtrowanie, zmniejszanie, ponawianie, ponawianie, gdy itp.

Kątowe obietnice a obserwowalne


5

Promise emituje jedną wartość, a Observable emituje wiele wartości. Tak więc, podczas obsługi żądania HTTP, Promise może zarządzać pojedynczą odpowiedzią na to samo żądanie, ale co zrobić, jeśli istnieje wiele odpowiedzi na to samo żądanie, wówczas musimy użyć Observable. Tak, Observable może obsłużyć wiele odpowiedzi dla tego samego żądania.

Obietnica

const promise = new Promise((data) =>
{ data(1);
  data(2);
  data(3); })
.then(element => console.log(‘Promise ‘ + element));

Wynik

Promise 1

Zauważalny

const observable = new Observable((data) => {
data.next(1);
data.next(2);
data.next(3);
}).subscribe(element => console.log('Observable ' + element));

Wynik

Observable 1
Observable 2
Observable 3

3

Poniżej kilka ważnych różnic w obietnicach i obserwowalnościach.

Obietnica

  • Emituje tylko jedną wartość
  • Nie można anulować
  • Nie do udostępnienia
  • Zawsze asynchroniczny

Zauważalny

  • Emituje wiele wartości
  • Wykonuje się tylko wtedy, gdy zostanie wywołany lub ktoś subskrybuje
  • Można anulować
  • Może być współużytkowana i subskrybowana tę wspólną wartość przez wielu subskrybentów. I wszyscy subskrybenci wykonają się w jednym momencie.
  • prawdopodobnie asynchroniczny

Aby lepiej zrozumieć, odwiedź https://stackblitz.com/edit/observable-vs-promises


3

Widzę wielu ludzi używających argumentu, że „Obserowalne” można „anulować”, ale ustawienie „Obietnicy” jest dość trywialne.

function cancellablePromise(body) {
  let resolve, reject;
  const promise = new Promise((res, rej) => {
    resolve = res; reject = rej;
    body(resolve, reject)
  })
  promise.resolve = resolve;
  promise.reject = reject;
  return promise
}

// Example 1: Reject a promise prematurely
const p1 = cancellablePromise((resolve, reject) => {
  setTimeout(() => resolve('10', 100))
})

p1.then(value => alert(value)).catch(err => console.error(err))
p1.reject(new Error('denied')) // expect an error in the console

// Example: Resolve a promise prematurely
const p2 = cancellablePromise((resolve, reject) => {
  setTimeout(() => resolve('blop'), 100)
})

p2.then(value => alert(value)).catch(err => console.error(err))
p2.resolve(200) // expect an alert with 200


2

Krótka odpowiedź :

Obserwowalne jest lepsze , ma wszystkie funkcje Obietnic plus dodatkowe funkcje.


Długa odpowiedź:

Obietnice:

  • Jednorazowo użyj opcji „Zwróć dane raz”
  • Nie anuluj
  • Jeden słuchacz
  • Brak obsługi gniazda Jeden odbiornik

Zauważalny:

  • Zwracaj dane wiele razy w miarę zmiany danych
  • Wsparcie anulować
  • Gniazdo podtrzymujące
  • Obsługa wielu Listener i powiadamianie ich o zmianie danych
  • Wesprzyj mapę, filtruj, zmniejszaj

Nie sądzę, że można powiedzieć, że Obserwowalne są obiektywnie lepsze. Istnieje wiele wad obserwowalnych wymienionych w różnych odpowiedziach tutaj. Te, które mnie wyróżniają, to złożoność Observable i to, że nie działają one bezpośrednio z funkcją Oczekiwania / Asynchronizacji. Osobiście uważam, że naprawdę ciężko z nimi pracować, ponieważ nie można określić zachowania Observable podczas korzystania z niego - musisz spojrzeć na kod, który go wygenerował. Natomiast dzięki obietnicy zawsze wiesz dokładnie, jak działają. Na przykład czasami subskrypcja Observable ma skutki uboczne (np. Żądanie HTTP), ale czasami nie.
Yona Appletree

W przypadku kąta zależy to od twojego przypadku. w większości przypadków będziemy pracować z usługami i niektórymi danymi, które wpłyną na różne miejsca, gniazda, anulowanie, mapę, filtrowanie i redukcję. więc będzie lepiej w tych przypadkach, ponieważ obietnice ich nie wspierają. więc znowu to zależy od twojej sprawy
Amr Ibrahim,

2

Chociaż ogólnie przyjęta odpowiedź jest dobra, nie sądzę, aby podkreślała, że ​​w przypadku Komponentów Angularnych prawie zawsze chcesz użyć Obserwowalnego, ponieważ obsługuje anulowanie. Obietnic nie można anulować i zostaną one rozwiązane, nawet jeśli element zostanie zniszczony. Angular zwykle wybacza, dopóki tak nie jest.

Na przykład każde ręczne wykrycie zmiany w zniszczonym komponencie spowoduje wyjątek:

ngOnInit() {
  // promise api
  this.service.getData().then(d => {
     this.data = d;
     this.changeDetectorRef.detectChanges();
  });

  // observable api
  this.service.getData().pipe(takeUntil(this.unsubscribe)).subscribe((d) => {
     this.data = d;
     this.changeDetectorRef.detectChanges();
  });
}

Jeśli twój komponent zostanie zniszczony przed rozpatrzeniem obietnicy, otrzymasz attempt to use destroyed view błąd, gdy obietnica zostanie rozwiązana.

Alternatywnie, jeśli używasz obserwowalnych z takeUntil wzorcem , to natychmiast po zniszczeniu komponentu subskrypcja zostanie anulowana.

To trochę wymyślony przykład, ale wykonanie kodu dla zniszczonego komponentu prawdopodobnie doprowadzi do błędów. Chyba że faktycznie chcesz to zrobić z jakiegoś powodu: str


2

Coś, na co wpadłem, nie było oczywiste po pierwszym czytaniu samouczka i dokumentów, było pomysłem multiemisji.

Upewnij się, że wiesz, że domyślnie wiele subskrypcji wywoła wiele wykonań w polu Observable. Wiele subskrypcji dla pojedynczego połączenia HTTP Observable wyzwoli wiele identycznych połączeń HTTP, chyba że Ty.share() (umożliwisz multiemisję).

Obietnica zmusza cię do radzenia sobie z jedną rzeczą na raz, rozpakowywania danych, obsługi wyjątków, ma obsługę języków dla fajnych rzeczy, takich jak async / czekaj, a poza tym jest całkiem prosta.

Obserwowalny ma wiele dzwonków i gwizdków, ale musisz zrozumieć moc, z którą pracujesz, w przeciwnym razie może zostać niewłaściwie wykorzystany.


2

Obietnica:

Asynchroniczny moduł obsługi zdarzeń - obiekt Promise reprezentuje ostateczne zakończenie (lub niepowodzenie) operacji asynchronicznej i jej wynikową wartość.

Składnia: nowa obietnica (executor);

Na przykład:

var promise_eg = new Promise(function(resolve, reject) {
  setTimeout(function() {
    resolve('foo');
  }, 300);
});

promise_eg.then(function(value) {
  console.log(value);
  // expected output: "foo"
});

console.log(promise_eg);

wprowadź opis zdjęcia tutaj

O Promise: ma jeden potok, więc zwróci wartości tylko raz, gdy zostanie wywołany. jego jednokierunkowy moduł obsługi, więc po wywołaniu możesz nie móc anulować. przydatna składnia, w którą możesz się bawić, kiedy (), a potem ()

Obserwowalne:

Obserwowalne to leniwe zbiory wielu wartości w czasie. to naprawdę świetne podejście do operacji asynchronicznych. można to zrobić za pomocą rxjs, który ma obsługę wielu platform, może używać z angular / reagować itp.

działa jak liniowiec. może być wiele potoków. więc po zdefiniowaniu możesz zapisać się, aby uzyskać wyniki zwrotów w wielu miejscach.

Składnia: import * as Rx from "@reactivex/rxjs"; do init:

Rx.Observable.fromEvent(button, "click"),
Rx.Subject()

itp

subskrybować: RxLogger.getInstance();

Na przykład:

import { range } from 'rxjs';
import { map, filter } from 'rxjs/operators';

range(1, 200).pipe(
  filter(x => x % 2 === 1),
  map(x => x + x)
).subscribe(x => console.log(x));

Ponieważ obsługuje wiele potoków, możesz subskrybować wyniki w innej lokalizacji, wprowadź opis zdjęcia tutaj ma wiele możliwości niż obiecuje.

Zastosowanie: ma więcej możliwościmap, filter, pipe, map, concatMap etc


2

Podstawowa różnica między obserwowalnymi a obietnicami to:

wprowadź opis zdjęcia tutaj


2
Proszę edytować swój post i pokazać rzeczywistą zawartość jako tekst zamiast screenów. Inni nie mogą kopiować ani wklejać z twoich zdjęć. Zobacz tutaj, aby uzyskać szczegółowe informacje. Dziękuję Ci.
Pang

1

Obserwowalne są często porównywane do obietnic. Oto kilka kluczowych różnic:

Obserwowalne są deklaratywne; obliczenia zaczynają się dopiero po subskrypcji. Obietnice wykonują się natychmiast po stworzeniu. To sprawia, że ​​obserwowalne są przydatne do definiowania przepisów, które można uruchamiać, gdy tylko potrzebujesz wyniku.

Obserwowalne dają wiele wartości. Obietnice zapewniają jedno. To sprawia, że ​​obserwowalne są przydatne do uzyskiwania wielu wartości w czasie.

Obserwowalne rozróżniają łańcuchy i subskrypcje. Obietnice mają tylko klauzule .then (). To sprawia, że ​​obserwowalne są przydatne do tworzenia złożonych receptur transformacji do wykorzystania przez inne części systemu, bez konieczności wykonywania pracy.

Observables subscribe () odpowiada za obsługę błędów. Obietnice popychają błędy do obietnic dziecka. To sprawia, że ​​obserwowalne są przydatne do scentralizowanej i przewidywalnej obsługi błędów.

To najprostsza różnica, jaką można znaleźć w dokumentach ANGULAR.IO. reszta odpowiedzi jest udzielana przez większość jest poprawna na swoim miejscu


1
  1. Obietnice skupiają się tylko na pojedynczych wartościach lub rozwiązaniach, obserwowalne są strumieniem danych.

  2. Obserwowalne można anulować, ale obietnic nie można anulować.

Najmniej znany, przynajmniej dla mnie, to

  1. Obietnice mają zawsze charakter asynchroniczny, ale obserwowalne mogą być zarówno synchroniczne, jak i asynchroniczne.

0
  1. obietnica jest chętna, podczas gdy obserwowalność jest leniwa,
  2. obietnica jest zawsze asynchroniczna, podczas gdy obserwowalna może być synchroniczna lub asynchroniczna,
  3. obietnica może zapewnić jedną wartość, podczas gdy obserwowalne to
    strumień wartości (od 0 do wielu wartości),
  4. możesz zastosować operatory RxJS do Observable, aby uzyskać nowy, dostosowany strumień.

-1

Obserwowalne i obietnice pomagają nam pracować z asynchronicznymi funkcjami JavaScript / maszynopisu. W wielu przypadkach są bardzo podobne, jednak nadal istnieją między nimi pewne różnice.

wprowadź opis zdjęcia tutaj


1
Proszę edytować swój post i pokazać rzeczywisty tekst zamiast screenów. Inni nie mogą kopiować ani wklejać z twoich zdjęć. Zobacz tutaj, aby uzyskać szczegółowe informacje. Dziękuję Ci.
Pang

Oprócz tego, że nie kod, ale zwykłe informacje, więc myślę, że można opublikować go jako obraz
Alator

1
przestań kopiować wklejanie z filmów z youtube Kudvenkata. Głosuj ode mnie! :)
Pratik

-2

Istnieje już wiele odpowiedzi na ten temat, więc nie dodam zbędnych.

Ale dla kogoś, kto właśnie zaczął uczyć się Observable / Angular i zastanawia się, którego użyć, porównać z Obietnicą , poleciłbym zachować wszystko Observable i przekonwertować wszystkie istniejące Obietnice w twoim projekcie na Observable.

Po prostu dlatego, że sam framework Angular i jego społeczność używają Observable. Byłoby więc korzystne, gdybyś zintegrował usługi frameworku lub moduły stron trzecich i połączył wszystko razem.


Chociaż doceniam wszystkie opinie, ale wciąż nalegam na moją opinię powyżej, chyba że ktoś umieści odpowiedni komentarz, aby wymienić kilka scenariuszy, które mogą być nadal przydatne w twoim projekcie Angulara, aby użyć Obietnic zamiast Obserowaczy.

Oczywiście, żadna opinia nie jest w 100% poprawna we wszystkich przypadkach, ale przynajmniej uważam, że 98% czasu na zwykłe projekty komercyjne realizowane w Angular, Observable jest właściwą drogą.

Nawet jeśli nie spodoba ci się to na początku Twojego prostego projektu hobby, wkrótce zdasz sobie sprawę, że prawie wszystkie komponenty, z którymi współpracujesz w Angular, a większość przyjaznych dla środowiska frameworków Angular używa Observables, kończyło się to ciągłym przekształcaniem Obietnicy w Observable w celu komunikowania się z nimi.

Składniki te obejmują między innymi: HttpClient, konstruktor formularzy, moduły / okna dialogowe materiałów Angular, sklep / efekty Ngrx i bootstrap ngx.

W rzeczywistości jedyną obietnicą z ekosystemu Angular, z którą korzystałem w ciągu ostatnich 2 lat, jest APP_INITIALIZER.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.