Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: Type narrowing for data after checking error #3750

Closed
y-hsgw opened this issue Feb 7, 2025 · 2 comments
Closed

RFC: Type narrowing for data after checking error #3750

y-hsgw opened this issue Feb 7, 2025 · 2 comments
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release

Comments

@y-hsgw
Copy link
Contributor

y-hsgw commented Feb 7, 2025

Summary

This issue proposes a stricter definition for OperationResult types.
I couldn't narrow down the type of data after checking error.
Present:

import { registerUrql } from '@urql/next/rsc';

const { getClient } = registerUrql(...);

export default async function Home() {
  const { data, error } = await getClient().query(PokemonsQuery, {});

  if (!error) return null;
  
  console.log(data); // type is `object | undefined`

  return ...
}

Expected Behavior:

export default async function Home() {
  const { data, error } = await getClient().query(PokemonsQuery, {});

  if (!error) return null;
  
  console.log(data); // type is `object`

  return ...
}

Proposed Solution

I propose the following changes:

ea609b1

This ensures that the type of data is narrowed after checking for error.

Requirements

@y-hsgw y-hsgw added the future 🔮 An enhancement or feature proposal that will be addressed after the next release label Feb 7, 2025
@JoviDeCroock
Copy link
Collaborator

JoviDeCroock commented Feb 7, 2025

Your proposal is technically incorrect as that's not how GraphQL works. GraphQL can have both errors and data at the same time, you can find more information about that over at https://commerce.nearform.com/open-source/urql/docs/basics/errors/.

Now that doesn't mean that it's entirely incorrect to do what you're doing but the impact would be a push into the wrong direction. If the user chooses to render a different UI just because there is an error would mean that they would discard what in theory could just be one leaf-field that failed to complete its result. The beautiful part is that if you generate TypeScript types based on your schema is that you are already preparing for these scenario's due to how null bubbling works in GraphQL.

The only distinction between a legitimate null and a null resulting from an error is that the latter would be in your array of GraphQLErrors and you can trace it back because the path of said GraphQLError will match up with your missing data.

@y-hsgw
Copy link
Contributor Author

y-hsgw commented Feb 7, 2025

Thank you for your quick response!
I appreciate the explanation about how GraphQL handles errors and null bubbling.
Thanks again for taking the time to clarify!😄

@y-hsgw y-hsgw closed this as completed Feb 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future 🔮 An enhancement or feature proposal that will be addressed after the next release
Projects
None yet
Development

No branches or pull requests

2 participants