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://codesandbox.io/s/vibrant-poincare-mojft4?file=/src/index.jsx

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.

[nicolassanmar]

Thanks for the clarification @TkDodo !
The reason I'm getting isDisabled() false in my codebase, is that there are no observers on the query.

The workaround I found to avoid using query.enabled is:

!query.isActive() && query.state.status === 'loading' && query.state.fetchStatus === 'idle'

Is this the best we can do?

[TkDodo]

If there are no observers, the query is "inactive", which you can filter for separately.

[nicolassanmar]

@TkDodo Here is a better example I made, where we can see that

query.options.enabled // false - State I would like to get
query.isDisabled() // false - Is not what I would expect to see, since I was expecting the opposite

Does the example I provide here count as having an active observer?
In the dev tools I can see that the only observer has a observer.options.enabled of false
https://codesandbox.io/s/vibrant-poincare-mojft4?file=/src/index.jsx

[TkDodo]

in your example, you are executing invalidateQueries directly during render, before the observer has been registered (which is a side-effect, so it cannot happen during render)

I've moved the invalidate call behind a button click and it works as expected:

https://codesandbox.io/s/usequery-forked-cln6vx?file=/src/index.js

[ftzi]

@TkDodo It seems that the problem is the following:

1. y: undefined | { a: { b: { ... } }
2. useQuery(['x', { data: y! }], { enabled: !!y })

invalidate({ predicate: ({ queryKey: [path, input] }) => {
  input.data.a.b
})

4. Error, tried to access data.a.b but data is undefined.

I believe this is unexpected as the enabled was false but it was added to the cache anyway and run by the predicate callback.

Is this expected and if so, what would be the right general workaround, without checking for undefined inputs?

Here we can see the error:
https://codesandbox.io/s/usequery-forked-58n82t

[TkDodo]

I believe this is unexpected as the enabled was false but it was added to the cache anyway and run by the predicate callback.

to the best of my knowledge, this is expected. again, a query cannot be enabled or disabled - it can just be. You can have multiple observers per query, and each one can be enabled or disabled, which means it will by itself trigger a fetch. If all observers are disabled, the query will not fetch.

It will still be passed to the predicate function because it exists.

Is this expected and if so, what would be the right general workaround, without checking for undefined inputs?

To answer this, I would need to know your use-case. Why are you even using the predicate function for example :)

[ftzi]

My use case is the following:

My trpc query has multiple properties. When I invalidate, I only have the item id, not the other properties, so that's why I need predicate (the invalidate input type is not Partial). The item id may be nested, so that's where my problem is raised as enabled leads to undefined items where I may take the id from.

That's why it's useful to me a predicate that only considers queries that have enabled=true, so I can type safely check for the nested id prop. As enabled can have any condition, doing deep partial for a general solution wouldn't work, as the input could have another value than undefined.

Also, as I use trpc, I can't check for the enabled condition on the queryFn instead of the enabled prop.

Please let me know if I got something wrong there!

[TkDodo]

My trpc query has multiple properties. When I invalidate, I only have the item id, not the other properties, so that's why I need predicate (the invalidate input type is not Partial).

from a pure react-query perspective, if your queryKey is:

['my-path', { a: 'b', foo: 'bar' }]
['my-path', { a: 'b', something: 'else' }]

it should be possible to target them both for query invalidation by doing:

queryClient.invalidateQueries({
  queryKey: ['my-path', { a: 'b' }]
})

because that does fuzzily match them both. It might be that trpc doesn't have a concept for that though ...