Re-architect Angular Query around Angular Resource before stable release

[OmerGronich]

I’d like to propose making Angular Resource part of the core implementation of injectQuery.

The Angular adapter is still experimental, and when it was created Angular did not yet have a first-party Resource API. Now Angular does, and newer Angular APIs are starting to compose around resources. Signal Forms async validation is a good example: validateAsync() is resource-based, but injectQuery() currently returns a TanStack-shaped signal object, not a resource.

That makes TanStack Query feel slightly outside Angular’s current async model. It works well with signals and templates, but it does not plug cleanly into APIs that expect a ResourceRef.

Proposal

Architect injectQuery around Angular Resource internally:

QueryObserver
  -> Angular Resource
  -> Angular Query result object

The public API could remain mostly the same:

const query = injectQuery(() => ({
  queryKey: ['user', userId()],
  queryFn: ({ signal }) => getUser(userId(), { signal }),
}))

query.data()
query.isPending()
query.isFetching()
query.refetch()

But because the implementation is resource-based, the underlying resource could also be exposed:

query.resource.value()
query.resource.status()
query.resource.error()
query.resource.reload()
query.resource.hasValue()

This would let Angular-native APIs consume TanStack Query without custom glue:

validateAsync(path.username, {
  params: field => field().value(),
  factory: username =>
    injectQuery(() => ({
      queryKey: ['username-availability', username],
      queryFn: ({ signal }) => checkUsername(username, { signal }),
    })).resource,
})

Why this should be part of the architecture

Angular signals are the reactivity primitive. Angular Resource is the async primitive. injectQuery() currently integrates with the former, but not really with the latter.

The Solid adapter is a useful comparison: it keeps the Query API, but integrates with Solid’s native async primitive under the hood. Angular now has its own equivalent async primitive, so it seems worth considering the same direction before the Angular adapter stabilizes.

The goal is not to hide TanStack Query behind Resource. TanStack Query still has important semantics that Resource does not fully capture, like stale state, background refetching, invalidation, retries, paused fetches, placeholder data, cache metadata, and separate status / fetchStatus.

So the returned object could expose both layers:

query.resource.value()
query.resource.status()
query.resource.reload()

query.data()
query.isFetching()
query.isStale()
query.fetchStatus()
query.refetch()

Open questions

• Should injectQuery() be resource-based internally?
• Should the resource be exposed as query.resource, query.asResource(), or something else?
• Should query.data() come from resource.value(), or should both come from a shared observer snapshot?
• How should TanStack Query’s status and fetchStatus map to Angular ResourceStatus?
• Should resource.reload() map to query.refetch()?
• Should resource.set() and resource.update() map to queryClient.setQueryData()?
• Should injectInfiniteQuery() follow the same model?

Since the Angular adapter is still experimental, this feels like the right time to decide whether it should be resource-first internally before the API stabilizes.