question 3: I would definitely renamerequest to something likeparams. I first thoughtrequest was isloader

Sorry for not responding to any question of the RFC, but I feel that some questions are missing in the discussion.

current value

what about the behavior of the resource regarding the current value when reloading, either imperatively, or because of a request signal change. The RFC says:

Generally, in Loading state the resource has no current value, but in Reloading the resource keeps its value while reloading

This looks wrong to me. I think that depending on the UI needs, either we want to switch to a loading spinner every time there is a reload, or we want to keep the current value (and maybe display a loading spinner in addition to the value) every time there is a reload. I find it weird to force the loss of the current value when loading, which makes it impossible to keep the current value displayed.

Cancellation / unsubscription

This is actually related to Question 7.rxResource andhttpResource both rely on RxJS, which is able to unsubscribe and cancel http requests. This will happen automatically on component destroy if the resource is created by the component. But if we delegate to a service or to a library to create and return the resource, then it forces the component to pass its injector every time to properly unsubscribe (or to provide the service in the component). This isn't something that is easily discoverable, especially for non-expert developers. And it isn't very convenient either. Is there a plan to improve this, or to make it clearer that it should be done?

Testing

The common and best practice today, when not using resources, is to delegate to services to make HTTP requests. This makes it very convenient when testing the component because it's easy to mock/fake the service and make it return an observable created withof(), or aSubject. When using anhttpResource directly inside the component, we lose this ability, and are forced, AFAICT, to use theHttpTestingController to test the component. This isn't very convenient. And if the resource is
And if we keep delegating to a service to create and return resources, then is there a plan to provide a fake resource that can be used in tests, and which guarantees the contract ofResourceRef (i.e. there souldn't be an error and a value at the same time, for example)?

Note that hasValue is reactive, despite not being typed as a Signal.

Why is this the case? As an educator and mentor of many junior engineers, it's much easier to help enforce the new standards of Signals (especially in a Zoneless app) that most reactive values are marked as signals for quick grok-ability.

What would be your preference when it comes to the status type?

I may be in the minority here, but I'd actually much rather not use a TypeScript enum here and rather just use a TS union of string constants"error" | "loading" as another step towards enabling erasable syntax only on my TSConfig

Generally, in Loading state the resource has no current value, but in Reloading the resource keeps its value while reloading.

Do you consider this distinction to be useful?

Not only do I find this distinction useful, it's incredibly important for what, IMO, is the correct loading pattern of having cached results from the previous call still display in the UI while displaying a mini loading spinner indicating the refetching behavior.

All apps should have:

• Loading state
• Error state
• Data state
• Refetching state

Does theType-safe HTTP responses work withStandard Schema? It might be an "easy" way to support adding in support for many community validation libraries such as ArkType, Valibot, and soon even Yup.

Ultimately I like the idea of not having to use TypeScript generics to cast type-safe values at all.

One thing that I also find quite strange in the API is thereload() method. It's in the baseResource interface, so all implementations must define the method. But it can returnfalse to indicate that it's not supported. So the API recognizes that all resources should not be reloadable, but there's no way to know if they are or not. Shouldn't the API have aReloadableResource interface that extendsResource?

My feedback comes after having used resources in both SolidJS and now Angular.
For background, I actually had implemented my own resources in userland that worked a bit more like SolidJS's shortly before resources were announced in Angular. I hadn't expected their release, so this caused a bit of friction, because they don't work exactly the same as mine. But given this background, I think I have a quite wide perspective on what can be achieved and what is still lacking in my opinion.

Regarding the questions:

Question 1: (enum vs. string literal)
I think that it doesn't really matter. But if the enums are kept, I believe that there need to be signals exposed for every possible state and its corresponding typing narrowing to avoid having to import the Status enum. (so for exampleisReloading() should be in there, for example).
Besides the enum import issue, I have a slight preference for string literals, as when you are quick and dirty debugging and printing status() in a template, the numbers aren't very meaningful, while a good old "loading" gets its meaning across much better.

Question 2: (usefulness of Reloading status)
I think exposing Reloading isn't problematic in its current state.
Reloading is in my opinion the part that needs the most work in resources. The loader should get sent the previous stored value, as well as the information of what caused the function to get called (source changed? manual reload?)
Besides that, the way things are currently implemented, resources are fairly useless for the purpose of fetch paginated lists of resources or resource lists (depending on what your definition of a resource is). I will come back to this at the end, because it's really the biggest thing that I am currently missing native support for.

Question 3: (name of resource options)
SolidJS calls the equivalent ofrequestsource. The issue with the namerequest is that it can give the impression that it is meant as the function that does the request. So I think doing it like SolidJS would be good. The other suggested names are either too long or a bit too generic (likedata).

Question 4: (streaming API)
This usage seems quite advanced; I haven't really been in the position to need this. That said the API seems to be robust and given its advanced use, I'd expect people that need it to know what they're doing. I wouldn't really have an alternative to suggest.

Question 5: (more uncommonly requested types)
I think this is a good idea. Small suggestion would be to allow XML.

Question 6: (type-safety in httpResource)
I think this is a good idea. However, there is one thing that isn't type safe: errors.I don't know if this is my Rust background talking, but I want resources and httpResources to not consider errors as less important than data.. Errors should also get an (optional) typing and an optionalparseError option! And yes, I realise, this goes against the JavaScript ecosystem with RXJS and Promises not handling this, but there is no reason to perpetuate this.

There is always much more boiler plate to write to extract errors and there just isn't a good reason for it.

Question 7:
No opinion

Now my two cents regarding resources:

• We need a way to easily handleresource lists orlist resources. I won't get into the philosophical part about what it should be called, but paginated lists based on filters is currently very hard to implement with resources.

In my limited time, I have worked on a function called listResource that I quite like (it doesn't have type narrowing, cause I'm bad at TS type juggling, but the idea is as follows).

This is how it is used:

combinedFilters=computed(()=>({startDate:this.startDate(),endDate:this.endDate(),sortBy:this.sortBy(),}));myList=listResource({filterSource:this.combinedFilters,fetcher:async(filters,pagination,notifyEndReached)=>{constnewRows=awaitfetchMore(filters,pagination);notifyEndReached(newRows.length<50);returnnewRows;},// Optional options here (this is actually the default behaviour):initPaginationValue:0,getNextPagination:(currentItemList,lastPage)=>{returnlastPage+1;},});// Some readonly signals:myList.data();myList.isLoading();myList.isLoadingMore();myList.isError();myList.isEndReached();// Some methods to reset and load more data:myList.reset();myList.loadMore();

Type definitions for those who care:

typeResourceListState="loading"|"loading-more"|"loaded"|"end-reached"|"error";interfaceListResource<Type,FilterType,PaginationType>{readonlystate:Signal<ResourceListState>;readonlyhasData:Signal<boolean>;readonlydata:Signal<Type[]|null>;readonlyisLoading:Signal<boolean>;readonlyisLoadingMore:Signal<boolean>;readonlyisError:Signal<boolean>;readonlyisEndReached:Signal<boolean>;loadMore():boolean;reset():void;mutateList(mutationOperation?:(list:Type[])=>void):void;}typeResourceListFetcher<Type,FilterType,PaginationType>=(filters:FilterType,pagination:PaginationType,notifyEndReached:(endReached:boolean)=>void,abortSignal:AbortSignal,)=>Promise<Type[]>|Observable<Type[]>;typeResourceListOptions<Type,FilterType,PaginationType>={filterSource:Signal<FilterType>,fetcher:ResourceListFetcher<Type,FilterType,PaginationType>,initPaginationValue:PaginationType,getNextPagination?:(currentItems:Type[],previousPagination:number)=>number,injector?:Injector;};functionlistResource<Type,FilterType,PaginationType>(options:ResourceListOptions<Type,FilterType,PaginationType>,):ListResource<Type,FilterType,PaginationType>;

Something like this should exist natively, because it's easy to get this wrong, between cancelation of requests when filters change, etc.

Maybe the most controversial take I have about resources (that is because my own resource implementation did this, so I may be biased):
I do not think rxResource was a good idea. Resources should be able to accept both promises and Observables. I also think that the source of a resource should be allowed to be a Signal or an Observable (or even hotter take: a Promise).

Edit: I had mentioned this in the original resource-PR, but I would also like it to be possible to accessmyResource.value() with the shorthand ofmyResource() like regular signals (SolidJS does this), but that's obviously just preference. I just like having things be used the same way everywhere.

Question 5:
Using sub-function APIs looks nice, but I’m worried about tree shaking. Will the unusedhttpResource.X() methods be removed from the final bundle?

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

I knowundefined prevents the loader from running, but our template is dictating our choice of default values. How I’ve been working around this is using an RxJsfilter() operator on therxResource loader Observable.

EDIT:

Regarding RFC question 2, my vote goes to a string union type.

Mutations
httpResource (and the more fundamental resource) both declare a dependency on data that should be fetched. It's not a suitable primitive for making imperative HTTP requests, such as requests to mutation APIs

Apologies if the expectation is to only answer the prompts. I'm primarily concerned with the decision to discourage mutations inhttpResource.

It's name implies that it's designed to interact with HTTP resources. The clearest definition of an HTTP resource is:

The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources.

RFC-9110 - 3.1 Resources

As an example, a resource could behttps://api.contoso.com/storage that hasPOST endpoint for adding items and aGET endpoint for retrieving items. (Keeping it simple to make the point)

Suggestions: ifhttpResource is meant to be considered an entirely different "resource" from the general HTTP resources, the name should be reconsidered. If not, mutations should be considered valid use-cases and supported.

When I introduce thehttpResource function to new people, what almost all get wrong at first:

userId:Signal<string>= ...;// e.g. inputuser=httpResource(`/api/user/${this.userId()}`);

instead of doing

userId:Signal<string>= ...;// e.g. inputuser=httpResource(()=>`/api/user/${this.userId()}`);

Are the overloads with static values (string andHttpResourceRequest) really needed? Is the overhead of calling the provided "computed" function that bad?

Doing it wrong does work sometimes, but of course doesn't react to changes. And if you have a required input signal, you get the error, that a value is not provided yet (of course). And that leads the junior devs on the wrong path, because then they start to setup thehttpResource in anAfterViewInit hook or similar and then things get even worse... 🙈

In my application I have only a handful of data requests, that don't use any filter parameters (from query etc.). Almost every fetch needs some parameter. So I won't miss the static overloads.

RFC question 1: in the proposed API design resource status is of type ResourceStatus enum. ResourceStatus is a convenient namespace that collects all the statuses and makes them easily discoverable. At the same time using enums in Angular templates (ex.:@if (myRes.status() === ResourceStatus.Error) ) requires exposing ResourceStatus on a component instance - this creates additional authoring friction.

I would like to see string literals as status values (likeFormControlStatus). "erasable syntax only" is one reason, but the other is, when debugging, the values are easier to read, because you don't have to remember what2 means.

RFC question 2: the experimental resource implementation distinguishes between the loading operation triggered by change to the reactive dependencies (Loading) and the one triggered imperatively (Reloading). Generally, in Loading state the resource has no current value, but in Reloading the resource keeps its value while reloading.

Yes, distinguishing between those two states is valuable.

RFC question 3: Our intention was to use a name for the parameter (currently called request) indicating that we are preparing all information necessary to make an actual request. The common point of feedback, though, is that this name might not clearly convey this intention and might be lacking context. What other name would you prefer here? On our side, we’ve also considered: params, data, requestParams, source, …

I prefersource, because that aligns withlinkedSignal. The source provides the request, it isn't the request.

And naming the functionloader/stream is inconsistent - why notstreamer? Or justload?

I would prefer (likeloadChildren orloadComponent in the routes) naming them

• loadValue
• streamValues (I'm not sure about the plural here)

RegardingrxResource the naming is harder. It don't neccessary loads only one value, it can emit multiple values (likestream). It's more like a creation function likeof orfrom or even more like aswitchMap.
Since this is an integration point to rxjs and it behaves likeswitchMap, it should be named like that?

That would open up to future overloads with something likeconcatMap etc.

I've been playing around withhttpResource today and I'm surprised to see that unlike inHttpClient, there is no way to add anHttpContext. Is that intentional? We rely heavily onHttpContext in our interceptors and without that, there is really no way for us to usehttpResource directly.

I would love to see a pattern like in AngularQuery where you can create a custom injector and inject your data when needed but without refetching the backend if the data is fresh.

exportconstinjectTodos=()=>{assertInInjectionContext(injectTodos);constapiUrl=injectApiUrl();constdataId=injectRouteQueryParams<string>('dataId');constTODO_API='todo';returnhttpResource(()=>`${apiUrl}/${TODO_API}?dataId=${dataId()}`,);};@Component({selector:'todos-list',template:` <div>{{ todos.value() }}</div>`,changeDetection:ChangeDetectionStrategy.OnPush,})exportclassTestComponent{// I expect to have only one requestpublictodos=injectTodos();}@Component({selector:'todos-list',imports:[TestComponent],template:`  <todos-list/>  <todos-list/>  `})exportclassParentComponent{}

About Q2:
It is a little bit strange that value is set to something empty when reloading is triggered reactivly.
For example I'm trying to filter a list, but when I change the filter value the list is for a moment empty until it is reloaded. I believe it would be better to keep the old value in place during loading and just replace it with the new one. It would also be less DOM changes, maybe only a loading sign, not the entire table.

RFC question 1: in the proposed API design resource status is of type ResourceStatus enum.

In all honesty, I'd say the best approach would be to have both a status and aisX signal for every possible status. It feels like a very minor thing to add and it would allow us to have the best of both worlds.

RFC question 3: Our intention was to use a name for the parameter (currently called request) indicating that we are preparing all information necessary to make an actual request.

I tend to agree thatrequest isn't a good option here because it's not the actual request so it shouldn't be called that as such.requestParams seems to come closest to what it actually is, a set of params used to make a request.

Question 3: what abouttrigger orloaderTrigger? Would make more sense to me, at least in an example like this:

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

VS.

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