type guards for useQuery

[tnyo43]

I created a simple todo app with GraphQL Code Generator. The code is quite similar to the one in the urql React tutorial.

import React from 'react';
import { useQuery } from 'urql';
import { graphql } from './gql';

const TodosQuery = graphql(`
  query getTodos {
    todos {
      id
      title
    }
  }
`);

const Todos = () => {
  const [result, reexecuteQuery] = useQuery({
    query: TodosQuery
  });

  const { data, fetching, error } = result;

  if (fetching) return <p>Loading...</p>;
  if (error) return <p>Oh no... {error.message}</p>;

  return (
    <ul>
      {data.todos.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );
};

Then, I got a following type error, because the type of data is not GetTodosQuery but GetTodosQuery| undefined

'data' is possibly 'undefined'.ts(18048)

I could solve it by adding a line which checks if data is undefined.

  if (fetching) return <p>Loading...</p>;
  if (error) return <p>Oh no... {error.message}</p>;

+  if (!data) return <p>Something happens :(</p>;

  return (
    <ul>
      {data.todos.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );

I'm wondering if it can happen that all of fetching, error and data are falsy. If not, I think we could clear this problem by updating the definition of UseQueryState.

If we update UseQueryState as like the folliowing code, we can use type guards, which means we can assume data is not undefined if both fetching and error are falsy without checking data by if (!data) .... (I'm sorry that I'm not familiar with the use of interface...)

export type UseQueryStateValue<
  Data = any,
  Variables extends AnyVariables = AnyVariables
> =
  | {
      stale: boolean;
      extensions?: Record<string, any>;
      operation?: Operation<Data, Variables>;
    } & (
      | { fetching: true; data?: Data; error?: CombinedError }
      | { fetching: boolean; data: Data; error?: never }
      | { fetching: boolean; data?: never; error: CombinedError };
    );

---

Maybe, some suggests me that we can write the following code to skip writing the annoying if (!data) .... But with this code, we may be forget some behavior. For example, even if we forget to write {fetching&& ...}, we can get no error but nothing displays while fetching.

const Todos = () => {
  const [result, reexecuteQuery] = useQuery({
    query: TodosQuery
  });

  const { data, fetching, error } = result;

  return (
    <>
      {fetching && <p>Loading...</p>}
      {error && <p>Oh no... {error.message}</p>}
      {data && (
        <ul>
          {data.todos.map((todo) => (
            <li key={todo.id}>{todo.title}</li>
          ))}
        </ul>
      )}
    </>
  );
};

---

Anyway, no matter how, I really appreciate if we have type guard with useQuery :)

---

references

reproduction: https://github.com/tnyo43/urql-request-type-guard/blob/a64238aa4375a645f45352eaf06bede1e7239011/src/Todo.tsx

[kitten]

So, there's several questions and answers around on this topic, including code snippets of people creating these types guards. However, it's important to understand that unfortunately a lot of them are wrong and some of them are unsafe 😅

In short, all of the properties you mention can be nullish, independent of each other.

• You've already noticed in your sample type that fetching is just UI state, so it can be always independently set from the other result properties
• fetching being false doesn't imply that a result has been delivered. It may also indicate that the hook has always been paused. It's only state that bindings add on
• data not being present does not necessarily mean that an error will be present in edge cases like cache-only requests. It may still be null in these cases, but we don't differentiate between these

In short, if you can ensure that these aren't the case, it's safe to leave the above cases out, however, as you can see, none of these are strictly guaranteed, and even tightening the types a little at the bindings level doesn't necessarily increase these guarantees.

The safest way to handle this is to also ensure that !data is handled in your error branch.

[tnyo43]

Now I know that I was taking things too simple and my proposal based on a false premise.
Thank you for your helpful answer.