Suggestion: Enhance Type Definitions for GQLExtensions and FetchResponseBody

[marcos-mo-loox]

Suggestion: Enhance Type Definitions for GQLExtensions and FetchResponseBody

Background

We are currently working on enhancing our GraphQL infrastructure and are evaluating the integration of this package. During our review, we encountered a few areas where the type definitions could better align with common usage patterns and improve type safety.

Problem Description

1. GQLExtensions Type

   • Currently, GQLExtensions is typed as Record<string, any>.
   • While this provides flexibility, it lacks specificity and omits fields like cost, which we believe should be included by default.
   • Explicitly including common extension fields like cost would improve the developer experience and reduce ambiguity.

2. FetchResponseBody Extensions Field

   • The extensions,data,errors,headers fields in FetchResponseBody are optional.
   • However, in our testing, this field is always present in successful responses.
   • Making it required would improve type safety and prevent unnecessary null checks.

Proposed Solution

• Enhance the GQLExtensions Type

  • Include common fields like cost while maintaining flexibility to accommodate additional fields.

• Update the FetchResponseBody Type

• Introduce a SuccessClientResponse type for responses containing data and extensions.

• Introduce an ErrorClientResponse type for responses containing errors.

This separation would allow for more explicit handling of success and error scenarios, aligning with common GraphQL response patterns.

Question

Would these changes align with your roadmap for the package? We believe this improvement could enhance the package’s usability for GraphQL clients.

Thank you for your consideration!

[lizkenyon]

Hi there 👋

Thank you for the flag! To clarify you are speaking about the GraphQL client package specifically?
If you would like to make a PR the team would prioritize reviewing it.
Otherwise I can add this to the teams backlog.

[github-actions]

We're labeling this issue as stale because there hasn't been any activity on it for 60 days. While the issue will stay open and we hope to resolve it, this helps us prioritize community requests.

You can add a comment to remove the label if it's still relevant, and we can re-evaluate it.