Doesn't work with ts-pattern

[2coo]

Issue 1: Unused Fields Detection

When using ts-pattern for type matching, TypeScript doesn't detect that certain fields, such as users.name, are used. This leads to false warnings like:

Field(s) 'users.name' are not used.ts(52005)

import { useQuery } from "urql";
import { match, P } from "ts-pattern";
import { graphql } from "gql.tada";

const AppGraphQLDocument = graphql(
  `
    query App {
    # Field(s) 'users.name' are not used.ts(52005)
      users {
        __typename
        id
        name
      }
    }
  `
);

function App() {
  const [result] = useQuery({
    query: AppGraphQLDocument,
  });

  return (
    <>
      {match(result)
        .with(
          {
            fetching: true,
          },
          () => "Loading..."
        )
        .with(
          {
            data: {
              users: P.when((users) => {
                return Array.isArray(users) && users.length > 0;
              }),
            },
          },
          ({ data: { users } }) =>
            users.map((user) => {
              return (
                <div>
                  <p>{user.name}</p>
                </div>
              );
            })
        )
        .otherwise(() => "No orders found")}
    </>
  );
}

export default App;

Issue 2: Type Narrowing with __typename field

TypeScript fails to narrow the type when using ts-pattern to match on the __typename field. For example, the following code throws a type error:

Type '{ __typename: "Robot"; ... } | { __typename: "Human"; ... }' is not assignable to type '{ [$tada.fragmentRefs]: { RobotComponent: "Robot"; }; }'.

{match(user.__typename)
  .with("Robot", () => <Robot key={user.id} data={user} />)
  .with("Human", () => <Human key={user.id} data={user} />)}

import { useQuery } from "urql";
import { match, P } from "ts-pattern";
import { graphql } from "gql.tada";
import Robot, { robotComponentFragment } from "./components/Robot";
import Human, { humanComponentFragment } from "./components/User";

const AppGraphQLDocument = graphql(
  `
    query App {
      users {
        __typename
        id
        ...RobotComponent
        ...HumanComponent
      }
    }
  `,
  [robotComponentFragment, humanComponentFragment]
);

function App() {
  const [result] = useQuery({
    query: AppGraphQLDocument,
  });

  return (
    <>
      {match(result)
        .with(
          {
            fetching: true,
          },
          () => "Loading..."
        )
        .with(
          {
            data: {
              users: P.when((users) => {
                return Array.isArray(users) && users.length > 0;
              }),
            },
          },
          ({ data: { users } }) =>
            users.map((user) => {
              return match(user.__typename)
              // Type '{ __typename: "Robot"; id: number; [$tada.fragmentRefs]: { RobotComponent: "Robot"; }; } | { __typename: "Human"; id: number; [$tada.fragmentRefs]: { HumanComponent: "Human"; }; }' is not assignable to type '{ [$tada.fragmentRefs]: { RobotComponent: "Robot"; }; }'.
              // Type '{ __typename: "Human"; id: number; [$tada.fragmentRefs]: { HumanComponent: "Human"; }; }' is not assignable to type '{ [$tada.fragmentRefs]: { RobotComponent: "Robot"; }; }'.
              //   Types of property '[$tada.fragmentRefs]' are incompatible.
              //     Property 'RobotComponent' is missing in type '{ HumanComponent: "Human"; }' but required in type '{ RobotComponent: "Robot"; }'
                .with("Robot", () => <Robot key={user.id} data={user} />)
                .with("Human", () => <Human key={user.id} data={user} />)
                .otherwise(() => null);
            })
        )
        .otherwise(() => "No orders found")}
    </>
  );
}

export default App;

[kitten]

It's not possible for us to detect when certain sub-parts of the types are used when any indirection occurs. Even if we made the detection more complex, there'll always be parts of this that we can't track since we don't have access to a type dependency graph, so to speak, and can't scan every part of the document. Doing this would lead to a lot of derivative types that are hard to detect as usage patterns for fields.

As such, it often makes sense to turn the field usage feature off in these cases

[2coo]

Thank you for the detailed explanation! I understand the challenges with tracking field usage due to the lack of a type dependency graph and the potential performance implications.

However, I believe it would be valuable to support ts-pattern usage in Issue #1 (unused fields detection). To balance the trade-offs, would it be possible to implement this as an optional feature controlled via a configuration flag, such as trackTsPatternFieldUsage in tsconfig.json?

{
  "plugins": [
      {
        "name": "gql.tada/ts-plugin",
        "schema": "./schema.graphql",
        "tadaOutputLocation": "./src/graphql-env.d.ts",
        "trackTsPatternFieldUsage": true
      }
    ],
}

This way, users who rely on ts-pattern for pattern matching but still want unused field detection could opt in. Those concerned about performance or complexity can leave it disabled by default.

This feature would help bridge the gap for users combining modern pattern-matching libraries like ts-pattern with gql.tada, especially since ts-pattern is becoming increasingly popular in TypeScript projects.

Thanks again for your great work!

[kitten]

it's a combination of a technical impossibility and a maintenance constraint.
See: https://github.com/0no-co/GraphQLSP/blob/main/packages/graphqlsp/src/fieldUsage.ts

If we replace this approach, some type inference patterns and some more libraries may start working. But generally, I'm saying, don't bet on this, and don't expect this to either be solid or comprehensive.

As per the note of adding specific support for a library, no, that doesn't scale. If we were to put in specific support for a single library, that means:

• we have to hard-code its detection and API, which is a no-go
• if we then go through a cycle of a library gaining support and losing support, that time was essentially wasted

There simply isn't a way to support a specific library. There are ways the generic detection can be improved, but again, we wouldn't track support against specific libraries, unless it's directly GraphQL-client-related