[Feature Request] - for the httpclient keep toPromise method after rxjs 7 (removed in rxjs 8)

[p3x-robot]

🚀 feature request

Relevant Package

This feature request is for @angular/common/http

Description

https://indepth.dev/rxjs-heads-up-topromise-is-being-deprecated/

Describe the solution you'd like

It looks like rxjs topromise is being deprecated. Could we have this method keep in the http client? It will again breaking and useless refactor, while has a valid method for the http client.

Describe alternatives you've considered

We would not like to refactor our codebase because rxjs will be breaking again and it is not adding an additional method after rxjs topromise is removed in rxjs v8.

[pshurygin]

I agree that httpclient should provide a way to handle requests with both observable and promise. The reality is that a lot of the http calls do not require any additional rxjs operations, and maintaining a subscription in this case just adds a lot of boilerplate code when you can simply write a single await statement instead.

The proposed refactoring to lastValueOf really adds nothing to your code, so it will just be a lot of pointless work to do if you have lots of toPromise in your app.

[p3x-robot]

yes, for usually, a one time request - mostly, it is much beautiful to use await and try/catch instead of callback-hell. event emitter is good for rxjs, but for http requests? pointless. await is the way to go.

[destus90]

I think that most users have a provider which is registered for the APP_INITIALIZER token. In this case, we can provide only a promise, not an Observable. So it would be great to have non-breaking code, as we could get some config file from our server with HttpClient.

[Airblader]

but for http requests?

Not pointless, as HTTP can have streaming responses, or you can request the individual events rather than the response body. This is the rationale for the design using observables.

Changing the API — which is not what this issue is asking for, is an even bigger breaking change than the rxjs change being discussed here. Many applications use HTTP requests in observable pipelines frequently and excessively.

---

Could we have this method keep in the http client?

It's not a method of HttpClient, though. HttpClient returns rxjs observables, so Angular has no control over what methods those have.

If Angular had a custom extension like PromisableObservable which is returned from HttpClient, it would only work directly on that, which would leave to the following odd and inconsistent behavior:

httpClient.get(...).toPromise(); // This would work
httpClient.get(...).pipe().toPromise(); // This would not work

If you have a specific idea in mind on how Angular should continue to support this themselves, can you elaborate on it perhaps?

[Airblader]

By the way, a migration from toPromise to lastValueFrom can very likely be done automatically through a code migration. IMO that should be more than sufficient.

[Airblader]

Side note:

I agree that httpclient should provide a way to handle requests with both observable and promise.

There's no way to type such an API in a way that wouldn't require you to change every usage in your app, which you said you wouldn't want to do. You cannot just return a type union of observable and promise as then neither calling pipe/subscribe nor then/await would work. You'd have to either have separate methods for returning promises or pass it as a flag to each request (similar to responseType).

There's also a trivial way to go from observable to promise, that way simply slightly changed now to have clearer semantics, so offloading this burden into the HttpClient API would needlessly increase complexity and bundle size.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.