You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API I've been working on has created some custom directives to make development easier, and usage of these relies on the mapSchema from @graphql-tools/utils to transform the schema.
I do realize that the extension can be configured to connect to the remote (localhost) api service to introspect the schema - however, that doesn't allow for proper Go-To Definition to work either - since the schema is split among a number of different files and introspection treats it as a single temporary large schema file.
I know this extension can be configured for glob pattern schema files schema: '**/*.gql' - and that works good for the Go-To definition, but errors due to the directives injecting extra fields onto the types.
Offline schema is also preferred since the developer doesn't actually have to spin up the api for it to start working.
Our custom @inherits directive looks up the UserBase type, get the fields and merges them onto the type User that it is decorating - with the resulting type (once the API is running) looking like this:
"""@inherits from UserBase """typeUserimplementsUserBase {
created_at: DateTime"""@inherits from UserBase .user_id"""user_id: ID!"""@inherits from UserBase .username"""username: String!"""@inherits from UserBase .first_name"""first_name: String"""@inherits from UserBase .middle_name"""middle_name: String"""@inherits from UserBase .last_name"""last_name: String
}
It would be awesome if there was some way to configure the extension (and therefore the language-server) by providing an extra script or function to introduce our own schema mapping so we can help the language server understand our custom directives.
If something like this were possible, an extra enhancement would be to allow the extensions customization to indicate the original file/line that the Go-To definition would take when encountering these injected fields.
The text was updated successfully, but these errors were encountered:
@Borvik there is a new interface for customizing jump to definition that I just added that would facilitate this! I can't remember what I named it, will check when Im home, but it can be configured from your graphql config file. it was designed to match a similar capability in relay LSP (which I might add, does not require relay and is a nice alternative to our LSP!)
I'd be very interested to know what that would be - though the request isn't purely about the jump to definition, it's mostly about the ability to handle schema transforms that aren't available to be parsed from the source *.gql files
I wonder if we can't solve this issue with graphql-config itself, as it allows very dynamic appraches for loading schema. I will circle back to this soon as I clear up some other things
The API I've been working on has created some custom directives to make development easier, and usage of these relies on the
mapSchema
from@graphql-tools/utils
to transform the schema.I do realize that the extension can be configured to connect to the remote (localhost) api service to introspect the schema - however, that doesn't allow for proper Go-To Definition to work either - since the schema is split among a number of different files and introspection treats it as a single temporary large schema file.
I know this extension can be configured for glob pattern schema files
schema: '**/*.gql'
- and that works good for the Go-To definition, but errors due to the directives injecting extra fields onto the types.Offline schema is also preferred since the developer doesn't actually have to spin up the api for it to start working.
A very small sample of what we are doing:
Our custom
@inherits
directive looks up theUserBase
type, get the fields and merges them onto the typeUser
that it is decorating - with the resulting type (once the API is running) looking like this:It would be awesome if there was some way to configure the extension (and therefore the language-server) by providing an extra script or function to introduce our own schema mapping so we can help the language server understand our custom directives.
If something like this were possible, an extra enhancement would be to allow the extensions customization to indicate the original file/line that the Go-To definition would take when encountering these injected fields.
The text was updated successfully, but these errors were encountered: