Open marwan38 opened 5 months ago
Honestly, it's unlikely we'll be able to prioritise this feature. Would you be keen to implement it yourself?
Honestly, it's unlikely we'll be able to prioritise this feature. Would you be keen to implement it yourself?
That's my intention. I just hope I can make the time to do it.
It's taking me quite a long time, migrating our codebase across to graphql 4+. It's been over two months so at this point I'm trying to workaround the little things that have a decent workaround.
I do think directives are quite valuable (just the basic @deprecatedReason is useful). Client side directives are also used (Apollo graphql) to handle certain use cases. They are also a part of the graphql specification.
No promises, but.. we'll see after I finish my current task.
Description
Directives are a fundamental part of GraphQL and as such I believe should be part of the base providing of any GraphQL implementation. It should be fairly straight forward to add as it's not much different from adding a new type, or interface, etc. Happy to do it with a bit of guidance.
Additional context or points of discussion
I would not ask or bother with this feature were I able to access the GraphQL schema directly during schema build, but I haven't been able to achieve that as the schema instance is generated right before generating the schema (as far as I understood the source code). If we can expose the schema, I'd prefer doing that as it's much less work Adding a directive is as easy as:
That is all.
Validations
PRs