Typing of `Query<>` should include query.options.enabled

[nicolassanmar]

Describe the bug

Context

I'm trying to do query invalidation based using predicates. For the particular use case, I would like to know if the query is enabled, since the typing of the queryKey may vary with it.
By using console log, I know that the queries in the query cache can have the query.options.enabled property, which I would like to use. Using query.isDisabled() is not equivalent, since it can return false even queries with enabled: false.

Issue

const queryClient = useQueryClient()
queryClient.invalidateQueries({
  predicate: (query) => {
    // query.options.enabled is not included in typing, but it is part of the object if we console log.
    return false
   },
})

Your minimal, reproducible example

https://stackblitz.com/edit/react-ts-dc5yox?file=App.tsx

Steps to reproduce

1. Create a query, and call it using {enabled: false}
2. Call the query client, and try doing query invalidation using predicate:
3. console.log the queries, you will see that the one that has enabled: false will appear as having it on:

{
...
options: {
  ...
  enabled: false
  }
}

4. Even though this happens, the typescript type says the {enabled? : boolean} property is not on the options object.

Expected behavior

I expected to have

query.options: typeof query.options & {enabled? : boolean}

as the type of the query options

How often does this bug happen?

Every time

Screenshots or Videos

No response

Platform

• Linux - Ubuntu
• Firefox and Chrome

TanStack Query version

4.20.4

TypeScript version

4.9.3

Additional context

No response

[TkDodo]

options.enabled being present at runtime is likely a side-effect of us applying all options that come from useQuery to the query via object spread. It's not something that you can or should rely on.

useQuery accepts some options that are part of the query, and some for the queryObserver that is created. enabled is an observer level property, which means you can call useQuery with the same key twice in two components, both being differently enabled. The value you can see here at runtime (and in the devtools) is likely the one that got last applied.

Still, the typings are correct and you shouldn't rely on that value being present.

For the particular use case, I would like to know if the query is enabled, since the typing of the queryKey may vary with it.

Strictly speaking, a query itself cannot be enabled or disabled - it can just "be". Observers can be disabled if they shouldn't trigger requests by themselves, that's all.

Can you elaborate on your use-case? Why would tpyings be different for enabled or disabled observers?

[nicolassanmar]

My use case is the following:
I have a query that depends on the data of another one. I use the enabled: !!data option to delay the execution until the last one starts, and I perform a non null assertion to avoid having to type my method as possibly undefined.
I know that the recommended solution is this one: #2281 (comment)
I just did not like it for this for two reasons:

• Semantically it didn't make much sense for the function to take an undefined parameter, it was just a matter of waiting until the other query finishes
• Adding undefined to the input, means the return type has to change as well, and this means that data could be undefined even if the query is a success, and I did not like that.

The only issue I had when doing things in this 'wrong way' was this. Trying to invalidate queries, I relied in the typing that was not always true, as it could be undefined when the query is not enabled.
That's the reason I would like to know if it the "query is enabled" or not.

[TkDodo]

query invalidation never targets disabled queries - there is an explicit check that filters out queries where all observers are disabled from the refetching logic:

query/packages/query-core/src/queryClient.ts

Lines 266 to 269 in 1c43f58

	this.queryCache
	.findAll(filters)
	.filter((query) => !query.isDisabled())
	.map((query) =>

[nicolassanmar]

The issue with this is that query.isDisabled() returns false for the query I mention. I find it weird, since the the query has enabled: false and will never be enabled with that input.
The query invalidatoin predicate does indeed get executed on my disabled query.
Could there be some bug there? What could make it work like that?

I'm using trpc as well as react-query, if that changes something, but in this particular case i don't think so

[TkDodo]

If you query is not disabled, it means it has at least one enabled observer :)

query/packages/query-core/src/query.ts

Lines 241 to 247 in abd1703

	isActive(): boolean {
	return this.observers.some((observer) => observer.options.enabled !== false)
	}
	isDisabled(): boolean {
	return this.getObserversCount() > 0 && !this.isActive()
	}

The devtools would show you how many observers there are, and if the query is fully disabled or not. I can't help much more without seeing the code in question.

This is turning into a discussion, so I'll move it there.