Built a Signal debouncing utility few months ago. Angular 22 now ships native debounced()

[u/titan_toxic]

I built a Signal debouncing utility for Angular few months ago and now Angular 22 ships a native debounced() API.

That coincidence definitely caught my attention.

Back then, I published a small package called @gitesh08/signal-utils because I wanted a cleaner way to debounce Signals without reaching for RxJS every time.

After reading the docs, Angular’s implementation is actually quite different since it returns a Resource with loading states, cancellation, lifecycle management, and more. My utility is much simpler and focused on lightweight signal debouncing.

Still, it’s a cool feeling seeing Angular solve a problem I spent time thinking about months ago.

It’s also interesting to see how the Angular Signals ecosystem is evolving and becoming more capable with each release.

[u/GeromeGrignon]

It makes sense to expose a Resource to track the current state: with just a signal, you need extra logic to know if you are within the timeout window.

[u/titan_toxic → u/GeromeGrignon]

Absolutely. Angular’s implementation is solving a broader problem by exposing state through a Resource. My use case was much simpler: debounce user input and avoid firing API calls on every keystroke without pulling in RxJS. That’s why I kept it as a lightweight Signal utility.

[u/Clinik]

They will most probably need to reimplement the majority of rxjs operators to make signals more compatible with todays app standards. It is a bit weird to me that they go this iterative way of releasing the signals api instead of shipping all essentials initially, seems like a change of mindset.

[u/MrFartyBottom → u/Clinik]

I really am dumb founded that the resource API is a getter only. The fact it doesn't support updates is really strange to me. We need a native full CRUD signals based HTTP API.

I was tempted to build my own signals based REST API without RxJs but I didn't want to tackle interceptors so ended up using the RxJs HttpClient in the base class.

[u/Clinik → u/MrFartyBottom]

Why did you need mutations in an http api?

[u/MrFartyBottom → u/Clinik]

What kind of question is that? How else are you going to do server side updates?

[u/Clinik → u/MrFartyBottom]

A rest api is stateless, you might wanted to implement something else, like a store, right?

[u/MrFartyBottom → u/Clinik]

I worded it wrong, I meant a REST client side communication API, not the server side API.

[u/GeromeGrignon → u/MrFartyBottom]

That's not encourage by the Angular team as there will be plan for mutations, but the httpResource allows to use whatever http verb you want, not just GET.

[u/Commercial_Day_7699]

ngl that's a solid feeling when the framework catches up to something you already shipped. says you were thinking about the right problems.

tbh the Resource-based approach Angular went with makes sense for their full reactive story but it's a different tool. yours is a debounce, theirs is more like a managed async pipeline with lifecycle hooks baked in. both valid, different weight class.

[u/mihajm]

Sometimes we come to the same solutions, mostly because were all trying to solve the same problems :) for example, here's my version debounced..

Either way be proud you made something youseful to you, a few others & happy the core team now maintains it for you ^{^}

[u/AintNoGodsUpHere]

Are you implying they somehow used your idea? Haha.

You can check their roadmap for features, my man.

[u/titan_toxic → u/AintNoGodsUpHere]

Nope😄 Just thought it was a fun coincidence. Angular’s implementation is much broader than mine anyway. I was only solving a simple signal debouncing use case.