Replies: 2 comments 1 reply
-
Well, I just ended up making a custom eslint rule to omit the local fields that we have created. |
Beta Was this translation helpful? Give feedback.
-
Thanks! I described how to extend your schema here #1063 (reply in thread) extend type User {
someClientField: String!
} |
Beta Was this translation helpful? Give feedback.
-
Hello!
First off, I want to say that you all have created a phenomenal library. I've been setting it up in the past day (we have a fairly legacy setup, so some mental gymnastics were involved), and I've been enjoying the results a lot.
To get to the issue/question at hand^^
Apollo allows the creation of "local" fields which we mostly use in this fashion:
(default, en, and fr are all "string"s)
where right after the data is received by the frontend and before it's fed into a component,
translatedLabel
goes through the label object, and ouputs the string that matches the current language. Basically, the same thing as doing it with a function in the frontend after the data is received, but this way it returns the data in the query body right away.The issue: naturally, these fields like
translatedLabel
are not present in the schema because they are added client side, and they fail the@graphql-eslint/fields-on-correct-type
. I don't think I can add them manually - our schema regenerates with a script, triggered manually (yup), and is usually done after server-side schema changes. I thought about injecting the schema with these values, but im dropping that idea for now because it feels a little barbaric (every time we add this to a new type, we would have to add it in the script as well, and it seems like a pain).I thought about doing what was mentionned here:
#1063 (comment)
but I don't think it is an issue of directives? (I already have
"@graphql-eslint/known-directives": ["error", { ignoreClientDirectives: ["client"] }]
to ignore the @client) and I'm not sure I understand how to extend for example this
User
type with atranslatedLabel: String
field manually in the parserOptions/schemaMy last resort is making a custom rule to check if it has a
@client
directive and try to ignore that query field?Is there something I overlooked/missed? If anyone had tips for this, it would be very appreciated!
Beta Was this translation helpful? Give feedback.
All reactions