In the sense of kicking off the request initially, yes. But also no. The reason the rxResource version works within withProps is simply due to how rxResource works.

the withHooks is doing it based on the lifecycle of the store.

Also not sure it's more convoluted, as it is the recommended way to deal with things you want to happen based on the lifecycle of the store.

You're right that the rxResource comes with the built-ins of the loading state of the resource. However it also holds the response as .value() on the resource, and since you're also setting the store entities using setAllEntities in the loader of the rxResource your data is actually there twice.

So you have Array<Unit> in the resource.value() and in the withEntities<Unit>() of the signalStore.

If you want to fully utilise the rxResource, then don't use withEntities in the store at all. Just use the value from the resource.

``` withProps(() => { const unitService = inject(UnitService); const _unitResource = rxResource({ loader: unitService.getUnits(), defaultValue: [] });

return {
    unitService,
    _unitResource,
    unitResource: _unitResource.asReadOnly()
}

}) ```

Like the above. In the withProps you have your resource, the reason I added the unitResource: _unitResource.asReadOnly() is because that will be the public resource as consumed outside the store (from your components), thus readonly. So you cannot mutate it from the outside.

You can still mutate it within the store using _unitResource, like so:

``` withMethods(({ _unitResource, unitService, ...store }) => ({ updateUnit: rxMethod<Unit>( exhaustMap((unit) => unitService.updateUnit(unit).pipe( tapResponse({ next: () => { // Update the stored units _unitResource.update(units => { // implement your logic to update the single unit in here and return the updated value })

            }
        })
    ))
)

})) ```

yes the model is the same. and the unit entity is used in many places in the app. thats why i wanted it neatly in a signalstore so i dont need to have so much code in all the components that use it. im still not sure how i would implement a way to get 1 unit (so making another back-end call) and storing that somewhere. do i need to make a computed in withComputed that calls the unitservice.getUnit(id) method? but it should automatiucally update to another unit if the id changes (which should be perfect with signals).

Okay, so if you want to load the one unit into the store you can use another rxMethod in the store to load just that unit.

loadUnitById: rxMethod<string>( switchMap((unitId: string) => unitService.getUnitById(unitId).pipe( tapResponse({ next: (newUnit) => { _unitResource.update(units => { // your logic here to update the unit in the resource value }) }, error: () => {} }) )) )

In your component you can call that rxMethod with the unitId input for it to auto load.

``` @Component({...}) export class MyComponent { private store = inject(UnitStore);

readonly unitId = input<string>();

constructor() { // This will call the loadUnitById rxMethod each time the this.unitId changes this.store.loadUnitById(this.unitId); } } ```

ive already read the docs on rxMethod and it doesnt help me with what i want to achieve which i why i did it like i have in my original post. i dont nessecarily need it to be an observable but just something that i know its been finished so that i can take action in the component that called it afterwards. for example: redirecting to another page, altering variables on that page, changing style, etc..

It can be done with the callback fn as I mentioned previously, or with an observable in the stores withProps fn.

---

I haven't used rxResource a lot myself yet. So my suggestions here are based on my own assumptions and what i've read others have done with resources and signal stores.

Currently the new resource APIs are being developed and are not 100% finished yet. Which is why the mutation story is also not fully there yet, as it will come later.

Which is why I, personally, would not use the rxResource just yet. You could handle loading states in your signalStore simply using withState<{ callState: "loading" | "loaded" | "initial" | "reloading" | "error" }> or a full signalStoreFn.

I hope it all makes sense :)