add default value to resource and rxResource

[robertIsaac]

Which @angular/* package(s) are relevant/related to the feature request?

No response

Description

I'm experimenting now with the new resource and rxResource new APIs and one thing that is a bit hassle is that it adds undefined to the the type of it
for example I find myself needing a lot to do resource.value() ?? [] because before I was making the signal value empty array till the value is loaded

Proposed solution

is to add initial value to the ResourceOptions
points to be discussed

1. if hasValue() should be true or false if it's the initial value
2. when resource.reload() is called if it should return to the default value or not

Alternatives considered

is to keep using ?? initialValue

[JeanMeche]

This cas can be directly adressed by an additional computed right ?

[sbarfurth]

This cas can be directly adressed by an additional computed right ?

It could. But then I would ask: why does toSignal offer this functionality and not resource? It seems that both serve similar purposes on the surface.

[robertIsaac]

This cas can be directly adressed by an additional computed right ?

but isn't the whole purpose of the resource API to make it easier for developers to use signals, we can achieve everything without resource at all
but I guess we can do a reusable function that take the resource and default value and do this functionality if the Angular team doesn't want to make it part of the API

and I want to double down on what @sbarfurth mentioned, the migrating current http calls from toSignal to rxResource will be more tedious since toSignal has initial value while resource doesn't, specially that using hasValue() doesn't remove undefined from the type of value()

[JeanMeche]

using hasValue() doesn't remove undefined from the type of value()

hasValue() is a type guard defined as hasValue(): this is WritableResource<T> & {value: WritableSignal<T>};

value is defined as value: Signal<T | undefined>, calling hasValue() will remove undefined from the signature of value.
But if you typed you resource in a way where T includes undefined, it can indeed return undefined.

What could be indeed argued is asking to go toward the direction TanStack query did:

• having an optional defaultValue
• returning the latest value and not reset to undefined on reload

[robertIsaac]

@JeanMeche and what do you think about hasValue?
should it be true or false if the current value is the initial value and the resource status is Loading?

[JeanMeche]

In my opinion, if we have a default value and the value is never undefined, hasValue doesn't serve any real purpose. isLoading() would be the main operator we would use.

Also, I want to make sure that I'm speaking for the team but sharing my current opinion here. The pros and cons need to be discussed.

[robertIsaac]

yeah you are right
I have a question, what happens right now when you request reload and the reload face an error? does the value kept as what it was before the reload, or does it reset to undefined?

[JeanMeche]

I think we have a bug on this part. I've open #58855 to address it. On error we should set value to undefined and reflect that on the status.

[robertIsaac]

I think we have a bug on this part. I've open #58855 to address it. On error we should set value to undefined and reflect that on the status.

so on error I guess we should also make it initial value instead of undefined as well

[mauriziocescon]

Umh... a bit confused about what we're talking about in this ticket. Is it initialValue or fallbackValue?

I do agree an initialValue is highly desirable while I don't see the added value of a fallbackValue (at least at the moment). What I'd like instead of a fallbackValue is the following #58602.

As for the initialValue, here is a concrete example: at app loading time, an app might want to fetch user-data based on some tokenisation mechanism. A slice of such info might be subjected to change over time and therefore be re-fetched (for example based on some server push mechanism saying "hey something new for you, refetch the resource").

Here is what I'd do:

  userPermissions = rxResource({
    loader: () => this.userClientApi.getPermissions(),
    initialValue: {...} // provided at resource init
  });

So: userPermissions value is already available at resource creation time and what I might need to do is simply userPermissions.reload(). In case of errors, I'd like to use #58602 to decide what to do... but not fallback to initialValue.

My 2 cents!

[robertIsaac]

@mauriziocescon if the type doesn't have undefined, the value should never be undefined even if it errors, that's why it should revert back to the initial value instead of undefined, e.g. if it's an array, then I want in error to be empty array not undefined