Recommended method for handling Apollo @client fields? #280
-
I've been getting up to speed on using 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 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! |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
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 mo…