Recommended method for handling Apollo @client fields?

[carsondarling]

I've been getting up to speed on using gql.tada an am wondering if there's a recommended method for handling Apollo's local-only fields. My current implementation returns those fields as unknown, is there an easy way to specify a type on the TadaDocumentNode?

For example, if I have the following:

// Query
const query = graphql(
  `
    query getComponent {
      component {
        id
        name
        path @client    // This is the local-only field that is computed client-side
      }
    }
  `,
);

// Cache
const cache = new InMemoryCache({
  typePolicies: {
    Component: {
      fields: {
        path: (_, { readField }) => {
          return `/${shortenUUID(readField('id'))}`;
        },
      },
    },
  }
});

when I execute that query, I get an object back that has path: unknown. One possible approach is to mitigate this with a custom hook that modifies the TData and TVariables generics of Apollo's useQuery:

export const useGetComponent = () =>
  useQuery<
    { id: string; name: string; path: string },
    VariablesOf<typeof GET_BILLING_INFORMATION>
  >(query);

but that approach loses much of the benefits of having the typed query in the first place.

I appreciate any input!

[JoviDeCroock]

Currently we have no support for this and you're also the first to ask. I guess this is a bit of a hard one but a possibility here is to run our generate-schema helper and maintaining a second schema that you merge with the generated schema. This way you can reflect the client-side extensions of your server side schema. When you have your schema reflecting the extensions you can generate your tada-output and you are off to the races.

In your case the local schema would only contain type Component { path:String } which would be merged with your server one to form the extended type.

We can't really predict the type nor can we know where these fit so this for the time being feels like the most elegant solution.

[kitten]

on a side-note, I can understand that @client are an interesting option to quickly abstract state. (While I'd always recommend separate state containers, e.g. signal-like libraries, that isn't of course always desireable in every setup)

However, in your example you're deriving a value that should either be dictated by the GraphQL API itself, since the UI depends on it, or derived in the UI from result data, since it's a transparent, computed value.

Meaning, for example, it's already possible to write a function that defines a fragment, consumes that data by accepting it as an argument, and returns that derived value — all without diverging from your schema with @client.

This doesn't apply to cases where actual client-state is stored in Apollo Client (which... I don't agree with necessarily, but is of course a feature that exists, and hence, does pose a problem here), but thought I'd point this out, since in this specific case there's an alternate pattern

[carsondarling]

Thanks @JoviDeCroock, merging schemas makes a ton of sense, and I can definitely understand why it's not baked in to gql.tada. I'll do some more experimentation and see what I can come up with.

@kitten you're definitely right that the example field could just as easily be derived in the UI, and that's likely the solution we'll move towards in the near future. We do have a couple of other small pieces of state that are tracking using local-only fields (it didn't make sense at the time to roll another state management system), but there's no reason they can't be migrated out of the schema or moved backend.

For the sake of anyone else that ends up on this discussion (and realistically myself when I return and have forgotten), we will most likely change our implementation to be something along the lines of:

// Query
const query = graphql(`
  query getComponent {
    component { // Remove the local-only field
      id
      name
    }
  }
`);

export const useGetComponent = () => useQuery(query);

function getComponentPath(component: { id: string}) {
  return `/${shortenUUID(component.id)}`;
}

// In use:
const { data } = useGetComponent();
const path = getComponentPath(data.component);

[carsondarling]

Also, just wanted to thank you both for the awesome work you're doing, it's definitely improving my DX quite a lot