rxjs observable.pipe(take(1)) 与 toPromise

Question

Recently I've been moved to a new project which uses angular 6 as frontend framework and spring for REST services.

The project is in development for 2 years now and what I've observed was that almost all HTTP request made with angular HttpClient is then piped to take filter from rxjs. All REST APIs emit only one value. There's no need for manual cancellation and the laziness property of observables.

My intuition is that using toPromise() would be a better way to code.

What are your thoughts?

  //customer-service.ts
  constructor(private http: HttpClient) {

  }

  public getCustomers() {
     return http.get('/customers');
  }

  //component.ts
  public ngOnInit() {
      this.customerService.getCustomers().pipe(take(1)).subscribe((customers) => {
           //do some stuff
      })
  }

My proposed approach:

  //customer-service.ts
  constructor(private http: HttpClient) {

  }

  public getCustomers() : Promise<Array<Customer>> {
     return http.get('/customers').toPromise();
  }

  //component.ts
  public ngOnInit() {
      this.customerService.getCustomers().then((customers: Array<Customer>) => {
         //do some stuff
      })
  }

I think that my approach is better because it is strongly typed and it's cleaner.

Answer 1

Actually the accepted answer is misleading by saying that transforming an observable to a promise is like taking a step backward. Rather it's about what your needs are. as stated in Angular Documentation :

Observables differentiate between chaining and subscription. Promises only have .then() clauses. This makes observables useful for creating complex transformation recipes to be used by other part of the system, without causing the work to be executed.

And the difference between toPromise() and take(1) (or for short use operator first()), is that take(1) completes after the 1st value emitted, while toPromise waits for the last emitted value (waits for the observable to complete then resolves the last value emitted).

Another difference between observables and promises that might interest you, is that Observable subscriptions are cancellable while promises are not. As a concrete example, say your API /customers takes time but you dont need the results anymore and you navigate to another page, unsubscribing cancels the HTTP request.

Answer 2

As you mentioned strongly typed we can do the same in observable approach.

public getCustomers():Observable<Array<Customer>>  {
     return http.get<Array<Customer>>('/customers');
  }

  //component.ts
  public ngOnInit() {
      this.customerService.getCustomers()
      .pipe(take(1))
      .subscribe((customers: Array<Customer>) => {
       //do some stuff
       });
  }

• For HttpRequest with single HttpResponse you may rely on promise approach.
• But HttpRequest with multiple response such as progress/stream of data(blob) go for the Observable approach.

Try to use Observable as much as possible, once you familiar with you wont go for other options. So Give it a try!

Answer 3

I recommend to keep using the Observable way.

Why? Because later it will be easier to:

• build upcoming logic (like mapping, filtering, etc.) for planned features
• use the code, due mixing the two approach makes it harder to read/write

On the other hand you have right, your code is more readable as the code from others, but you can also change the Observable to be as good as yours (just add strong typing to it), and it still keeps the functionality and consistency of the Observables.

Answer 4

Going from observables to promises is a step back.

It's like going from a Porsche 911 to a Fiat multipla.

So no, you shouldn't use toPromise() , and no, your way isn't "better" (that's some ego there buddy !)

I think that my approach is better because it is strongly typed and it's cleaner.

Typing an HTTP answer isn't depending on pormises or observables, but on the developer himself. And cleaner is a matter of perspective, personally I hate seeing toPromise() s.

And the major drawback of your solution is that once converted to a promise, you can't pipe anything anymore, making your functions less versatile.

But their code isn't the best either. Usually this kind of behavior is used for stores and caches, are you sure you didn't omit something ?

Anyway, if not, and I only rely on the code provided, this would be the right code :

public getCustomers() {
  return http.get<Customer[]>('/customers');
}

....

public ngOnInit() {
  this.customerService.getCustomers()
    .subscribe((customers) => {...})
}