Angular Рекомендации по созданию Generi c метод - PullRequest
Новая
       7

Angular Рекомендации по созданию Generi c метод

0 голосов
/ 18 июня 2020

Я проектирую конечные точки Api в Angular с помощью HttpClient. Это единственный класс обслуживания, который будет обрабатывать все вызовы Rest, он будет вызываться из других классов обслуживания (которые в настоящее время выполняют вызовы Rest).

Как лучше всего сделать общий? c Rest метод. 

getApi(url: string, options?: object): Observable<any> {
    return this.http.get<any>(url, options).pipe(
      catchError((error: HttpErrorResponse) => {
        return throwError(error);
    })
  )
}

Или 

getApi<T>(url: string, options?: object): Observable<T> {
    return this.http.get<T>(url, options).pipe(
      catchError((error: HttpErrorResponse) => {
        return throwError(error);
    })
  )
}

Будет ли что-либо из вышеперечисленного сможет обработать: HttpEvent, HttpResponse или другой подобный ответ?

Следует ли использовать несколько методов обрабатывать?

1 Ответ

1 голос
/ 18 июня 2020

Обратите внимание, что ответ очень основан на мнении.

Прежде чем я покажу свое решение, я хочу поделиться с ним идеей. Итак, когда я работаю с TS, я ожидаю, что у меня будет как можно более строгих типов . Таким образом, использование any, object или чего-то подобного в данном контексте отвлекает. Я также хочу избежать лишнего приведения типов, потому что это где-то приведет к ошибке.

К счастью, TS очень умен, чтобы помочь мне с этой целью, потому что он может определять типы в зависимости от использования.

На основе этого мы можем построить что-то вроде этого:

Очень общий c класс, который может все, что нам нужно (его можно расширить с помощью передачи параметров для выборки, ведения журнала, счетчика всего, что вы need) 

class HttpService {
    get<TData, TResult>(url: string, data?: TData): Promise<TResult> {
        return fetch(url, data)
            .then(x => x.json())
            .catch((err) => console.log(err));
    }
}

Но этот класс не следует использовать напрямую. Я бы посоветовал создать более строгий и специализированный сервис, который будет изолировать выборку logi c и предоставлять строгие типы вместо обобщенных. 

type User = {
    name: string;
}

class MyDataService {

    constructor(private readonly _transportService: HttpService) { }
    fetchUserInfo(userId: number): Promise<User> {
        return this._transportService.get('/some/url', userId);
    }
}

Теперь я могу использовать MyDataService без приведения типов и угадывания типов. Еще одним преимуществом является то, что эту службу очень легко протестировать, потому что вы можете заменить транспортный модуль, как хотите.

Надеюсь, мой ответ вам помог.

...