Считается ли обертывание HttpClient хорошей практикой?

#angular #httpclient #angular-http-interceptors

#угловатый #httpclient httpclient #angular-http-interceptors

Вопрос:

Я хотел бы знать, каково наилучшее практическое решение для обработки http-ошибок. В компании, в которой я работал, мы использовали для обертывания всех глаголов HttpClient с помощью собственных функций, и мы могли справляться с ошибками, добавлять заголовки токенов из этих оболочек.

Я знаю, что все это можно было бы сделать с помощью перехватчиков, поэтому мой вопрос таков: используете ли вы только перехватчики и выполняете вызовы с использованием HttpClient из ваших сервисов или вы комбинируете два метода и по-прежнему переносите все http-глаголы?

Пример простого переноса вызова Get:

   get<T>(api: string, headers?: HttpHeaders, params?: HttpParams): Observable<T> {
    return this.httpClient.get<T>(api, {headers, params}).pipe(
       catchError(error => {
       console.log(error.message);
       return throwError(error);
       }));
     }
 

Ответ №1:

Абстракция обычно является хорошей идеей, когда вы не хотите, чтобы потребители что-либо знали о используемом ими API, поэтому, когда вы замените API, потребителю будет все равно, и он не пострадает.

В этом случае я могу придумать сценарий, в котором, возможно, ваша команда заменит httpClient код некоторым кодом AngularFire, скажем, следующим:

   get<T>(collection: string, headers?: HttpHeaders, params?: HttpParams): Observable<T> {
    return afs.collection(collection)<T>.valueChanges().pipe(
       catchError(error => {
       console.log(error.message);
       return throwError(error);
       }));
   }
 

К вашему сведению (а также не так важно), afs представляет AngularFireService .

import { AngularFirestore, AngularFirestoreCollection } from '@angular/fire/firestore';

В результате мы изменили внутреннюю реализацию, но потребители не пострадали.

Это пример хорошей практики абстракции. Не самый лучший, но вполне приемлемый.

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

Обработка ошибок не сыграла в этом реальной роли.

Поэтому не считается лучшей практикой абстрагировать некоторый фрагмент кода только для добавления этой автоматической обработки ошибок.

Промежуточное программное обеспечение (перехватчик) было бы лучшим подходом, при котором вы изолируете обработку ошибок для каждого запроса и не вмешиваетесь в то, как вы получаете или обрабатываете данные (разделение проблем).

Также, например, будет очень легко добавить retry метод обработки ошибок (глобально), а не во все CRUD API, которые вы пишете (просто дублирование).

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