I guess using a debounce on the search before setting the search signal value, would be a better option to avoid all those ugly canceled calls in the console
Ta for the tutorial. IMHO I think that cancel request is still not ideal. A denounce time from rxjs would be better. Mixing the interop api between signals and observables
One can definitely 'naively' use httpClient (just wrap the get()-call in firstValueFrom() to transform to a promise). However, I don't see anything in the current resource API/documentation that would integrate with HttpClient's cancel()...
I guess using a debounce on the search before setting the search signal value, would be a better option to avoid all those ugly canceled calls in the console
Ta for the tutorial.
IMHO I think that cancel request is still not ideal. A denounce time from rxjs would be better.
Mixing the interop api between signals and observables
Agreed. The damage may well be done by the flood of requests.
great video
Thank you!
Thnx again
Damn, I dont like to use abort signal. It's too dirty on the console. I wonder how it will implement using rxjs + resource.
Thanks for the explanation! Can we use httpCliente with Resource() ? Does httpCliente also have a method with AbortSignal?
One can definitely 'naively' use httpClient (just wrap the get()-call in firstValueFrom() to transform to a promise). However, I don't see anything in the current resource API/documentation that would integrate with HttpClient's cancel()...
@@NikiHerl Thanks for the help! 👍
You can tell it to use the http client
Instead of abort cant we go ahead with debounce functions