[Completed] Looking for community feedback on Angular Query

[arnoud-dv]

Completed

Remaining work for a stable release is tracked in this issue and its sub-issues. Comments are welcome.

This feedback discussion is now completed, please create a new discussion about a specific subject for any future questions or feedback.

Thank you everybody who gave feedback or contributed with code, ideas or reporting issues!

---

👋 Hi everyone,

I've been working on a pull request for adding an Angular adapter to TanStack Query, and it's now approaching completion.

To give you a better idea of its functionality, here are two sandboxes:

1. Angular Query: Simple Example Ported from React Query.
2. Angular Query: Basic Example Ported from React Query, which includes reactivity in the Post component.

These sandboxes are interactive, allowing you to edit the code and see how it works in your own forked sandbox.

The adapter exclusively uses Angular signals, but integrating it with RxJS is quite straightforward thanks to the Angular RxJS interop. With Tanstack / Angular Query, you can potentially replace most, if not all, RxJS-based server-side state synchronization code. That said, I believe RxJS still has significant applications in modern Angular apps, even after the introduction of signals in the framework. For instance, signals derived from an RxJS stream can be easily integrated into query options for reactive behavior.

For the time being, I'm naming the adapter "experimental." This is primarily to allow for the possibility of making breaking API changes in the future. However, I am quite satisfied with its API, especially with createQuery.

I'm looking forward to read your thoughts and feedback! If you have suggestions for API changes or any other improvements, now is the perfect time to share them.

[arnoud-dv]

Edit: changed it from query = inject(CreateQuery)(() => ({ to query = injectQuery(() => ({ as suggested, thanks!

A convincing case is made by @eneajaho (thanks for the incredible amount of feedback so quickly!) to rename the create* functions to inject*.

Example:
query = inject(CreateQuery)(() => ({

would become

query = injectQuery(() => ({

benefit is also getting rid of a pair of parentheses. Opinions? If nobody objects I will rename this as suggested.

[eneajaho]

This kind of API would also have other benefits later.

For example, let's take this mutation with invalidation.

import { useMutation, useQueryClient } from '@tanstack/react-query'

const queryClient = useQueryClient()

// When this mutation succeeds, invalidate any queries with the `todos` or `reminders` query key
const mutation = useMutation({
  mutationFn: addTodo,
  onSuccess: () => {
    queryClient.invalidateQueries({ queryKey: ['todos'] })
    queryClient.invalidateQueries({ queryKey: ['reminders'] })
  },
})

Using a setup function like API (almost same as rxState) it would become sth like this in Angular

@Component()
export class Cmp {
  mutation = injectMutation(({ invalidateQueries, /* maybe some other helper api-s here, setQueryData ?*/ }) => {
   return {
      mutationFn: addTodo,
      onSuccess: () => {
         invalidateQueries({ queryKey: ['todos'] })
         invalidateQueries({ queryKey: ['reminders'] })
      },
   }
 }); 
}

Because we can use inject underneath, we can give the devs some helpers under the hood we can get directly from the query client, the devs won't have to import anything else, because we expose methods directly from the injectMutation setup function. And everything becomes clear.

Of course, the will be able to do the same thing if they inject the query client from the outside, but enabling these API-s by default is so much better.

[kuncevic]

Looks super cool, Is is something that can leverage https://github.com/ngneat/query by @NetanelBasal?
Are there any chances that effort might became a part of an official TanStack query offer? //cc @TkDodo

[NetanelBasal]

Hello @kuncevic,

I'm currently in the process of updating the library to version 5 and am contemplating the inclusion of signal support. However, I have reservations about its suitability for our use case. RxJS provides a far more robust solution when handling requests. Furthermore, I believe there's a significant concern with the use of signals within templates, particularly because of the challenges associated with type guarding. For instance:

<div *ngIf="result().isSuccess">
  {{ result().data }} <== data still typed as undefined | T
</div>

[arnoud-dv]

The NgNeat adapter is a completely different approach by basing it on RxJS and of course signals weren't available in Angular back then. The adapter I wrote works with signals but should interop with RxJS well.

[ayush-sd]

Hi @NetanelBasal, I see you mentioned that you were in the process of upgrading the library to version 5, but in the repo I see that the last tag says 3.0.0, I want to ask you if your adapter is still being maintained/developed? Me and my team are starting migration to angular v16 and we want to start using tanstack query but we are still trying to decide which of these 2 adapters should we use. Any points you can provide towards helping us choose the better adapter for us would be very appreciated as well, thank you.

@arnoud-dv any inputs from you would also be very helpful here

[ducin]

@arnoud-dv awesome amount of work! Definitely the amount of parenthesis might discourage people from trying that out, so 👍 for query = injectQuery(() => ({

Question 1: Not sure if core tanstack/query is capable of supporting streams. Hardly anybody in angular area is using axios directly. Would rxjs-based HTTP work out of the box with the queryFn? Did you consider auto-convertion like Observable<T> | Promise<T> -> if(isObservable(queryFn)) queryFn().toPromise()` or would you rather developers do that explicitly?

Question 2: would providing an example basing on NgModules-based components require extra-effort? Such example might attract more people who didn't move to standalone yet.

Again, awesome work, IMO the community needs such port very much.

[rbalet]

@alexciesielski No it isn't but feel free to download the repo and test it out ;). -> Reason: this is a function, not a service

That said, this way of writing is Not yet approved by @arnoud-dv, so maybe better waits his approval, or changes before learning from this demo.

I'm just filling in this demo how I'm actually using TanStack query with angular, inside my own project, as it may helps others

[alexciesielski]

it throws

[rbalet]

@alexciesielski Interesting, do you use the same repo ? Can you provide a step to reproduce (Even if that sounds numb, cause I do not have this error) I'd be glad to search & fix the error :)

[JulienLecoq]

@rbalet It has nothing to do with being a function or service, it depends where you call this function. If this function is called inside an injection context it's fine otherwise it will throw an error.

[BThomann]

@rbalet there is now a very nice example of how to use the query options pattern in Angular:
https://tanstack.com/query/latest/docs/framework/angular/examples/query-options-from-a-service
This currently my goto way for queries. I am still looking for a nice pattern for mutations.

[theo-matzavinos]

The queryOptions function is pretty useful. It would be nice to have something similar for mutations.

[TkDodo]

the use-case for query options is mainly to share them between useQuery, useQueries, useSuspenseQuery and imperative methods like queryClient.fetchQuery. What would be the use-case for mutation options?

[theo-matzavinos]

The idea is to define the mutations in a service with some predefined options (usually mutationFn and onSuccess). A function would help with the inference of the generics.

[theo-matzavinos]

I rescind this comment. I have since figured out we don't need services. Too much angular brain, I guess.

[PhillipNinan]

I thought this code from your sandbox was nifty. I frequently have a use case where i need to wait for some data (id, form, etc) before creating the query. it would be nice if you could somehow create a dummy query until you have what you need to make the request.

export class PostComponent {
  @Output() setPostId = new EventEmitter<number>()

  // Until Angular supports signal-based inputs, we have to set a signal
  @Input({ required: true })
  set postId(value: number) {
    this.postIdSignal.set(value)
  }
  postIdSignal = signal<number>(0)
  postQuery = inject(CreateQuery)(() => ({
    enabled: this.postIdSignal() > 0,
    queryKey: ['post', this.postIdSignal()],
    queryFn: async (): Promise<Post> => {
      const { data } = await axios.get(
        `https://jsonplaceholder.typicode.com/posts/${this.postIdSignal()}`,
      )
      return data
    },
  }))

  queryClient = inject(UseQueryClient)
}

I don't think this code made it into the current release. I'm not sure what the purpose of CreateQuery was. for now i have a lot of code like this.

  @Input()
  set personId(personId: number) {
    runInInjectionContext(this.injector, () => {
      this.query = this.evalService.getEvalsForPlayer(personId);
    });
  }

i tried to do something like this but it did not seem to work.

  _personId = signal(-1);
  @Input()
  set personId(personId: number) {
    // runInInjectionContext(this.injector, () => {
    //   this.query = this.evalService.getEvalsForPlayer(personId);
    // });
    this._personId.set(personId);
  }

  query = injectQuery(() => ({
    enabled: this._personId() > 0,
    queryKey: [evalKeys.forPlayer(this._personId())] as const,
    queryFn: () => {
      return lastValueFrom(inject(EvalService).getEvalsForPlayer(this._personId()));
    },
  }));

[arnoud-dv]

Hi, I don't fully understand what you're trying to do. In any case, I wouldn't recommend injecting a new query after the class (component or service) is instantiated. Probably TanStack Query already has you covered and it's just a matter of setting query properties and the right states will be changed, your queryFn gets executed if needed and templates rendered through the signals reactively for you.

For instance, if you need data in your query before it's fetched you can use placeholder query data. But in most cases simply rendering some static content in your template will suffice.

I am working on porting all the React Query documentation to Angular but in the meantime I would suggest checking out the documentation for React Query, in most cases it will be very similar. Also TkDodo's blog is highly recommended.

If you cannot find it there and could elaborate what you are trying to accomplish I could probably help you so let me know.

[JulienLecoq]

I have the same issue than @PhillipNinan, it's often that I need some extra data to build my queries and having them to be constructed inside an injection context feels too restrictive and annoying to deal with.

I also sometimes have queries built from a loop, so I don't know in advance how many of them I'll need. Hence, having the possibility to build them later on (outside an injection context) would be very cool.

Furthermore, I don't even see the benefits of having to build them inside an injection context, what does it brings positively? I would much prefer having something like this:

query = new Query(() => ({
    queryKey: [".."],
    queryFn: () => {},
})) 

And another variant which does not require to pass a function, making the code less verbose:

query = new Query({
    queryKey: [".."],
    queryFn: () => {},
})

Or function based since it seems to be fashionable:

productQuery = query(() => ({ 
    queryKey: [".."],
    queryFn: () => {},
}))

productQuery = query({
    queryKey: [".."],
    queryFn: () => {},
})

[arnoud-dv]

it's often that I need some extra data to build my queries and having them to be constructed inside an injection context feels too restrictive and annoying to deal with.

Can you elaborate on this? I really wouldn't know a use case for when you'd want to have a query outside an injection context. Injection context fits reactive programming very well and enables automatic unsubscription. I will soon add support for required input signals which should reduce the need to disable queries until the input is available.

Note you can actually use injectQuery outside an injection context but you'd need to pass an injector manually.

I also sometimes have queries built from a loop, so I don't know in advance how many of them I'll need. Hence, having the possibility to build them later on (outside an injection context) would be very cool.

This will be supported by injectQueries which I will re-implement before the first non-experimental release. This will also be in an injectionContext - or using the manually passed injector.

Furthermore, I don't even see the benefits of having to build them inside an injection context, what does it brings positively? I would much prefer having something like this

I have the feeling this need results from imperative code? Can you tell me more about why you'd want this?

[jmleep]

I really love how simple this is to use. It would probably be useful to see an example that exists in a service as most Angular devs are going to be using that as a simple way to manage things like API calls and global state in their applications.

Any updates on when stable is going to be released?

[NetanelBasal]

Try https://github.com/ngneat/query

[arnoud-dv]

Thank you @jmleep, great to hear that!

I'd say at this point what is left to do:

• redo injectQueries
• injectInfiniteQuery. I am working on this at the moment including docs and examples.
• examples more representative of real-world applications including services. This also serves as validation for the public API of Angular Query.
• SSR needs to be tested.

"when" is hard to say but expect at least a few more weeks. I tried to do as much as possible at the end of the year when I had some time off but I'm working full time again now so I can only work in the weekends and evenings on Angular Query.

It's open source so anyone can help out. What would help me the most at the moment is feedback on the public API of Angular Query and testing and reporting any bugs.

[Xample]

@NetanelBasal it's another projet / another thread, but I'm experimenting both project to see which one is most suitable. My concern yet is to see which one works best with the Signals. While ngneat/query works like a charm with observables, the injection context seems not to work as expected. What people need is an easy way to fetch data based on signals (the new angular's signal input), and get a query based on that input. However, this requires to create a signal holding the result at some point. And to create that one, we need to provide an injector (which I did not manage to make it work yet). We could cheat keeping the service's injector and use it to create the signal but we would be unsubscribing on the service's lifecircle instead of the component or directive one.

[JulienLecoq]

refetch method could be named fetch instead. It would be more appropriate to what it does and be less verbose, since in the case that you have a query which is not enabled, refetch is just a simple fetch.

Example:

query = injectQuery(() => ({
  enabled: false,
  queryKey: ["test"],
  queryFn: () => 1,
}))

query.refetch() // Does not make sense, it's just a fetch, not a refetch.

"Improved version":

query = injectQuery(() => ({
  enabled: false,
  queryKey: ["test"],
  queryFn: () => 1,
}))

query.fetch() // Makes more sense.

[JulienLecoq]

Make a version of the query that works with errors as values. Errors as values are recently used more and more and are recognised as a better pattern to manage errors. They allow to have typed errors, compared to thrown error that are "unknown" as gotten in a catch block. They allow to immediately see that a function can return an error, compared to thrown errors that are invisible from the function signature. And allow other powerful/better things than thrown errors.
Imho, thrown errors should be avoided as much as possible and returned errors be used instead.

Some popular libraries already started to use returned errors instead of thrown ones.

Example from Supabase documentation:

Since this kind of error handling is becoming more and more popular, I would like to have a version of injectQuery that handles errors like so instead of having to throw errors in the queryFn. This would remove the annoying thing of having to create wrappers to manage this kind of cases.

[hichemfantar]

What exactly is the different between this and ngneat/query?

[bjesuiter]

This is an official adapter where the dev connects closely with the devs of tanstack/query.
ngneat/query on the other hand is basically a 3rd party implementation of tanstack/query for angular and since it started earlier, it's a little more feature rich. But the dev behind it did not want to publish it's adapter under the @TanStack umbrella but to put it under his own umbrella @ngneat.
Also, it's documentation is not as good, as I hoped.

I'm betting on this official adapter and beta-testing it, since I think, in the long run it's the better bet.

[ayush-sd]

@bjesuiter me and my company are also now trying to decide which adapter to use, did you finally figure out which one to use? Any problems you faced with either adapter so far?

[bjesuiter]

I'm now using the @tanstack/angular-query-experimental in production.
It's absolutely great.
It's very compatible with Angular Signals. And since it's based on the pure tan-stack query core, I have more hope that it will be nearer to the core of tanstack and not deviate too much.

I'm using it!

[IamSAL]

I'm a developer shifting to angular from react world. It'll genuinely be a great time saver handling out data-fetching responsibilities to query. I checked the code examples in the documentation, seems interfaces are same as react-query. I'll definitely adopt it in real projects as soon as it comes out of the experimental stage!

[johngrimsey]

Am trying AQ out now and really enjoying the reduction in boilerplate from NgRx (a library I love very much). This is great work! 🙏

[Kerrick]

This looks pretty great, and has been experimental for a while now. With no non-chore, non-release commits in about a month, it seems stable enough to release to me. Is there anything keeping the library experimental besides inertia? I'd love to know what blockers exist to marking it as "ready to use in production."

[riccardoperra]

I’m interested as well. We’ve used Angular Query for an experimental production app some months ago and it was “ready” (except for something like signal required input etc which was released in that time). I would like to introduce it in our bigger projects, but as it's experimental I'm not 100% sure

[hichemfantar]

@TkDodo Perhaps marking the integration as Beta instead of experimental will encourage people to use it more thus increasing the feedback loop and improving it faster.

[arnoud-dv]

Any chance you'd be willing to soften the tone of the disclaimer? Something like

Done

[jon9090]

@TkDodo:

In my opinion, people don't use it because it's still experimental. If it were an official release, it would likely see more usage. I'm not sure why it's still in this state, because every package should have a stable version released (the current package works fine). When there's a major breaking change, you should just update the main version to indicate a possible breaking change to users. I find it odd that after such a long time, with zero issues reported on this package in Angular, you're still waiting for feedback that isn't coming. People rarely provide feedback unless they're actively interested, which is uncommon in the GitHub community.

[TkDodo]

people don't use it because it's still experimental

yes, that's a problem, but I don't think the fix is to just mark it stable, but rather to get users to use it anyhow :)

If they don't want to use it - fine, then don't. If you want to use it, please do. I think comments like "I'm waiting for this to be stable so that I can FINALLY use it" are not helpful and just show that people don't understand how open source works (I'm not saying you said that btw).

@arnoud-dv posted a todo-list of his not too long ago, so we're definitely still in the "figuring it out phase". I'm happy that you have no issues with the adapter, so if that's the case - why is it a problem for you if it says "experimental" or not?

When there's a major breaking change, you should just update the main version to indicate a possible breaking change to users.

I think I already said that this isn't easily possible in a monorepo where we have react/vue/solid/svelte and now an angular adapter that all have to be on the same major version. The version of the query-core has to match the versions of the adapters. That's certainly a constraint, but that's how it is.

And frankly, we can't just make a major version bump for everybody just because we got something wrong in the angular adapter. It's (sadly) just not how it works. React Query has 5.3 million downloads per week, and this would seriously anger a lot of people because their automatic dependabot upgrades won't work anymore. Coincidentally, my talk at React Advanced later this year will touch on that topic, too :)

[arnoud-dv]

people don't use it

Compared to React Query it's rookie numbers but it's downloaded in the thousands a week. Except for injectQueries which needs work I would use it on production myself if accepting the possibility of API changes which the experimental naming is mostly about.

Todo list is public, PRs are open and people are contributing. Anyone who wants to collaborate on the adapter can contact me on Twitter or Discord. Also consider the Angular APIs this is built on are partly in developer preview.

you're still waiting for feedback that isn't coming

Feedback is still welcome but I'm in this stage not waiting for it to release a non-experimental.

you should just update the main version

I'd rather avoid breaking changes, we have way too much churn in the FE world as is. I am working on a solution for the fixed major version number. The main challenge here is supported Angular versions.

[ThiloAschebrock]

I have been using Angular query in medium sized projects for two months now and I am really enjoying it, especially that it is working with signals as opposed to observables. I am coming from a React background (including react query) and missed the ease of data fetching and handling that this library enables.

My only major struggle so far is the typing of CreateQueryResult, which makes it nearly impossible to use with generics and, thus, for building generic component, see TS playground example.

Even without a official plugin, persisting the cache with session storage using @tanstack/query-sync-storage-persister was surprisingly simple.

[NateRadebaugh]

@arnoud-dv is there anything published on the timeline and what's remaining to upgrade @tanstack/angular-query-experimental to non-experimental?

I'd like to avoid scrutiny from using something called "experimental" in production deployments.

[arnoud-dv]

Yes, see my answer from last week.

To the people pushing for a non-experimental release I would like to say see the experimental phase as an opportunity too. In this phase a lot more is possible to get to a very nice API and DX. Try it, test it, if you have any ideas share them. And PRs are open, multiple people have contributed already.

I think it's worth it as we'll all be benefiting from this for years to come.

[NateRadebaugh]

Thanks for the response. I see 5 todos in your comment from last week. And would be interested in spending some time making some movement on these.

1. Angular doesn't handle signal types well
   I think this is likely an Angular/Typescript level change that the Angular team is working to improve and shouldn't require updates to this library.

2. Inject function APIs will change
   Is there a proposal you're wanting feedback or implementation help on?

3. SSR doesn't work well
   Is SSR support strictly required for the initial stable release? I know Angular team is currently revamping support for SSR and streaming/hydration, so I'm wondering if the plan would be to wait until that work is more further flushed out by the framework, possibly not until post-ng18. Not sure if it's entirely broken if SSR is enabled, or whether it would gracefully fallback to client-side initial data fetching

4. InjectQueries doesn't work well
   Are there test failures or scenarios you want help investigating?

5. queryFn should support returning observables
   I think this PR is heading in the right direction you're talking about? feat(angular-query): added observable support #6726

[buffos]

I have worked with Tanstack query for Angular for a little bit, and it is a great tool. Below I will add what I think should be added in the API to make easier and more natural to work with

1. The main "problem" with query.data() signal is that when it updates, it is set to undefined and then back to a value. This will cause the UI to flash (especially tables). This is more apparent when the query depends on signals and it chances reactively. What I do now every single time is the following

resolvedData = ReturningType[] = []
resolvedDataSignal = computed(() => {
    if (this.myInjectedQuery.data()) {
      this.resolvedData = this.myInjectedQuery.data()!;
    }
    return this.resolvedData ;
  });

Now I use the resolvedDataSignal instead of the data() signal.

** Proposal 1 **
Introduce the resolvedData signal in the api and also initialResolvedData. That way we do not have to worry about stale data of initialData, and it actually does what the user expects. Have the resolved data without getting in and out of undefined state

2. BeforeStart, OnSuccess and OnError hooks

I have a global service to notify loading (this.loadingService.start("message")). This sets some signals to make global loading available.
Initially, before adding tanstack, those calls were before and after each http call. Adding tanstack introduced errors, since those requests are now made inside the query, which is obviously some effect or computed signal and throws errors about writeable signals.

For this reason I had to move them to the query level and that is fine. The problem now is that there is no signal to stop loading so I have to to the following (I can also add a finally clause to stopLoading, but that's fine)

 queryFn: async () => {
      loadingService.startLoading('Loading customer bookings...');
      try {
        const bookings = await customerService.getCustomerBookings(
          customer_id(),
          limit(),
          offset(),
          isCancelled ? isCancelled() : undefined,
        );
        loadingService.stopLoading();
        return bookings;
      } catch (error) {
        loadingService.stopLoading();
        return Promise.reject([]);
      }
    },

This works ok but its not pretty. It would be much nicer to have separate hooks for pre , onSuccess and onError hook functions

I did not have any other issues so far.

[BThomann]

Point number 1 seems interesting did not notice that behavior in my apps - could you provide a minimal example that shows that behavior ?

To point number 2: I did not use it my self but it seems there is already a global error handling via the QueryCache available see:

• https://tanstack.com/query/latest/docs/reference/QueryCache
• https://medium.com/@valerasheligan/how-to-handle-global-errors-in-react-query-v5-4f8b919ee47a

You could also provide some meta information like here: https://tkdodo.eu/blog/automatic-query-invalidation-after-mutations#use-the-meta-option Its a different use case but could be adapted.

But if you want to do It on query level I guess you have to do something in the query function.

[buffos]

• For point 2, I didn't notice the QueryCache and it looks very very good. I will look into it
• For point 1. For example

export function injectCustomerListQuery(limit: Signal<number>, offset: Signal<number>, filter: Signal<string>) {
  const customerService = inject(CustomerService);
  const loadingService = inject(LoadingService);

  return injectQuery(() => {
    return {
      queryKey: customerKeys.allCustomers(limit(), offset(), filter()),
      queryFn: async () => {
        loadingService.startLoading('Loading customers...');
        try {
          const customers = await customerService.getCustomers(limit(), offset(), filter());
          loadingService.stopLoading();
          return customers;
        } catch (error) {
          loadingService.stopLoading();
          return Promise.reject([]);
        }
      },
      staleTime: staleTime,
      retry: retry,
    };
  });
}

• I feed the results to a CustomDataSource for material tables. When the signals change, the table flashes because you get a new key, which is of course undefined, and wait to get resolved. You will not notice the flashes for something that is very minor, but for a table the flashes are very annoying.
• The try catch blocks were inserted because the loading service changes a signal and had to be removed from the actual call that was initially close (I was getting an error about writing signals inside a compute or effect)

Having a resolved state and a resolved initial state will simply solve all the problems, because the resolvedState would not be key dependent but a general blanket of the query. And we will have an initialResolved State that will be replaced as soon as a new resolved state is there

For example, we have the query key ["customers", 1 ,1] , where 1,1 are some parameters. The InitialresolvedState is set to []. and the resolvedState is undefined ?? InitialresolvedState. When and IF the query resolves, the resolvedState will get a new value.
Now we change the key to ["customers", 1 ,2] there is no change in resolvedState until the query resolves and we get a new value

This is at least my solution to all be tables. Make a computed that does exactly that, but it would be better to avoid the repetition and have it inside the project.

[BThomann]

Ah now I understand your "problem". So basically it works as expected - new query key, new request, new loading state new data.

Have you already looked into using maybe placeholder data for that. This example from the react docs: https://tanstack.com/query/latest/docs/framework/react/guides/placeholder-query-data#placeholder-data-as-a-function
seems like its what you want tough. Disclaimer: had not yet the possibility to check if it also works for the Angular adapter already.

[buffos]

Yes. It works as expected. I am just proposing adding those two states to the query to make it seamless.
I find myself reimplementing the following code and seems logical to create a seamless transition. It does not break anything, just expands the API

resolvedData = ReturningType[] = []
resolvedDataSignal = computed(() => {
    if (this.myInjectedQuery.data()) {
      this.resolvedData = this.myInjectedQuery.data()!;
    }
    return this.resolvedData ;
  });

Writing code for the placeholder is more work than pasting those lines in every pieces I use inject query.
I just thought to share my experience and my solution to the problem I had.

[BThomann]

Writing code for the placeholder is more work than pasting those lines in every pieces I use inject query.

Why more work? It seems to be a one liner in the example I linked. It seems to solve the issue you have or am I wrong?

I also think it's going to be hard to get something into the QueryOptions core api "just" for an Angular use case.

[moxaj]

I have 2 questions:

First, how do I wait for a value to arrive and do something with it once the view has been rendered? For now, I have:

  injector = inject(Injector)
  apis = injectQuery(...)

  constructor() {
    afterNextRender(() => {
      toObservable(this.apis.data, { injector: this.injector })
        .pipe(
          filter((apis) => apis !== undefined),
          first()
        )
        .subscribe((apis) => {
          if (!apis) {
            return
          }
      
          // ...
        })
    })
  }

Feels a bit too complicated.

Second, say I have

  foo = injectQuery(() => ({
    queryKey: ['foo'],
    queryFn: () => 'foo',
  }))

and another value bar which depends on the value of foo. What is the best way to initialize bar?

Option 1 (built in computed):

  bar1 = computed(() => (!this.foo.isSuccess() ? undefined : 'bar'))

The problem with this is that if undefined would be a valid value for bar, then I cannot differentiate between that and the loading state (unless I use foo.status).s

Option 2 (ngxtension library):

  bar2 = derivedAsync(() =>
    toObservable(this.foo.data).pipe(
      filter((data) => data !== undefined),
      map((data) => 'bar')
    )
  )

I think this is functionally the same, and has the same issue with undefined.

Option 3 (dependant query):

  bar3 = injectQuery(() => ({
    queryKey: ['bar'],
    queryFn: () => 'bar',
    enabled: !!this.foo.data(),
  }))

I don't think queries are meant to be used with regular derived values, so this one feels like a hack, but at least it has the nice status API.

[moxaj]

@arnoud-dv I see you've given the thumbs up for that answer, could you please then clarify these in the documentation (assuming you are the one responsible for them)?

[BThomann]

How would you like the docs to be clarified? Any suggestions?

One thing I learned: a lot of things that can be done in react (where the documentation is more mature and there are more blogs etc online) can be transferred to the Angular world. So don't be fully focused on Angular when searching for solutions in Angular (Tanstack) Query.

[arnoud-dv]

One thing I learned: a lot of things that can be done in react (where the documentation is more mature and there are more blogs etc online) can be transferred to the Angular world.

Yes it was my intention when developing the Angular adapter to stay close to the React Query API and its reactive principles while also integrating well with Angular signals. So yeah Angular signals are very different from how React works but APIs are similar between the Angular and React adapters and ideas about reactive programming should transfer well.

[moxaj]

I think it should mention how you can make a synchronous operation depend on a value from injectQuery. Right now the only example is a follow-up http request.

And, reading the react docs, I realize this is pretty much the same in react land:

const { data: user } = useQuery({
  queryKey: ['user', email],
  queryFn: getUserByEmail,
})

const userId = user?.id

Here, if for some reason the id can be undefined, then some information is lost at user?.id. Is the value actually undefined, or did the parent request fail / is it still pending? For the query, this is encoded at the type level, it's like a monad, and if it had a map operation, you could map the user query to userId, and then you could do

if (userId.isSuccess()) { .. }

without having to know that userId depended on a specific query.

[arnoud-dv]

I think it should mention how you can make a synchronous operation depend on a value from injectQuery

No different from other signals: create a computed, or effect if you need to perform a side effect like calling imperative code.

then some information is lost at user?.id

It's not lost, it's in the original query result. If you choose to build an abstraction over that it's hidden behind the abstraction yes. I would generally not recommend that. It would mean hiding types and functionality as well which you will then probably need to re-implement.

[rbalet]

Hi @arnoud-dv.

I'm currently migrating from @ngneat/query to your library.
Appart from this small issue, the migration has been smooth and easy to understand. Big thanks for the excellent work! ❤️

Now that you're handling signal — which was the main reason I originally chose the ngneat library — I was wondering: have you considered reaching out to the ngneat/query maintainer, to see if he'd be interested in collaborating on your library instead, and potentially marking his as deprecated?

Thanks again for all your efforts!

[arnoud-dv]

I was wondering: have you considered reaching out to the ngneat/query maintainer, to see if he'd be interested in collaborating on your library instead

PRs are open for everybody so he's welcome if he wants to collaborate.

[hoangvutruong513]

Hello @arnoud-dv, really really appreciate your hard work on this Angular adapter for Tanstack Query. I was lucky enough to start a new Angular project and immediately jumps onto this train the moment I saw the documentation. Happy to report that I have encountered 0 production bugs so far, and the app itself is a huge internal enterprise application.

This library has dramatically changed the way I approached state management in general, and asynchronous state management in particular.

Angular devs tend to over-burden ourselves with services injecting/co-ordinating other services, and worrying about at which layers should we load/fire our request to make sure our data is available. Also using a bunch of RxJs operators like distinctUntilChanged, debounceTime, switchMap, tap to perform repetitive tasks like debouncing, de-duping requests, setLoading, setError, etc. So happy that I no longer have to think so much about those things with Angular/Tanstack Query.

The built-in query-key cache management, request de-dup/cancellation, active/inactive query management on component mount/unmount (via injection context), etc have been amazing to work with. I am honestly impressed with the perfect balance between declarative and imperative APIs available to developers.

Big kudos to you and the team's work. Look forward to next stage of the library, graduation from experimental!

[moxaj]

How do you test query data? In my unit tests (jest), my query is stuck in pending state. Things I've tried:

• fixture.detectChanges()
• TestBed.flushEffects()
• the experimental await component.query.promise()
• manually refetching the query with await component.query.refetch()

The only thing that works is manually waiting for some arbitrary duration:

fixture.detectChanges()
await new Promise((r) => setTimeout(r, 1000))

but obviously, that's super brittle (fails with 500ms for example).

FWIW, as per https://tanstack.com/query/latest/docs/framework/react/guides/testing#our-first-test, in react you can simply do:

await waitFor(() => result.current.isSuccess)

[arnoud-dv]

A testing guide needs to be written (that's also an invitation to anyone who wants to do that).

For now I would suggest to look at the Angular adapters own tests. It uses Vitest but APIs of Vitest and Jest are almost the same.

The Angular team is working on making testing signals easier, so keep an eye out on any updates on signal testing in general.

[moxaj]

@arnoud-dv those tests were very helpful! The trick for me was:

// component created, data is still undefined
fixture.detectChanges()
tick()
TestBed.flushEffects()
// now status is 'success' and data is available

[wilson-webdev]

I found that this worked when using with Spectator and Jest.

spectator.detectChanges();
await jest.advanceTimersToNextTimerAsync();

[Kibadango13]

Is there any update on a stable version? I'm eager to use this in my application.

[arnoud-dv]

Made a lot of progress recently, keep an eye on the issues - I'll add one about how to get to stable within a few days.

[moxaj]

Angular 19 is introducing an experimental resource function:

@Component(...)
export class UserProfile {
  userId = input<number>();

  userService = inject(UserService);

  user = resource({
    request: this.userId,
    loader: async ({request: id}) => await userService.getUser(id),
  });
}

The resulting Resource instance, which exposes signals that communicate both the value (when available) as well as the current status of the resource (loading, resolved, errored, etc).

This looks an awful lot like injectQuery, so I wonder how this is going to affect this library. Probably not too much in the short term, as without all the useful middleware (retries, caching, invalidation, etc.) it's very barebones.

[moxaj]

enabled and skipToken feel a bit awkward to use when checking for falsy values. In the official example:

  todosQuery = injectQuery(() => ({
    queryKey: ['todos', this.filter()],
    queryFn: this.filter() ? () => fetchTodos(this.filter()) : skipToken,
  }))

The compiler doesn't know when the queryFn would be called, so it cannot deduce that this.filter() would still be truthy value, so you would have to check again inside queryFn:

  todosQuery = injectQuery(() => ({
    queryKey: ['todos', this.filter()],
    queryFn: !this.filter()
      ? skipToken
      : () => {
          const filter = this.filter()
          if (!filter) {
            throw new Error('yikes')
          }

          return fetchTodos(filter)
        },
  }))

But since the argument given to injectQuery is already a function, maybe you could do this?

  todosQuery = injectQuery(() => {
    const filter = this.filter()
    return !filter
      ? { queryFn: skipToken } // Can I omit queryKey?
      : {
          queryKey: ['todos', filter],
          queryFn: () => fetchTodos(filter),
        }
  })

At which point, if skipToken is only ever used here, you could rename it to something like skipQuery and do:

  todosQuery = injectQuery(() => {
    const filter = this.filter()
    return !filter
      ? skipQuery
      : {
          queryKey: ['todos', filter],
          queryFn: () => fetchTodos(filter),
        }
  })

[BThomann]

I guess this would be a good usecase for the Query Options API? You could do something like this:

function todosQueryOptions(filter: string | undefined) {
  return queryOptions({
    queryKey: ['todos', filter],
    queryFn: filter ? () => fetchTodos(filter) : skipToken
  });
}

const todosQuery = injectQuery(() => todosQueryOptions(filter()));

This a pretty neat solution and typed well.

[moxaj]

@BThomann I think this is functionally equivalent to my 3rd example, no? queryOptions simply returns whatever is passed to it, as per the docs, and also it's for cases when you want to reuse stuff (which isn't true for this case).

At the very least, I think the docs should be improved, as fetchTodos(this.filter()) is very likely wrong: the definition for fetchTodos isn't there, but I don't believe it would accept nullish values, and if it would, why would you disable the query?

[BThomann]

Yes its an adaption of your third option. I am just a fan of the query options API and move them to a service like one would do also for the http client.

Thats ah valid observation with the docs I guess I would be much appreciated if you could create a PR with your suggested improvements 👍🏻

[arnoud-dv]

I think the docs should be improved, as fetchTodos(this.filter()) is very likely wrong: the definition for fetchTodos isn't there

I attempted to create real implementations of all the code examples in the docs to validate them but it was just too much. If you find that an example doesn't work, a PR is welcome!

[ayush-sd]

I recently upgraded from v5.62.7 to v5.62.8 and started seeing this type error on a very basic function @arnoud-dv
Going back to v5.62.7 makes this error go away, what is the issue here? Is it something on my end?

@Injectable({ providedIn: "root" })
export class VersionsQueriesSer {
  #http = inject(HttpClient);

  getVersions(contractId: string) {
    return queryOptions({
      queryKey: ["versions", contractId],
      queryFn: () => {
        return lastValueFrom(this.#http.get(""));
      }
    });
  }
}

[ayush-sd]

I checked on 5.62.9 but the issue is still there

[arnoud-dv]

I checked on 5.62.9 but the issue is still there

I cannot reproduce this myself. Can you make a reproduction on either TypeScript Playground, Stackblitz or Codesandbox and create a bug report?

[ayush-sd]

@arnoud-dv On stackblitz I am facing a completely different kind of issue, no typings at all
https://stackblitz.com/edit/angular-naz9plef?file=src%2Fversions.queries.ts

Locally the error is this, the error message has changed from previous version, it doesn't specify dataTagSymbol anymore

[ayush-sd]

However, I am unable to reproduce this in codesandbox, I tried flipping different ts compiler settings too but could not reproduce it. I still see the error in my local project which is quite a big nx angular monorepo, I have tried restarting, deleting node_modules and installing again, etc

[dorji-dev]

Same type error on: 5.64.2. Using 5.62.7 for now as suggested by others.

[wizardnet972]

@arnoud-dv

First of all, thank you for the Angular support. I recommend this library to my clients and use it in my projects.

Here’s some feedback regarding its usage:

• In Angular, we usually work with RxJS, so HTTP calls typically return an observable. It would be more convenient if the library provided built-in support for observables rather than just promises. If I have to write lastValueFrom for every call, it becomes boilerplate code.

• Another point is that Angular also uses signals. I would expect that if a signal changes, the query would automatically re-run, similar to a computed property. One example of this approach can be seen in the derivedAsync function from ngxtension/derived-async.

I’m happy to submit a PR for this if needed.

[BThomann]

Tbh I am not sure if it's worth the typing effort to support rxjs out of the box. lastValueFrom just adds a minimal boiler plate that can easily be automated with snippets.

[arnoud-dv]

Tbh I am not sure if it's worth the typing effort to support rxjs out of the box. lastValueFrom just adds a minimal boiler plate that can easily be automated with snippets.

Yeah I agree, maybe I should remove it from the list of things to be done for a stable release.

[wizardnet972]

It's a boilerplate issue for those using observables—that's a fact. Good code minimizes boilerplate.

I also don’t think this is a particularly complex problem to solve. Just check if the object is an observable using [isObservable](https://rxjs.dev/api/index/function/isObservable), and if it is, use lastValueFrom internally. This function should only take 1-2 lines to implement.

[BThomann]

Feel free to open a PR on that.

[arnoud-dv]

I also don’t think this is a particularly complex problem to solve. Just check if the object is an observable using [isObservable](https://rxjs.dev/api/index/function/isObservable), and if it is, use lastValueFrom internally. This function should only take 1-2 lines to implement.

As I've said before in this thread it's not the implementation but the typing that's difficult.

[hiepxanh]

Angular Universal version 19 SSR solution to cache with TransferState, it work with me:
Writing here for note purpose:

export const GRAPHQL_CACHE_KEY = makeStateKey<Record<string, any>>('GRAPHQL_CACHE');

// after that add it to angular provider array:

const providers = [ 
// ... your previous provider
 provideEnvironmentInitializer(() => {
    const transferState = inject(TransferState);
    const platform_id = inject(PLATFORM_ID);
    console.log('isBrowser?', isPlatformBrowser(platform_id));
    if (isPlatformBrowser(platform_id)) {
      // restore on client
      const state = transferState.get(GRAPHQL_CACHE_KEY, {});
      console.log('BROWSER: restoring checkpoint from Angular', state);
      hydrate(queryClient, state);
     
    } else {
      // server
      transferState.onSerialize(GRAPHQL_CACHE_KEY, () => {
        const state = dehydrate(queryClient, { shouldDehydrateQuery: () => true }) // to also include Errors
        console.log('SERVER: creating checkpoint to Angular once render finished.', state);
        return state;
      })
      
    }
  }), 
];

That all, very easy

[nebbsie]

Would you mind sharing the rest of your config?

[efleetcon-simon-s]

I observe an issue related to @moxaj's observation, where queries get stuck in pending states. Whenever I use await inside a query function, isPending() will resolve to true in approximately 9/10 cases. I have one use-case where I need to await a firstValueFrom call, before executing an HTTP request. Easy to test using the following:

query = injectQuery(() => ({
	queryKey: ['test'],
	queryFn: async () => {
		await new Promise((r) => setTimeout(r, 1000));
		console.log('this is called, but query.isPending() will always be true');
		return [];
	},
}));

[efleetcon-simon-s]

Funny enough, the code works as expected in a StackBlitz. If I cut all my app code and replace my bootstrapApp with the same code as in the example, I also get a working version, so it is not a matter of dependencies.

Yes, the http call is also an observable that is a awaited, which actually always works. Only when I add other awaits for "regular" promises, I get queries stuck in pending state. This happens during runtime, as well as in a production build.

In my specific usecase, I have some startup code that determines if the app is currently running in offline or online mode. This will take shy of a second to evaluate, and then feeds a ReplaySubject that is exposed as an Observable. Since the lib relies on the use of promises, and I naturally keep my network code in promises as well, I thought it would be easiest to just await the firstValueFrom here (which means every query waits until the app knows wheter is runs in offline or online mode). Depending on the resulting value, I either run a network call or load a cached value. This works, as the promises return, but the queries will not change state.

[arnoud-dv]

I don't think having logic for this in every queryFn in an application is the best way to do this. Some other solutions I can think of, but there are probably plenty more:

Complete app initialization only when the offline / online logic has run

This would mean any code having queries would only run after this is completed.

Perform your startup code in provideAppInitializer and return a promise that resolves when the initialisation is complete. Either use QueryClient.setQueryData to add to the TanStack Query cache manually, or use an Angular HttpInterceptor that can return cached data. When using an interceptor you probably won't need provideAppInitializer as the interceptor can just depend on the offline / online logic itself.

Render the application while the offline / online logic is running

This would mean all queries would be paused and in a loading state until the offline / online logic has run.

You can set the TanStack Query onlineManager first to offline. provideAppInitializer would again be a good place for this. Then have your custom online logic set it to online when that status is confirmed. While onlineManager is set to offline all your queries will be automatically paused. I just tried this in a provideAppInitializer in the basic example and this works.

import { provideHttpClient, withFetch } from '@angular/common/http'
import {
  QueryClient,
  onlineManager,
  provideTanStackQuery,
  withDevtools,
} from '@tanstack/angular-query-experimental'
import { provideAppInitializer } from '@angular/core'
import type { ApplicationConfig } from '@angular/core'

export const appConfig: ApplicationConfig = {
  providers: [
    provideAppInitializer(() => {
      onlineManager.setOnline(false)
    }),
    provideHttpClient(withFetch()),
    provideTanStackQuery(new QueryClient(), withDevtools()),
  ],
}

[efleetcon-simon-s]

Thank you for the provided examples. While I agree that this might not be the best way to do this, it is the most convenient at the time for me and is an independent topic that should be discussed separately from the actual issue: queries arbitrarily getting stuck in pending mode when awaiting a promise that is not an await lastValueFrom(this.http.get(...)) call. I am sorry I cannot provide a better reproduction at the time. I tried to drop most of my application boilerplate, but it seems so random. If I reduce my app to only the StackBlitz, everything works as expected, but as soon as I add a few modules (even without other queries), the issue comes back.

To comment on your ideas: Using an initializer is not an option, as I do not want the whole app to wait just for this information. Many pages can be used regardless, and the method would cause unnecessary delays. While an interceptor with some smart logic would work, I am not a fan of this approach as loading data from a cache is semantically different from performing an HTTP request.

At the moment, my workaround is to expose a signal that is set when the offline/online logic has run, and use that as enabled: ... option. The query can then use a variable set by a subscribe call to decide whether to return cached or remote data. Your idea of using onlineManager really helps here, as I can get rid of the signal and make sure that the onlineManager is only set to online when the online/offline logic has run, and I am sure I have a synchronous update from the subscribe call. Thank you for that, prevents me from using the signal in every query.

But still, there is likely something wrong because queryFn's can return while leaving the query in pending state.

[efleetcon-simon-s]

Never mind, I tracked the cause of the issue down. It is (was) my user error. I ran queryClient.clear() every time the app went to online mode. This sometimes ran while the query was processing, and a pitfall is that this function does not notify observers of the cleared cache. I am not the first one to experience this, as documented in this issue.

Hope I didn't waste too much of your time, I'm going to leave this here for anyone who stunbles across.

[BThomann]

Glad to hear you found a solution and thanks for the context! :)

[JulienLecoq]

What does the field experimental_prefetchInRender exactly do with queries? There is this documentation: "Enable prefetching during rendering" but it's not really clear for me.

[Cybertron01Z]

We use @tanstack/angular-query-experimental quite heavily on a medium-sized project. We have services that are generated from OpenAPI schemas. Then we create a layer of functions that generate the queryOptions or mutationOptions. We use those options directly in the components with injectQuery, and this works like a charm.

However, I recently ran into a problem when I tried to get the queryOptions (I just needed the queryKey) in the onSuccess callback.
The issue is that the onSuccess callback is not run in an injection context anymore, which means the const service = inject(SelectionServiceGenerated); fails.

I was able to fix this by manually calling runInInjectionContext in onSuccess.

I am not sure if I am doing something that is not intended to be used this way. If it is intended, would it be possible to make the callbacks run in an injection context?

Note: we are still on version 5.61.6. I checked the Changelogs and didn't see any changes regarding the onSuccess.

function getSelection(selection_id: string | null) {
  const service = inject(SelectionServiceGenerated);

  return queryOptions({
    queryKey: ['selection', selection_id],
    queryFn: () => lastValueFrom(service.getSelection('', '', selection_id ?? '')),
    enabled: !!selection_id,
  });
}

// does not work
function createSelection() {
  const service = inject(SelectionServiceGenerated);
  const queryClient = inject(QueryClient);

  return mutationOptions({
    mutationKey: ['create', 'selection'],
    mutationFn: (selection: Request) =>
      lastValueFrom(service.createSelection('', '', selection)),
    onSuccess: (response) => {
      const queryKey = getSelection(response.id).queryKey;

      queryClient.setQueryData(queryKey, response);
    }
  });
}

// works
function createSelection() {
  const service = inject(SelectionServiceGenerated);
  const queryClient = inject(QueryClient);
  const injector = inject(Injector);

  return mutationOptions({
    mutationKey: ['create', 'selection'],
    mutationFn: (selection: Request) => lastValueFrom(service.createSelection('', '', selection)),
    onSuccess: (response) =>
      runInInjectionContext(injector, () => {
        const queryKey = getSelection(response.id).queryKey;

        queryClient.setQueryData(queryKey, response);
      }),
  });
}

[BThomann]

We use a very similar approach like you mentioned. OpenAPI HttpClient Service -> Queries Service that returns queryOptions/muationsOptions -> use injectQuery & injectMutation in component.

The only difference is that we don't create plain functions that return the query options but a dedicated service that does that. With that you would be able to also solve the issue with the injection context if you do something like:

@Injectable({
  providedIn: 'root'
})
export class SelectionQueries {
  readonly service = inject(SelectionServiceGenerated);
  readonly queryClient = inject(QueryClient);

  function getSelection(selection_id: string | null) {  
    return queryOptions({
      queryKey: ['selection', selection_id],
      queryFn: () => lastValueFrom(this.service.getSelection('', '', selection_id ?? '')),
      enabled: !!selection_id,
    });
  }
  
  function createSelection() {  
    return mutationOptions({
      mutationKey: ['create', 'selection'],
      mutationFn: (selection: Request) =>
        lastValueFrom(this.service.createSelection('', '', selection)),
      onSuccess: (response) => {
        const queryKey = this.getSelection(response.id).queryKey;
  
        this.queryClient.setQueryData(queryKey, response);
      }
    });
  }
}

And then you could go on using the SelectionQueries in the component. For example:

readonly queries = inject(SelectionQueries);
readonly getSelection = injectQuery(() => this.queries.getSelection("foo"));

I know it's a bit more boilerplate but I think this is more the Angular way of doing it!?

[arnoud-dv]

inject is best run once on initialisation. See this article by Matthieu Riegler

For that reason I don't think onSuccess should run in the injection context. The example by @BThomann is a good way to accomplish running inject on initialisation only.

[Cybertron01Z]

Thank you for the quick response. I already assumed that we need to lean more into the Angular way to achieve this.

Since 98% of the cases work without any problems, we will stick with the pattern we have and extract the creation of the key into its own function.
However, I will definitely keep this in mind :)

function createGetSelectionKey(selection_id: string | null) {
  return ['selection', selection_id];
}

function getSelection(selection_id: string | null) {
  const service = inject(SelectionServiceGenerated);

  return queryOptions({
    queryKey: createGetSelectionKey(selection_id),
    queryFn: () => lastValueFrom(service.getSelection('', '', selection_id ?? '')),
    enabled: !!selection_id,
  });
}

function createSelection() {
  const service = inject(SelectionServiceGenerated);
  const queryClient = inject(QueryClient);

  return mutationOptions({
    mutationKey: ['create', 'selection'],
    mutationFn: (selection: Request) =>
      lastValueFrom(service.createSelection('', '', selection)),
    onSuccess: (response) => {
      const queryKey = createGetSelectionKey(response.id);

      queryClient.setQueryData(queryKey, response);
    }
  });
}

[BThomann]

With moving the key creation into a separate function you lose all the power of the query function. It's always beneficial to colocate the queryKey and queryFn because of the nice TS magic query options offer.
For more context see: https://tkdodo.eu/blog/the-query-options-api

(Is a react article but the same goes for angular.

Or check out the docs:
https://tanstack.com/query/latest/docs/framework/angular/guides/query-options

All the query client functions are typed correctly. In your example you would lose that type info.

[Cybertron01Z]

Ha, you are right, there is some crazy TS magic happening. Thx a lot for taking the time to help me :)

[christiantweed-oc]

Hi I've been watching this discussion for a while and I think this is one of the better angular packages to keep any eye out for. Is there a roadmap for getting this released as a stable package? I'd be happy to contribute, but I am unsure of where to help.

It's been in an alpha state for over a year now and I've seen adoption of this over ngneat/query, but I'd like to feel comfortable switching.

[arnoud-dv]

but I'd like to feel comfortable switching

Go for it, especially if you already use developer preview APIs on Angular such as effect. It's essentially the same concept - API can change.

TanStack Query Core is one of the most popular frontend libraries and very well tested through the other framework adapters. Also many people already use the Angular adapter in production and I consider it well tested too at this point. Bugs were reported and fixed.

There's just one known bug which can be fixed after a stable release as it doesn't require a breaking change. Besides that injectQueries is being worked on.

Just no guarantees about the API of the Angular adapter potentially changing but at this point I do not expect very impactful API changes. If the Angular adapter would have its own versioning I would have released a stable version by now. If we would need a breaking change for Angular we cannot increase the adapter major version so we need to be extra careful about the API being stable for the foreseeable future.

In any case not many must haves and API decisions to be made left so I expect a stable release soon. I'll put what's left in a Github issue.