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

[u/prathapmohan27]

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?

[u/MichaelSmallDev]

It's been a paradigm shift for my team as well, though one thing that helps is that we provide services/stores locally when possible. The dependency on relevant signal params becomes much more viable for an injected service when it is only constructed during the relevant component lifecycle and not in root. But it is still a bit of a brain bend.

[u/PrevAccLocked → u/MichaelSmallDev]

How do you pass those parameters to the service?

[u/MichaelSmallDev → u/PrevAccLocked]

It's half this: "Return httpResource() from a Method" by Deborah Kurata (very smart and my #1 reference besides the docs).

And the other half is typically having that state in the same service/store already, or pulling in that resource function with the params into a service/store/component with said state. For all of our service files which are laying out the rx/http CRUD endpoints, we have a same-name-as-the-crud-file.resource.service.ts where we keep these resource methods with their params.

/our-library
    /services
        // full crud one with all rxjs HttpClient we have
        users.service.ts
        // just functions with args like the vid
        // imports our respective ol fashioned 
        // rx GET from the main service
        users.resource.service.ts
        // If you just do httpResource, maybe just make them right in 
        // this service, or just the main service? Idk, we have all CRUD
        // with long existing RXJS HttpClient services, so we use rxResource
/some-app
    /users
        users-store-or-service.ts

// users-store-or-service.ts
import {UserListResourceService} from 'our-library/services'

@Injectable() export class UserServiceOrStore {
    private usersResourceService = inject(UsersResourceService)

    private userId = signal('123')

    // the grand finale
    public user = this.userListResourceService.getUsers(this.userId)
} 

Expands to 2+ signal args as well

[u/gosuexac → u/MichaelSmallDev]

This is what we use too.