maybe resolver instead of loader 🤔

I would suggest naming the parameter need instead of request.

It's a reactive value that declaratively states the specific data-need to be satisfied/resolved by this resource.

The other suggestions are a bit generic IMHO. Also, source is not really accurate in my opinion.

Tbh I would go for dependency

@maxKciw dependency is maximal confusing. 👎 👎 👎

'source' is IMHO a very confusing expression. It is not the source of anything that happens in the loader. It is maybe the 'cause', but not the source. I strongly suggest using 'need'. It is a signal that shows that the resource is needed.

Agreed. Naming is hard.

I actually agree with @alxhub that if we have userId as signal and user as a resource that if user is defined then user.id should always equal userId
having user.id equal to the old userId can introduce hard to debug errors, while if user become undefined debugging will be easier

and in reality I think showing loading is better than showing the old value, because if there is delay the user might thing his action was ignored and might try to try again, imagine in a page click next page but nothing happen you might think you clicked outside the button (specially on touch screens) and can try to click again which could cancel the ongoing request and create a new one which makes the delay even longer
I know there might be cases where we'd like to keep the old value but as suggested here we can used linkedSignal to show the old value

another potential solution (but more effort from the Angular team) is to add another variant resource.keepOldValue or other better name, same as input.required and formBuilder.nonNullable that make it quiet different

and in reality I think showing loading is better than showing the old value

When using a list of items with pagination, I much prefer not to show loading states when swapping pages. It would be much better to still show "Page 1" even after the signal state has changed to "Page 2".

• It can avoid abrupt height changes to show loading state
• DOM elements can possibly be re-used instead of discarded and re-created
• That the list is loading new items can still be shown without discarding existing table/list-view

It's likely a good default to be pure, and discard current value when state changes. But it would IMO be great if there was an option for resource() to opt-in to keeping the value until we get the new response. Something like: resource({ ..., clearStaleValue: false }) (but with better naming).

So we agree that the default behavior should be to clear the current value
And it's good to have the option to opt out of this

Might be obvious but if keeping the current value, it should also keep the last response headers and status code as they're inherently tied to the state of the current value.

It's a predicate ! You use it as a signal but you don't it to be a signal 😄

@JeanMeche the fact that the RFC felt the need to specify the fact that it is reactive is quite a sign that it isn't entirely obvious. Making it a signal makes it obvious.

hasValue is a TS type guard which makes an assertion about the resource's type. This is a specific syntax for the return type that doesn't let us type the function as a Signal. If we did, we'd lose the type narrowing.

Our hope is that TS ultimately adds support for signals to be declared as narrowable ( microsoft/TypeScript#60948), in which case hasValue can potentially be removed in favor of explicitly checking the value.

With this context, I'd like to withdraw my comment. This makes a lot of sense to me

@crutchcorn just to clear this up further, I have something similar in my library

If they would make using enums in templates easy, would you still prefer union strings?

Yeah - because even when not in the template generally you have to import the enum to use it's value but with a string literal you don't have to import the type in order to check it and can just infer its value

+1 for string literals! When debugging, the value is more readable then to remember what status 3 is about... 🥸

I would rather have a const object style enum where you get the best of both worlds of being able to use the object as it if was an enum or with a string literal.

Yeah, union type > enum IMO. The arguments for the enum I have been told make sense: primarily for my sake, that the helper functions for value/status do the bulk of the lifting and prevent people from overthinking/getting too granular. But personally in my experimentation with resource as an overthinking-maxxer, I alias the enum as a component variable to be used in the template for various edge cases half the time. This is probably a good speed bump for writing application code, but when I am experimenting with library type logic I'm like "ugh".

This is a very interesting idea and something we can definitely consider.

Conceptually all resources should be able to support reloading - it's basically the same as running the loader again with the same inputs, as if the resource were freshly created. reload()'s boolean return indicates whether it actually started a reload or not.

A related question is "why is reload() on the read-only Resource type?" I think that point resonates - reloading is a kind of mutation, and if you give someone a read-only handle to your resource state, they shouldn't be able to manipulate it.

Thanks @alxhub. The documentation currently says "@returns true if a reload was initiated, false if a reload was unnecessary or unsupported". So maybe it should drop the "or unsupported" part.
In what situations can a resource decide to ignore the reload. Is it just when is it in Loading or Reloading state already, and the reload would thus cancel the current request to redo the exact same one?

reload() returns false when the status is Idle or Loading (or Reloading - Reloading actually isn't used under the hood; there's just a reload counter and if it's 0, you get Loading and if it's > 0, you get Reloading)

Thanks @wartab. That's how the specific implementation used currently works. But the interface defines a contract that this implementation and other implementations are supposed to respect. So I think it would be a good idea to make the contract as clear as possible.
Please say Hi to the Torê for me :-)

Going to co-sign that resource should be able to accept an Observable.

As far as accepting Observable, I think this is something we plan to revisit once the Observable spec lands upstream in the browser.

I agree on optional typing for errors in httpResource, that seems like a great idea!

It won't treeshake with current optimizer (esbuild), but there isn't much to treeshake it's only a different argument getting passed to a mutual function.

Yeah, tree-shaking isn't a concern here - in this case it's just a different way of passing another parameter (but so much cleaner in terms of typing).

Probably a dumb request, but can there be an Initialized ResourceStatus when the resource is first initialized? I’ve run into several use cases where I want to delay (or essentially skip) the initial resource load because the request value is tied to an input Signal where the initial value is an empty array or null value.

Would Idle work for your use-cases? If not - why?

Yes, the name "resource" is not related to the HTTP / RESTful concept of "resources". It's a name that a few different reactive frameworks use to refer to async dependencies in the reactive graph.

Gotcha. What about calling it httpQuery instead? The other two may be something like query and rxQuery.

I see solidjs uses the naming convention of resource, but I can't think of any other frameworks that do.

The better question might be: if mutations aren't meant for resource, is anything on the roadmap that is?

I know I'm using it wrong, but I love the elegance of disabling a form's submit button when myResource.loading()

This is a good point - our thinking was that "well, not all data requests need to be reactive" but you're right that it's a footgun.

I think we can consider removing the non-reactive flavors...

@ameckl Is that an assumption or a test feedback ?

I quickly updated to 19.2.1 and tested it, and while now HttpResourceRequest accepts the context parameter, it seems that is still not working. Now digging the Angular code to find evidence.

Shouldn't the context be passed here?

Good catch, That's what happen when you ship without a unit test.

The funny thing is that when I saw the PR, I was wondering about this, checked the code, got interrupted, and forgot about it

#60228 fixes this.

This should be doable in user land. Ngxtension has a injectQueryParams. The implementation would need to change to always return the same resource though.

yes tanstack query is already doing it. but I thought that would be nice to do it.

But if I'm on a route which show not a list but a specific item (e.g. a user), then I don't want to see the last user, while navigating from users/1 to users/2 (which is the same component, just the input userId = input.required<string>() changes, which is used in the request of the "userResource").

"showing the last known value" is a needed functionality, I agree, but should it be part of resource as a low-level building block?

@flensrocker So you think it would be better that all userdata is set to undefined or null when clicking on the next route? Wouldn't it be enough to have a loading animation with the isLoading() signal, because in this scenario too, it would flicker twise first removing the old user and than adding the new one instead of replacing the first with the second.

There are two sides of this "coin" for me:

• How to display it in the template.
• How to keep the resource "in sync".

Yes, you should avoid flickering, layout shift etc. in the template when changing state. But that highly depends on the usecase. What I do, when showing a list of items (think search results) and I modify the filter, I do show the old results grayed out and a progress bar to visualize, that the current list is reevaluated. The template can that reuse the components (track $index) and it#s a nicer experience.

When navigating from one entity to another, I would rather not display the old entity while fetching the new one. "Disabling" the view of the entity highly depends on how it's actually done. I often have forms, and when I set a new value to the existing form, I have to really think about, if I want to "emitEvent" or not, because the form may react to changes in fields. And distinguishing between "the field has changed because of user input" or "the field has changed because of a whole new form value is loaded" is difficult. So I rather destroy the form and create a new one, because then I have the "switchMap(form => form.ValueChanges)" kind of thing where I'm able to interrupt the "valueChanges" (it does not emit on subscribe) in a controlled way.

Both scenarios can be accomplished regardless if the resource resets to the default value (or undefined) while loading or preserving the old value, because you can visualize that depending on the isLoading() signal.

The other thing is "keeping the resource in sync". Signals are for synchronous state. And when the request signal represents "userId 2", but the resource (the request is part of the resource) still represents "user with userId 1", then the resource in itself is out of sync. That's why the resource should reset to the default value (which is undefined on default) while the value is not in sync with the request.

But that's just my opinion, we can agree to disagree. 😀 I would like to have less "built in" in the low-level resource, so it can be extended with whatever I need. And putting a "memoizeResource" around every kind of Resource<T> creating resource function is easy and a nice composition. The same is valid for caching capabilities (which I don't need in my apps).

I don't think there is any notion of "resource in sync" when you just consider "request" and "value":

// IMO equally wrong while loading

userId = '2' with resource.value = user1
userId = '2' with resource.value = undefined
userId = '2' with resource.value = defaultValue

As I see it, It's mostly a matter of picking the smartest approximation... so it would be nice to see examples where "undefined" or "defaultValue" are better than "user1" (for which clear examples have been provided).

My 2 cents!

Yes, you have to put "status" into that equation. There exist different equally valid solutions to this.
Most of the time I type such states with discriminated unions, where, for example, the value doesn't exist, when status is Idle. But that was expressed with an observable (or one signal containing the whole state { status; request; value }.
When you break out and provide signals for each property, you have to define, how to express "missing". And undefined is not the worst way to do.

Simplified example:

type Resource<R, T> = {
  status: ResourceStatus.Idle;
} | {
  status: ResourceStatus.Loading;
  request: R;
} | {
  status: ResourceStatus.Error;
  request: R;
  error: unknown;
} | {
  status: ResourceStatus.Reloading;
  request: R;
  value: T | undefined; // in this case it can be the last resolved value or "undefined" if it has never been resolved
} | {
  status: ResourceStatus.Resolved;
  request: R;
  value: T;
};

Sidenote (because of "wrong" code): Don't use the signal inside the loader, but use the value from the request object passed to the loader.

searchTerm = signal<string>(''); // used as an [(ngModel)] for an input
data = rxResource({
  loader: ({ request: searchTerm }) => this.myService.find(searchTerm),
  request: this.searchTerm
});

ok, when we use it like this, params makes more sense. So far i always just used the signal directly, so it felt like a trigger 🤔

The loader function is not executed in a reactive context, so it won't track the signal. It only works, because you use the same signal on the request and therefore it is tracked.

yes, i know - that's why for me the name trigger made sense at first^^ but you're right, if the request is passed to the loader function, then a name like params or request makes more sense.

My initial thought is that yes, the numbers be explicitly defined in the POJO. However, I'm not sure exactly how a migration from the current enum to this approach would be handled. In any case, I will say that, in my experience in my job, we use a pattern where statuses span a broad range (i.e. from 0 to 1000 or similar) and we categorize groups of statuses within that overall range, kind of like http status codes. So errors might be from 500 to 600, success might be from 200 to 300, etc. And that way, you can insert new statuses into the system very easily and still have room for more and not have to "shift" things around. That approach may be overkill for this scenario, but the concept of the POJO still makes more sense and is a much better solution than the current enum.

It's an experimental API, so breaking it is "allowed" I guess.

Reminds me of good old C64 BASIC line numbers time... 😀 But I agree, that may be overkill here.

Yeah so maybe some reduced version of that or something. Who knows!

@johnsonav1992 there is a trick to move away with full compatibility is to name the type as the object e.g.

const LogLevel = {
  WARNING: 'warning',
  ERROR: 'error',
} as const;
type LogLevel = (typeof LogLevel)[keyof typeof LogLevel];

function log(msg: string, level: LogLevel) {
  console.log(level, msg);
}

log('error message', LogLevel.ERROR);
log('error message 2', 'error');

now everything works same as before

and now typescript will use the type when you use it as a type and the object when you use it as a value :)