Deprecate derivedAsync in favor of Angular's Resource API

[eneajaho]

With the introduction of the resource API in Angular (currently experimental), we're seeing an overlap in functionality with ngxtension's derivedAsync utility. This discussion aims to gather community feedback on the potential deprecation of derivedAsync in favor of leveraging the native resource API.

Background

derivedAsync in ngxtension provides a convenient way to derive asynchronous data based on signals. However, the resource API in Angular offers a more integrated and complete solution for similar use cases.

Key Points

• Functionality Overlap: The resource API directly addresses the need for asynchronous signal derivation, particularly in scenarios involving HTTP requests and data fetching.
• Native Integration: Utilizing the resource API aligns with Angular's core features, potentially leading to better performance and maintainability.
• Simplification: Deprecating derivedAsync would simplify the ngxtension API, reducing redundancy and focusing on utilities that complement Angular's native offerings.

Proposed Action

We propose to deprecate derivedAsync in a future major release of ngxtension, once the resource API in Angular is officially marked as stable.

Discussion Points

• What are your thoughts on the overlap between derivedAsync and the resource API?
• Are there specific use cases where derivedAsync still provides a significant advantage over the resource API?
• What migration strategies would be helpful for users transitioning from derivedAsync to the resource API?
• Do you have any concerns regarding the deprecation of this function?
• When do you consider that the resource API in Angular is stable enough to make this change?

Next Steps

We will closely monitor this discussion and consider all feedback before making a final decision. If the community consensus supports deprecation, we will provide clear migration guidance and update the documentation accordingly.

We value your input and appreciate your participation in this discussion.

[michaelbe812]

+1 for deprecation.

It should also be very foreseeable once it can be removed (earliest once resources become stable, latest maybe 1 or 2 majors after they re stable).

I would appreciate as early communication as possible that this will happen (if decision is done for deprecation)

Some more questions popping up:

• Does it make sense to already recommend using resources even if they are still experimental
• Does ngxtension want to ship a migration to resources? Ngxtension should already have quite a good user base. However we of course don't know how much people are using derivedAsync

[michael-small]

I agree with these points and the sentiment of the follow up questions.

"Does it make sense to already recommend using resources even if they are still experimental"

If I recall right, Alex Rickabaugh already recommends using resources in projects see @JeanMeche's comment for very important caveat.

Personally, I don't consider using resources in my professional projects yet. But with parity with how I understand derivedAsync works, I think resources probably do the job already.

"Does ngxtension want to ship a migration to resources? Ngxtension should already have quite a good user base. However we of course don't know how much people are using derivedAsync"

To be transparent I never really used derivedAsync much. But if I were to guess what is used the most in ngxtension, my gut says derivedAsync has to be up there. I see a lot of people talk about it. I even referenced it in the PR that added resources as my own frame of reference before I had seen any takes from people.

On that hunch, I would say a migration would be appropriate. Or at the very least, consider some options like:

• A dev time console warning like signalSlice does with its original built-in effects?
• An dedicated section of the doc page with some detailed examples?

[JeanMeche]

recommends using resources in projects.

Yes and no. We recommend using it, to give feedback to the team. But the caveat is important. The API is experimental and will change a bit. Using it means you'll take the responsability to fix the breaking changes that will occur.

[michael-small]

Thanks for the clarification, I updated my comment to put emphasis on yours.

[sysmat]

• derivedAsync is clean code
• derivedAsync createNotifier is clean, but new resource can be done with some extra signal in request
• over all derivedAsync is greate and was much need it back then, all thx for it

[matiasfs12]

I will go straight to my use case in my app. That said, I tried to do this simple infinite scroll view model, with resource, with no success, afaik, there is no way to get previous value, correct me if I´m wrong. I don´t really know if it´s something already on the radar.

filteredSymbols = derivedAsync((previousValue: Product[] = []) => {
        const query = this.state.searchQuery();
        const page = this.state.page();
        const pageSize = this.state.pageSize();
        return this.productService
            .searchProducts({
                source,
                query,
                pageSize,
                page,
                order: 'codeasc'
            })
            .pipe(
                map(symbols => {
                    if (page === 0) {
                        return symbols;
                    }
                    return [...previousValue, ...symbols];
                })
            );
    });

What would it be the best replacement if we deprecate derivedAsync ?

[JeanMeche]

What would it be the best replacement if we deprecate derivedAsync ?

A resource + a computed should be able to do the same thing.

[matiasfs12]

    symbolsReqParams = computed(() => {
          const page = this.state.page();
          const pageSize = this.state.pageSize();
          const query = this.state.searchQuery();
          return {
              page,
              pageSize,
              query
          };
        });
        
     symbols: Signal<Product[]> = computed(() => {
            return this.symbolsResource.value() || [];
        });

    symbolsResource = rxResource({
        request: () => this.symbolsReqParams(),
        loader: ({ request: { pageSize, page, query} }) => {
            return this.productService
                .searchProducts({
                    source,
                    query,
                    pageSize,
                    page,
                    order: 'codeasc'
                })
                .pipe(
                    map(symbols => {
                        if (page === 0) {
                            return symbols;
                        }
                        const prevSymbols = this.symbols();
                        return [...prevSymbols, ...symbols];
                    })
                );
        }
    });

Every time any of the req params change, value will be cleared, how the accumulation it´s supposed to be done ?

[JeanMeche]

My bad linkedSignal instead of computed this way you have access to the previous value.

[matiasfs12]

Nevermind, resource + linkedSignal works like a charm. Thanks @JeanMeche.
It was the only scenario I thought resource might not cover. I´m not sure if it would make sense to have the previous value somehow on resource.

That said, I personally use derivedAsync() very often, in a really large codebase, but whenever resource becomes stable, we will migrate to it.