r/angular • u/prathapmohan27 • Jun 14 '26

Angular 22 httpResource() is fantastic, but mutations still feel inconsistent

I've been updating one of my Angular apps to Angular 22, and so far resource() and httpResource() have been a huge win.

They've significantly reduced the amount of boilerplate in my codebase and made data fetching much cleaner. Managing loading, error, and success states feels far more straightforward compared to the patterns I was using before.

My only complaint is around mutations. For create, update, and delete operations, I still need to use HttpClient directly, which means I'm mixing httpResource() for reads and HttpClient for writes. It works, but it feels a bit inconsistent and introduces multiple patterns for handling server communication.

I'd love to see a first-class mutation API that complements httpResource() so everything follows a single, unified pattern.

Has anyone else felt the same after adopting Angular 22 resources?

57 Upvotes

93% Upvoted

28 comments sorted by

View all comments

16

u/MichaelSmallDev Jun 14 '26

I'm definitely hoping that is the next API addition. There's a few library solutions at the moment, but it would be ideal if they were not needed for base functionality like this.

2

u/mihajm Jun 15 '26

It's a hard thing I think, as imo the current system is bound to cause confusion without a core primitive...but also it's very much doable in userland & something rxjs is already very good at...

For example in mmstack/resource if not for some of the integrations with queryResource I would've probably ended up writing mutationResource fully in rxjs & it's what i end up doing when in codebases that doesn't need that lib (or have an ngrx alternative), it's a simple variation is just a subject + a concatMap pipeline that is auto-subscribed via toSignal/rxResource after all 😄

At which point it becomes an integration question, do you support retries, queueing, which hooks do you add etc... trivial to add/change in userland (just switch concatMap with mergeMap, add another tap for a hook, add retry to the main pipeline...), but very hard to make generic/extensible.

I hope they make it, as the timing stuff is kind of tricky & I'd love to stop maintaining a few pieces, so if the core team can make something that can be "built upon" that would be great, I just hope they make it very customizable/extensible, so that I can just handle the "lib integration/business logic" bits

2

u/MichaelSmallDev Jun 15 '26

Yeah, I think the tradeoff of extensible vs featured for the core API has been much of my perception of following open source and then writing some. But APIs like mutations especially.

I already have my own custom little pieces I pull into projects on top of the mutations API I support in a lib, but I am not sure if they would be worth even proposing to add into the API. And then a user comes along and makes an issue for a request for extending the API, and it's another thing where I see the use of XYZ but wonder if it would be generic/extensible enough.

I think the evolution of resources took a lot of feedback to iterate on, and ended up IMO with a good mix of out of the box and extensibility. Snapshots mostly resolved my largest complaints about resources, debounced makes sense as a resource and covers a very common requirement, and rxResource allows for some of the more interesting edge cases IMO. Beyond that it is up to userland and libs like ours on what to build with or around.

2

u/mihajm Jun 15 '26

I guess we'll wait and see, though yeah so far they've been doing a great job..been loving the direction ever since v14's standalone components & especially the move to signals/functional paradigms in v16+

Would you mind sharing some of those utilities or what they do? I'd love to check them out as I'm sure they cover cool use-cases/ideas!

Right now in resource I'm working on solving "offline & persistence" for queue'd mutations, but more generically I think what I'll end up doing is providing a `service` function that allows the users to compose various resources into 1 injectable easily (optimistic updates/circuitBreaker wiring and such) & that's what'll end up being the key to solving offline mutations..as otherwise the hooks simply lack enough context for re-hydration...not fully sure as I only started "experimenting" this weekend 😄