Комментарии 17
Описано все тоже самое, что и в старом. Чем новый лучше старого?
Interceptor'ы- киллер фича. По сути middleware, который работают как на отправку, так и на получение. Отличная штука. Не надо больше сервисы-обвязки городить для того, чтобы токены в заголовки проставлять.
Раньше это тоже вполне работало, в частности если нужно было токен добавить.
@Injectable()
export class AuthRequestOptions extends BaseRequestOptions {
merge(options?: RequestOptionsArgs): RequestOptions {
let newOptions = super.merge(options);
newOptions.headers.set('Authorization', 'Bearer SOME.TOKEN');
newOptions.merge = this.merge;
return newOptions;
}
}
и{ provide: RequestOptions, useClass: AuthRequestOptions }
А в 1.х ангуляре их что-ли не было?
Можете заглянуть по этой ссылке — github.com/angular/angular/commit/37797e2.
Кратко — избавляет Вас от необходимости использовать сервисы обёртки, которые разработчики пишут каждый по своему…
Из часто используемого — благодаря релизу теперь у Вас есть тип ответа JSON по умолчанию, и возможность обработки запросов (добавление хедеров, обратка ошибок и тд) более структурированно…
Кратко — избавляет Вас от необходимости использовать сервисы обёртки, которые разработчики пишут каждый по своему…
Из часто используемого — благодаря релизу теперь у Вас есть тип ответа JSON по умолчанию, и возможность обработки запросов (добавление хедеров, обратка ошибок и тд) более структурированно…
Описано как в документации…
Который раз вижу, что используют сабжект неправильно! Зачем вы такое делаете?
Первая версия была очень ограниченной, в итоге пришлось на писать свою обертку над XHR, со всеми интерсепторами, терпимой поддержкой аплоада и прочим. А эта вторая версия умеет загружать файлы (с мониторингом прогресса)?
В статье как раз пример мониторинга прогресса с загрузкой на сервер HttpEventType.UploadProgress, при загрузке с сервера было бы HttpEventType.DownloadProgress.
Пока что единственное с чем еще не разобрался, это как сделать фейковый бекенд, на Http все делалось через MockBackend. Здесь же можно легко протестировать, а вот отдельный бекенд как то не собирается.
Пока что единственное с чем еще не разобрался, это как сделать фейковый бекенд, на Http все делалось через MockBackend. Здесь же можно легко протестировать, а вот отдельный бекенд как то не собирается.
Похоже они решили вместо того, чтобы просто принимать Subject<HttpEvent>
, дать низкоуровневый апи request
, который выдает все события. Это лучше чем ничего.
Правда HttpEventType
не соответсвует XHR событиям, как понять что случился таймаут или ошибка соединения? Какого типа свалится еррор в сабскрайбера?
Еще один вопрос, клиенту попрежнему нельзя сказать какие статус коды являются успешными, а какие нет?
А с какой целью нужен фейковый бекенд? Для использования в тестах?
В этой статье вроде рабочий пример тестов с новым HttpClient.
Ну и конечно поиск по github. Отличный источник готовых примеров, с учетом распространнености Angular, то довольно быстро появляются примеры.
В этой статье вроде рабочий пример тестов с новым HttpClient.
Ну и конечно поиск по github. Отличный источник готовых примеров, с учетом распространнености Angular, то довольно быстро появляются примеры.
Особенность работы HttpTestingController в том что он вызывается сразу после самого запроса. Для тестирования так как раз и нужно. А для моих целей не совсем. Мне как раз бы лучше развести это все дело в разные места.
А я использую фейковый для эмуляции работы бекенда, пока нет самого бекенда, или пока он не поднят на environment. При этом учитывая, что фронт будет загружен на amazon и там же как то будет, потом, бекенд, то собирать временный бекенд из чего-то другого смысла нет.
Вот на старом было удобно сварганить быстренько API бекенда, чтобы показать работу системы, и по готовности бекенда переводить UI на нормальную работу, исправляя конфиг с endPoint'ами.
А я использую фейковый для эмуляции работы бекенда, пока нет самого бекенда, или пока он не поднят на environment. При этом учитывая, что фронт будет загружен на amazon и там же как то будет, потом, бекенд, то собирать временный бекенд из чего-то другого смысла нет.
Вот на старом было удобно сварганить быстренько API бекенда, чтобы показать работу системы, и по готовности бекенда переводить UI на нормальную работу, исправляя конфиг с endPoint'ами.
Ok, a in-memory-web-api чем не подходит? Я симуляцию бека с ним делал, в том числе там есть поодержка простеньких фильтров в запросе.
Он как раз на Http, а не на HttpClient. На Http можно и проще сделать. Простой пример fake-backend. Сейчас пробую через CachingInterceptor собрать для HttpClient.
Мне больше нравится json-server. На in-memory-web-api не смог настроить singular routes.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы Angular: HttpClient