type guards for `useQuery` #3277

tnyo43 · 2023-06-16T00:41:35Z

tnyo43
Jun 16, 2023

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 8000 type guard with useQuery :)

references

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

kitten · 2023-06-16T08:18:50Z

kitten
Jun 16, 2023
Maintainer

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.

1 reply

tnyo43 Jun 17, 2023
Author

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

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

type guards for `useQuery` #3277

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment 1 reply

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

type guards for useQuery #3277

Uh oh!

tnyo43 Jun 16, 2023

Replies: 1 comment · 1 reply

Uh oh!

kitten Jun 16, 2023 Maintainer

Uh oh!

tnyo43 Jun 17, 2023 Author

type guards for `useQuery` #3277

tnyo43
Jun 16, 2023

Replies: 1 comment 1 reply

kitten
Jun 16, 2023
Maintainer

tnyo43 Jun 17, 2023
Author