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.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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