Get rid of the option "enabled"

[artem-malko]

The main idea here is useQuery is a hook, one of the hook's rule is "All the hooks should be executed unconditionally". But useQuery is quite special here)

The second idea is — difficulties of a query state management during render. I mean, that we have to handle not only error/loading/success, but paused too.

Cause of that flag we have to develop some ways, how to use it with TypeScript https://tkdodo.eu/blog/react-query-and-type-script#type-safety-with-the-enabled-option. But as for me (sorry @TkDodo) it's just a spike, not a solution.

And sometimes "enabled" is like a fast patch in all of the cases in my opinion. Do not think, just use enabled. I know, that it is a problem of developers in the first place, but, as I think, TanStack query should learn how to write good code =)

When do we need that option?

There is no params for a query

Actually you have such example in the docs: https://tanstack.com/query/v4/docs/react/guides/disabling-queries#lazy-queries
But, of the top of my head, this problem could be solved by different components:

• In the main component we have [filter, setFilter]
• In the child component we have useQuery.

So, we need to render the child component with useQuery only if we have any truthy value in filter. By the way, this approach allows to write more reliable applications.

Conditionals queries

const q1 = useQuery(['q1']);
const q2 = useQuery(['q2', q1.data]);

Actually this problem has the same solutions — conditional rendering =)

I'm glad to see another examples, when we need such option. And I wanna discuss it here.

So, right now I have 2 questions and 1 idea. Questions:

1. Why do we need to have that option?
2. Is it possible to get rid of it?

And the idea — to get rid of it =)

[artem-malko]

Hey, @TkDodo @Ephem what do you think?)

[TkDodo]

Why do we need to have that option?

Because it's not possible to call hooks conditionally. It's also not always easily possible or desired to split things up into multiple components, especially when writing custom hooks. Consider:

const useSomething = () => {
  const userId = useSelector(state => state.user?.id)
  return useQuery({
    queryKey: ['something', userId],
    queryFn: () => fetchSomething(userId),
    enabled: !!userId
  })
}

sure you can split that up into multiple components, but that would mean prop-drilling something that you read from a global client state manager (like redux in this example) and you can't really use custom hooks composition nicely.

it also occurs frequently when reading params with useRouter from nextJs, because those params are undefined on the first render. They return a router.isReady property that is frequently used to disable a query.

[TkDodo]

except that you can also use refetch to bypass enabled :)

[artem-malko]

except that you can also use refetch to bypass enabled :)

I didn't get it. Could you explain, pls?)

[artem-malko]

refetch has to work the same way. No Params — no request.

[TkDodo]

no, if you have the example from above:

type Param = number | undefined;

const customQuery = (param: Param) => useQuery({
  key: ['someKey', param],
  queryFn: param ?? () => { fetch(`/something/${param}`) },
});

and you call customQuery.refetch(), it will refetch. However, queryClient.invalidateQueries or queryClient.refetchQueries will not target this query.

The reason is that you can opt-out into manual mode by doing enabled: false and then just fetch with refetch() if you want to, even though it's not recommended.

This is documented here.

refetch returned from useQuery can be used to manually trigger the query to fetch.

[artem-malko]

Oh, ok. I understand. It goes to deep right now with enable.