Ergonomic conditional / dependent queries

[seiyab]

I wonder if we can execute conditional / dependent queries with API like following.

function MyComponent() {
  const fetcher = useFetcher();

  const x = fetcher.fetch(["query1"], () => myAsyncFunction1());
  if (!x.isSuccess) return <span>loading x...</span>;

  const y = fetcher.fetch(["query2", x.data.id], () => myAsyncFunction2(x.data.id));
  if (!y.isSuccess) return <span>loading y...</span>;

  return <div>
    {/* something using y.data */}
  </div>
}

Is it feasible?

Following CodeSandbox is a rough proof of concept.
https://codesandbox.io/s/nice-sun-diu0uc?file=/src/App.tsx

Though CodeSandbox looks "works" for me, it might be broken under some use cases.
I'm not familiar with react-query's internal lifecycle.

Idea to realize this API (added on 2023-01-27)

To realize it, I think following conditions should be satisfied.

• fetcher.fetch should return query cache immediately (doesn't return Promise).
• Executions of queryFn should happen in useEffect hook.
• Component should subscribe changes of the results.
• Component should unsubscribe queries that is not used for the latest render.

useFetcher in the CodeSandbox works like following way.

• useFetcher has a local variable observers, which stores QueryObserver that is necessary for current render.
• useFetcher invokes useEffect. The effect is "subscribe all the observers. and unsbscribe them at cleanup.".
  • subscribing QueryObserver will invoke queryFn.
• fetcher.fetch creates a new QueryObserver on each call and push it to observers. And it returns a result from the current cache.

This seems to satisfy the conditions above.

[louis-young]

Hi 👋

Have you seen the documentation on dependent queries? I like how they're expressed, personally. Are the current ergonomics a pain point for you?

https://tanstack.com/query/v4/docs/react/guides/dependent-queries

I wonder if your implementation would violate the rules of hooks somewhere internally, although I haven't looked at the internals in much detail so perhaps that's a moot point.

[seiyab]

Hi, thank you for your reaction😊
I've already read the document and I'd followed the API.
However, current API can't receive advantages of type narrowing and I think plain if-statement is more confortable for many developers.

And I think CodeSandbox does't violate rule-of-kooks.

[louis-young]

No problem 🙂

Yeah, I understand your frustration. The TypeScript compiler cannot (rightly so) infer/guarantee that the query function won't be called when an option is disabled. You can also call refetch manually on a disabled query (see: https://tkdodo.eu/blog/react-query-and-type-script#type-safety-with-the-enabled-option). I think there has been some discussion around this but I don't know what the outcome was, unfortunately.

Personally, I solve this by rejecting or throwing from the query function. This satisfies the compiler and isn't too onerous in my opinion. I agree though, it'd be ideal if we could do something a little nicer here.

With regards to the rules of hooks, I don't think the linter will pick it up given the level of abstraction here (interacting with library code) even if the lint rule is enabled and configured. I'm essentially thinking about where and how query state is managed, and how that'd work if things were no longer called unconditionally. Just a thought. I haven't looked at the internals in much detail.

[seiyab]

Thank you, the blog post and your solution help me 😄

I'll add my idea how useFetcher might "work" later.

[seiyab]

I added it.

[Newbie012]

See #4727

[seiyab]

Thanks, it's good to know and sounds great 👍
And I think #4883 is still worth a discuss because #4883 can handle not only dependent queries but also conditional queries.

[seiyab]

(If it's feasible.)