39

I have watch a few courses on Angular and have found there are different ways to manage data from an Http request.

  • Using Observables, .map(), .subscribe()
  • Using Promises, .toPromise(), .then(), .catch()

I have used toPromise() in my application as I find it similar to the AngularJS Http services.

In what scenario would I need to use Observables?

shammelburg
  • 6,974
  • 7
  • 26
  • 34
  • 3
    Angular2 relies on `Observables` heavily. I'd rather use `subscribe()` for consistency. – j2L4e Sep 01 '16 at 08:53

3 Answers3

36

If you like the reactive programming style and want to be consistent within your application to always use observables even for single events (instead of streams of events) then use observables. If that doesn't matter to you, then use toPromise().

One advantage of observables is, that you can cancel the request.

See also Angular - Promise vs Observable

David Pine
  • 23,787
  • 10
  • 79
  • 107
Günter Zöchbauer
  • 623,577
  • 216
  • 2,003
  • 1,567
  • 2
    I would only add the nice example of Observable advantage in tutorial: https://angular.io/docs/ts/latest/tutorial/toh-pt6.html#!#-_observable-s (deferred search) – Bartek Cichocki Sep 01 '16 at 07:48
  • 2
    What if you know that a particular piece of data is fixed and not a stream? Surely, that should be returned as a Promise? It sounds like a waste of resources to set up a subscription to an Observable for data that you know is not going to change over time. – ChillyPenguin Sep 26 '18 at 02:17
  • Waiting for completion of a promise is not that different to subscribing. If you think this negatively affects performance you should do your own benchmarks. Without benchmarks that checks critical code, it's probably premature optimization to avoid promise for performance reasons. – Günter Zöchbauer Sep 26 '18 at 02:55
  • Except that a subscription to an Observable doesn't actually complete; it sits there listening for changes until you unsubscribe or your app finishes. Is that not how it works? – ChillyPenguin Sep 26 '18 at 04:49
  • 2
    A quick search revealed https://medium.com/@benlesh/rxjs-dont-unsubscribe-6753ed4fda87 that you might find helpful. When an observable is closed you don't need to unsubscribe. If you have an observable like http it will close after one event, for others you can use `first()` to transform it to one that closes after one event. – Günter Zöchbauer Sep 26 '18 at 05:09
28

I think as long as the response is not a data stream that you're going to use, then you'd better use the .toPromise() approach, because it's meaningless to keep listening to a response that you don't need and it's not even going to change.

UPDATE

.toPromise() is now deprecated in RxJS 7, they replaced it with something better firstValueFrom and lastValueFrom.

So your code should look like this:
await lastValueFrom(httpRequest$)

For more info about this check these links:
https://rxjs.dev/deprecations/to-promise
https://www.youtube.com/watch?v=3aeK5SfWBSU

Tariq Saeed
  • 1,154
  • 1
  • 10
  • 15
1

Default http requests in angular emits observables. It can be converted to promise by calling toPromise(). But it is not required. Angular unsubscribes the http request once it gets resolved by calling

   `_xhr.removeEventListener('load', onLoad);
    _xhr.removeEventListener('error', onError);
    _xhr.abort();`

Observables are cancellable, but promises are not.

The open request remain even after the component gets destroyed leading to memory leakage, which can be prevented by unsubscribing the observable or calling the destroy method once the component gets destroyed. Ways to unsubscribe to prevent memory leaks

Conclusion, better to use observables with memory leak prevention techniques.

sridharan jayabal
  • 11
  • 3