Question 1B: What challenges do you see in your own applications with declaring data dependencies "above" components?
Almost all of our pages are categorized into either a form, a view or a list. For each of these 3 types we have a pair of component + datasource to help with loading state, error state, etc. and then the pages itself are just configuring the datasource (loadFn, saveFn, loadTrigger, etc.) and a bit of form/view/list-cell templates.

I am wondering how we would do this, if the loading would be declared above the components.

Here a short example how we do it currently:

<zv-form [dataSource]="fds">
    <div [formGroup]="fds.form">
         <mat-form-field>
            <mat-label>firstname</mat-label>
            <input type="text" matInput formControlName="firstname" />
         </mat-form-field>
         <mat-form-field>
            <mat-label>lastname</mat-label>
            <input type="text" matInput formControlName="lastname" />
         </mat-form-field>
    </div>
</zv-form>

  public fds = new ZvFormDataSource({
    form: new FormGroup(
      {
        firstname: new FormControl(''),
        lastname: new FormControl(''),
      },
    ),
    loadTrigger$: this.route.paramMap.pipe(
      map((params) => params.get('userId'))
    ), 
    loadFn: (userId) => this.http.get<User>(`users/${userId}`),
    saveFn: (formValue, userId) => this.http.post(`users/${userId}`, formValue),
  });

export declare type IZvSavebarMode = 'sticky' | 'fixed' | 'auto' | 'hide';
export interface IZvFormDataSourceConnectOptions {
  errorInView$: Observable<boolean>;
  scrollToError(): void;
}

export interface IZvFormDataSource {
  readonly form: FormGroup;
  readonly autocomplete: 'on' | 'off';
  readonly buttons: IZvButton[];
  readonly contentVisible: boolean;
  readonly contentBlocked: boolean;
  readonly exception: IZvException | null;
  readonly savebarMode: IZvSavebarMode;
  readonly progress?: number | null;
  connect(options: IZvFormDataSourceConnectOptions): Observable<void>; // this return observable notifies the view of changes. When we switch to signals, this will not be necessary anymore :)
  disconnect(): void;
}

Question 1A: What thoughts do you have on our choice of explicit over implicit async? What problems/challenges do you see with our approach? Are there other perspectives or factors we should consider?

Overall, I think explicitness async is better than implicit async. A problem that I can think of off top of my mind right now is how the template looks like when we want to kick off multiple resources. Taking the code from the RFC, the Suspense approach might look like this which looks pretty clean imo

@suspense {
  <user-info [data]="userData()" />
  <other-async [data]="otherData()" />
} @fallback {
  <loading-spinner />
}

Wondering how this would look with Resource approach. Maybe we do need to have a special construct like @async that can handle multiple resources with a single loading fallback.

Question 1B: What challenges do you see in your own applications with declaring data dependencies "above" components?

Personally, I see this in two folds. SSR and SPA. For SSR applications, this is a godsend; components don't have to deal with the platform to (re)perform fetching for the data that they need. This is also assuming that there is fallback to "fetching on the component" where the users see fit (like initiate a streamed data on user interactions etc...). For SPA though, one challenge I see is handling the loading state; maybe we can provide a UI fallback on the route level (or the level where we declare the data fetching). Overall, I think many apps will still benefit from declaring data fetching above the components; I mean I'm probably not the only one annoyed by the "flashing loading spinner". Coupled with prefetch strategies, maybe we can have a good DX surrounding this.

Question 1C: Would the resource concept or any of the ideas discussed here significantly reduce complexity or address real problems in your applications? Are there other things we should consider doing with resources that you can think of, that would make a difference in your applications?

😅 The "Future research" section kind of answered my questions above.

• Reduce complexity? Somewhat. I think we're shifting the complexity elsewhere. Components are going to be designed differently with Resource which we don't know how that will look like yet. Maybe it's for the better, maybe it's good that we have the components own their data fetching and we can drop the components anywhere without worrying about their data 😅
• Addressing real problems? Yes. The waterfall fetching is really annoying to solve with the current model. Tons of rxjs operators to orchestrate a reusable solution across the application. Also, the "flashing of loading spinner" is the bane of my existence.

EDIT: expanding on the "Future Research" section

Template API for awaiting data

I think this is desirable for both component-level data fetching as well as non-blocking data. There gotta be a consistent way to read async data on the template on the component level.

Blocking and non-blocking data dependencies
Resource streaming from SSR

Would these 2 be grouped together under one umbrella? Where if an application is SSR, then resource streaming is the default. If an app is CSR, then it's just plain non-blocking (aka resource is only kicked off by the consuming component(s))?

But this is definitely a desirable feature. In Remix, we would do something like this

export const loader = async () => {
  const lightData = await getLightData();
  const heavyDataPromise = getHeavyData();

  return defer({
    lightData, // blocking data
    heavyDataPromise, // non-blocking
  })
}

export default function MyCmp() {
  const { lightData, heavyDataPromise } = useLoaderData<typeof loader>();
  // lightData is readily available, heavyDataPromise needs Suspense to start loading in (SSR streams the response in Remix' case)

  return (
    <div>
      <p>{ lightData }</p>
      <Suspense fallback={...}>
        <Await resolve={heavyDataPromise}>
          {(heavyData) => (...)}
        </Await>
      </Suspense>
    </div>
  )
}

Prefetching data dependencies

YES!! Multiple prefetch strategies would be nice

Router loading state

I mentioned this above. This is definitely needed if we lift the data fetching above the components.

Deadlines for non-blocking data

I think this is definitely nice to have but if we could have @defer to recognize Resource then we can just use @defer with min instead of having a separate configuration point on the "above component" level.

Server-only data fetching logic

Considering most Angular apps are still SPA and probably will be SPA (unless more materials about Angular SSR that point people to choose Angular for SSR applications), this is at most a nice to have.

Retry mechanics & error recovery

I'm not sure what error recovery means when put together with retry here? Maybe Error Handling in general would be better to explore first. I personally think "retry mechanics" is userland responsibility rather than the framework but I definitely can be convinced otherwise.

Compiler-supported data dependencies

This would be nice for type-safety if we can pull this off. I personally like what the ReactRouter team achieves with Route Module or TanStack Start https://tanstack.com/start/latest/docs/framework/react/learn-the-basics

I wanna add a few short replies;

I have used the resource pattern and I love it so in that regard i prefer Explicit

I have earlier tried to use SSR/SSG with the current ways of fetching data - and I think it would be amazing to know more how things like resource would work with this

It would also be amazing to see how the server Only fetching could look

Maybe a example of the route config with resource - i have used resolve for this in the past with mixed success

Would it make sense to have a resource with a server and a client config when compiled for the two it strip's the other part i guess it would introduce some type related Challenges

1. My experience from someone who worked a lot with Observables:
I've been working with Subjects for years, and I believe using a BehaviorSubject<object | 'LOADING'> is never the wrong approach which is in your case resource. The 'LOADING' state acts as a built-in isLoading() check, making it more powerful than a ReplaySubject which is in your case suspense.

PRO: With BehaviorSubject, you always have an initial value, allowing for synchronous actions—such as updating the UI immediately on a button press you can check if its still loading, display an error, etc.
CONTRA: With ReplaySubject it doesn't provide an immediate state from buffer; you need to subscribe to it first, and if the state is currently being loaded the user might click again, and the action will execute sometime in the future, which is "wrong". To avoid that Angular would need a special mechanism to handle this directly in the html or ts - which I dont think is anyones wish.

Therefore I'm also for:

@if (userData.isLoading()) {
  <loading-spinner />
} @else {
  <user-profile [data]="userData.value()" />
}

2. I would like besides all of this that we refactor the signals to be more like BehaviorSubjects:
I like the approach of accessing .value() I wish only that it would be more consistent, I would prefear if possible that we refactor the current signals or offer instad of directly calling the function that we have the option to say .value(). Maybe all signals could implement simply that one interface cause to me it seems it would be a mess to write generic implementations.

Question 1A: that's the right choice :)

Question 1B: 1. Lack of reactivity; 2. Many components have no resolvers above - they get their params from inputs and fetch the data using these params.

Question 1C: Right now, I don't think so. APIs are not flexible enough - I can't pick between switchMap or concatMap behavior; error handling is "hardcoded." Observables offer much more out of the box, and all you need to make them eager is toSignal(). If a developer starts using httpResource for loading, they still need something else for writing. That's a weird inconsistency.

"Server-only data fetching logic" and "Resource streaming from SSR" - this sounds very interesting!

Question 1A: What thoughts do you have on our choice of explicit over implicit async? What problems/challenges do you see with our approach? Are there other perspectives or factors we should consider?

In the past I implemented something similar to a "resource" with rxjs, which pushes the state with value/error/busy, which then got subscribed to with the AsyncPipe. For me the transition to Resource<T> is painless and straight forward.

I must confess, that "implicit async" seems more difficult for me, reasoning about how the template really looks like in which state and how to display the previous value while loading the next etc.

Question 1B: What challenges do you see in your own applications with declaring data dependencies "above" components?

In my applications most of the time loading the data is done inside the component, so it can already show its title and a spinner etc. And they almost always depend on some (query)params of the route. Loading that data in a resolver may be ok - I haven't tried yet. And since I treat my route as the source of truth, loading new data is almost always triggered with a navigation - even if only the query params get changed.

Question 1C: Would the resource concept or any of the ideas discussed here significantly reduce complexity or address real problems in your applications? Are there other things we should consider doing with resources that you can think of, that would make a difference in your applications?

It's nice to have a unified way to express an (async) resource. I guess most of us implemented something like this. It will reduce complexity and makes the code more understandable for new developers, because they don't have to learn our own utilities.

Are we trying to reinvent rxjs?
I think we should stick more to js standards.
it is enough to use await/async with signals to achieve async update better than over complicating the API and then deprecate it after few iterations

1A

Say: I trust you, but I'm not 100% sure the result is set in stone 😅!

Out of the 3 points, I mostly see 2 as the real blocking issue for any concrete suspense / error-boundary approach right now. On the other hand, the ideas around createAsync explored by the solid team are very interesting.

Some of the things I like about suspense in solid v2:

• "value" undefined management is gone (annoying with resource, no matter what),
• loading / error-management follows page layouts (signals read) with a customisable granularity... rather than each data fetching,
• the code becomes pretty clean,
• more or less one way of managing code lazy-loading, async fetch with good SSR integration.

But even for solid, such things are relatively new. So again: I understand the choice!

source: https://www.youtube.com/watch?v=xnmvxWEK25I

1B

Mostly two:

• reusable components: the reusability / encapsulation comes at the cost of keeping the fetch linked to the component; reusable components fetches data based on inputs.

• route components fetching data based on many filters (list of items): similar to the previous point. Manageable at the cost of sharing knowledge on the filters between the entry component and its route.

Too early to say... but for such cases, some adjustments might be required.

1C

Difficult to say at this point, but I overall like the direction. I'd just keep a close eye on what solid is doing: as ng-devs, we're all used to an explicit (data driven) async approach, but maybe it's not the best deal we can get. Just the most convenient now!

First, I appreciate the effort the Angular team is putting into making async state management more ergonomic. Resources are a great step forward, providing a much-needed alternative to using Observables for data fetching.

However, I’d like to clarify two key points in the RFC:

1. Clarifying "Suspense" vs. Throwing Async Resources
   The RFC presents "Resource vs. Suspense" as a fundamental choice, but this actually mixes two separate concerns:

   • Nullable vs. Throwing Resources: Should resources return undefined while loading or throw errors until resolved?
   • Suspense Boundaries: A UI mechanism that catches async dependencies and shows a fallback while waiting.

   These are independent concepts—for example, SolidJS currently supports Suspense with nullable async resources and will soon support throwing async resources as well. The RFC should distinguish between these two ideas rather than treating them as a single tradeoff.

2. Exploring @defer as an Alternative to Suspense
   The RFC briefly mentions @defer, but it doesn’t fully explore its potential role in async data management.

   • @defer already behaves similarly to Suspense boundaries, allowing UI elements to render only when dependencies are ready, while also supporting placeholders.
   • Instead of introducing a separate Suspense API, it may be better to extend @defer to work with resource(), creating a unified async handling mechanism in Angular.

Suggested Refinements

• Clearly separate the discussion of throwing vs. nullable resources from the concept of Suspense boundaries.
• Consider enhancing @defer to integrate with resources, rather than adding a separate Suspense API.

Question 1A: What thoughts do you have on our choice of explicit over implicit async? What problems/challenges do you see with our approach? Are there other perspectives or factors we should consider?

Definitely explicit approach seems to be better. Also I don't understand doubts related with the question how to handle loading data from two different resources before they will be presented in template. Doesn't the rxResource is an answer on that question?

Question 1B: What challenges do you see in your own applications with declaring data dependencies "above" components?

It would be great if it could protect against waterfalling, but what if child component would be displayed only if something specific will come in the response to the query send by parent component? Does the solution would be enough smart to know that data for child component shouldn't be loaded in parallel with data for parent component?

Question 1C: Would the resource concept or any of the ideas discussed here significantly reduce complexity or address real problems in your applications? Are there other things we should consider doing with resources that you can think of, that would make a difference in your applications?

All of that looks very promising, I only wondering, how it will cooperate with state management solution.

Question 1c: Real world applications.
We are using resource in our app already and stumbled into a difficult to workaround issue in regards to resource caching.

(However, this is of course a complex use case that probably few people will enocunter.
It is also contra to the simplicity of using resource. I wrote it down to provide a real world issue and maybe there is an elegant and simpler solution than the one describe that is useful to a lot of people :) )

Scenario:
There is a table with a dropdown in each row. The dropdown options come from a REST-API endpoint. The endpoint has a parameter that is filled by another column of the table. resource({request: columnX, loader: ()=> getRestEndpoint(columnX)})

Currently it is not possible to create resources dynamically. Since the dropdown options depend on another column of the table, we cannot create a resource for each possible value in columnX.
Since there might be many rows, its not feasible to have each row send a request to the server.
What we would need is sharing the same resource over multiple rows, one resource for each result of "request".

Current solution:

• not using resource, but creating the signals and handling promise subscription manually. It looks like a resource for the row elements
• resources cannot be created dynamically, however computed and signals can, so we return a computed that eiter
  a) create a new promise and signal and send the REST-API request
  b) returns an already existing computed from a "cache"
• each row of the table has its own computed for value, loading, error but they all just reference the cache one.

Ideal solution (probably to complicated for most users):

• sharedResourceContainer/Provider -> used to create shared resources. This is usefull as a provider via DI, in case
• sharedResourceContainer.createSharedResource({ uniqueCacheKey: Signal, request: Signal, loader: ()=> Promise })
  typescript: protected readonly resource: ResourceRef<> = sharedResourceContainer.createSharedResource();
• uniqueCacheKey is used to identify if a new resource should be dynamically created and to retrieve existing ones from the cache.

Probably to complex of a scenario, but having an easy solution to this issue, would maybe make developers default to cached resources and save a lot of traffic, instead of going for the currently much easier non-cached version even though a cache would be beneficial.

Question 1A: What thoughts do you have on our choice of explicit over implicit async? What problems/challenges do you see with our approach? Are there other perspectives or factors we should consider?

I guess based on what I understand implicit is like freezing the application so it's a sync Async operation, which will block everything even the User interactions, which I will take a quote from @alxhub and say
Angular components aren't well suited to the Suspense model.
so I agree, it is not suitable for angular Unless the angular team will find a better way to define it
because what I did understand is that, the angular team thinking about moving the heavy lifting from the developer and moving it to the framework,
so using the implicit async where we move everything to the route resolver so the (smart / dumb) components will be even more ignorant about what's going on,
Regarding what i understand also about mixing implicit async and @ suspend pattern
this will have a bad UX on the users so what i need to do (( not the best option but it Might works ))
at the app.componnet.ts

@if(spinnerService.isSpinnerShowen()) {
<my-global-spinner/>
}
<router-outlet</router-outlet>

and trigger it with a root-injected service that can handle the appearance of the spinner each time a resolver runs
then i can maintain the UX for the users or any other possible solution otherwise we will send the users to the VOID

so reaching the point that i will be on the choice of explicit over implicit async

=====================================================

Question 1B: What challenges do you see in your own applications with declaring data dependencies "above" components?

1. as i mentioned above one of the challenges that we might face is the UX in like (loading , ...)
2. while lifting data fetching out of components can simplify UI component tests, it can introduce new challenges in testing the higher level logic responsible for data fetching
3. finding the right level of initializing the data dependencies can be difficult , fetching too much data at once can lead to performance issues
4. when you said > "" managing state of the application will be more easy ""
   did you mean something like NGRX (( if so )) that means adding more responsibilities to the higher level which can lead to increased difficulty in tracking and debugging state changes
   =================================================================

Question 1C: Would the resource concept or any of the ideas discussed here significantly reduce complexity or address real problems in your applications? Are there other things we should consider doing with resources that you can think of, that would make a difference in your applications?

i can't say it will reduce complexity, but what i can say it will apply the concept of making the component away from data handling and making the angular framework handle it for the developer which i see it as a good approach

Retry mechanics & error recovery
Currently resource failures can be retried only by calling .reload() imperatively. We would like to explore adding holistic support for error recovery.

it would be awesome if we have retry automatic mechanism like for example

user:Resource<user[]>= httpResource(()=>"/api/users" , {
defaultValue:[],
parser: ...,
retryIfFailes :(number of trails , ()=>{
takes a call back in case of even the number of trails fails let the user handle it 
   })
})

and still keep the .reload() imperatively

Now i want to say I love the Whole RFC and thank you so much #angular team for the hard work

Thank you @alxhub for such an awesome RFC

The Resource Architecture RFC has come to a close! We'd like to extend our thanks to everyone who took the time to read through this fairly high-level proposal and leave us their comments and feedback. As always, we're amazed by the thoughtfulness and care that our community brings to these conversations.

Based on your feedback, we're confident moving forward with our plans around an asynchronous architecture for Angular, based on resources and explicit asynchronicity.

Most of you expressed strong agreement with our proposed choice of an explicit model for asynchronicity, based around the Resource type to communicate the status of an async dependency or loading operation. You agreed with us that the large-scale drawbacks of an implicit model, where signals look synchronous but might block under the hood, outweigh the small-scale ergonomic benefits.

At the same time, many of you described use cases which highlight the complexity of this problem. Some notable examples include:

• Data which depends partly on component-specific state.
• Lists/tables where each row requires a separate fetch, including where many rows might share the same dependency.
• Cases where UI actions need to result in reloads of specific data.

Going forward, we will take these use cases into consideration both when designing future functionality with resources as well as in example code & communications.

We noted some excitement around potential benefits of this architecture, particularly around potential integrations with server-side rendering like server-only data fetching code or data streaming. Another idea which had positive responses was the concept of a template-level mechanism for awaiting a resource, largely because of how it could address some of the cases where resources might not be able to be lifted out of components.

In terms of concerns, you highlighted that like with signals, this direction is significantly different than current patterns in Angular. This is true, and we always need to weigh that tradeoff when considering such conceptual changes. We wouldn't propose such a move if we didn't believe the result would be worth it, but such a value proposition will need to be demonstrated.

In conclusion, we're moving forward with our ambitions to add first-class support for asynchronous data on top of Resources in Angular, and we look forward to engaging with you in future RFCs as these ideas develop into new designs and APIs of their own.