-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
Issue Description
I have a query where all the fields have @include directive, and are included conditionally, different sets based on different scenarios. And if none of the fields get included, useSuspenseQuery behaves strange.
For simplicity sake, and in the reproduction, let's say there's only one field, and that field is with @include directive. If there would be more fields but without this directive, this issue wouldn't manifest. errorPolicy is left at default.
If that query is used in useSuspenseQuery, and that field is not included (basically @include (if: false)), useSuspenseQuery does one of the two things:
If fetchPolicy is left to the default, it never resolves. I don't think this is correct, because the query did resolve, i.e. backend returned empty data: {} object, which is the expectation.
If fetchPolicy is cache-and-network, then useSuspenseQuery resolves but data becomes null. And useSuspenseQuery typescript signature suggests that data will never be null with the default errorPolicy. dataState in this case is empty and error is undefined, whereas I would expect data: {}, dataState: 'complete', which would also conveniently satisfy typescript signature. So either the behavior with empty data is not fully correct, or typescript signature should be changed to allow data to be null even with the default errorPolicy, which would probably greatly reduce useSuspenseQuery ergonomics.
In my case I can workaround this by checking if any of include variables is true, and use skipToken otherwise thus not executing query at all, but I think the basic case shouldn't behave as it does now either way.
Thank you for the great work, this library is a joy to use.
Link to Reproduction
Reproduction Steps
No response
@apollo/client version
4.0.11