I'll add documentation for exhaustiveness checking within Typescript

[dgreene1]

I'd like to add the readme how to document exhaustiveness checking within Typescript so that users of useQuery can:

• have Typescript tell them that data is TQueryFnData instead of TQueryFnData | undefined
• have Typescript inform them if a new status type is ever added (thereby letting consumers of react-query know that they have a new case to handle)

For example:

interface ViewUserPagePathParameters {
  userId: string;
}

interface IUser {
  id: string;
  displayName: string;
}

export function assertNever(value: never): never {
  throw new Error(`Unhandled discriminated union member: ${value}`);
}

export const ViewUser: React.FC = (props) => {
  const { userId } = useParams<ViewUserPagePathParameters >();
  const queryResult = useQuery<IUser, Error>(`getUser for ${userId}`, () => getUser({ id: userId }));

  if (queryResult.status === 'success') {
    const user = queryResult.data;
    return <div>Name: {user.displayName}</div>;
  } else if (queryResult.status === 'loading'){
    return <div>loading...</div>;
  } else if(queryResult.status === 'idle') {
    return <div>mutating...</div>;
  } else if (queryResult.status === 'error') {
    return 'An error has occurred: ' + queryResult.error.message;
  } else {
    return assertNever(queryResult);
  }
};

[TkDodo]

exhaustive matching is good, but it's a bit tedious because idle is an edge case that you need to handle, but it rarely occurs (only for disabled queries).

Type narrowing on the other hand is a very good pattern to show, it can go into the TypeScript section in the docs maybe. It's also good to not that we can discriminate by the status fields as well as the status booleans :)

[dgreene1]

Yes, I hadn’t thought of type narrowing via type guards. But the reason why exhaustiveness matching is valuable is because if you make your component of type React.FC it expects to get a return value. With type guards I’m not sure how you would be able to definitely return a React.ReactComponent type definitively. I’d like to see that covered if you have it handy.