rxjs observable.pipe (take (1)) против toPromise - PullRequest
Новая
       13

rxjs observable.pipe (take (1)) против toPromise

0 голосов
/ 29 мая 2019

Недавно я был переведен в новый проект, в котором используется angular 6 в качестве оболочки внешнего интерфейса и пружина для служб REST.

Проект находится в разработке уже 2 года, и я заметил, что почтивсе HTTP-запросы, сделанные с помощью углового HttpClient, затем передаются для получения фильтра от rxjsВсе REST API выдают только одно значение.Нет необходимости в ручной отмене и свойстве ленивости наблюдаемых.

Моя интуиция заключается в том, что использование toPromise () было бы лучшим способом кодирования.

Что вы думаете? 

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

Мой предложенный подход: 

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

Я думаю, что мой подход лучше, потому что он строго типизирован и чище.

Ответы [ 2 ]

1 голос
/ 29 мая 2019

Переход от наблюдаемых к обещаниям - это шаг назад.

Это похоже на переход с Porsche 911 на Fiat multipla.

Так что нет, вы не должны использовать toPromise(), и нет, ваш путь не "лучше" (это эго, приятель!)

Я думаю, что мой подход лучше, потому что он сильно напечатан и чище.

Ввод HTTP-ответа зависит не от вида или наблюдаемого, а от самого разработчика. И чище это вопрос перспективы, лично я ненавижу видеть toPromise() с.

И главный недостаток вашего решения заключается в том, что, превратившись в обещание, вы больше не можете ничего транслировать, делая ваши функции менее универсальными.

Но их код тоже не самый лучший. Обычно такое поведение используется для магазинов и кешей, вы уверены, что не пропустили что-то?

В любом случае, если нет, и я полагаюсь только на предоставленный код, это будет правильный код: 

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

....

public ngOnInit() {
  this.customerService.getCustomers()
    .subscribe((customers) => {...})
}
0 голосов
/ 29 мая 2019

Как вы упомянули, мы можем сделать то же самое в наблюдаемом подходе. 


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
       });
  }
  • Для HttpRequest с одним HttpResponse вы можете положиться на обещание подход.
  • Но HttpRequest с несколькими ответами, такими как прогресс / поток данные (большой двоичный объект) для подхода Observable .

Постарайтесь использовать Observable как можно чаще, как только вы познакомитесь с вами, не перейдете на другие варианты. Так что попробуйте!

...