graphql-zeus
graphql-zeus copied to clipboard
Custom ScalarResolver extensibility
Hello,
Its possible extend function export const ScalarResolver = (scalar: string, value: any)
generated in zeus-graphql.ts?
I have defined custom date scalar in my graphql schema and need extend the function. For example:
case "DateTime":
return `"${value.toISOString()}"`;
Thanks
Not possible now I think. Would you like to do it ?
Sure, now i must after each schema and types regeneration edit graphql-zeus.ts file.
Will you contribute?
Sorry, have absolute no free time :/
For others, in my side project i use replace-in-file package
npm package and replace string after zeus-graphql gen.
zeus-fix.js
module.exports = {
files: "src/api/graphql-zeus.ts",
from: ["case 'scalar':"],
to: ['case "DateTime": \n return `"${value.toISOString()}"`; \n case "scalar": ']
};
scripts:
"gen": "npm-run-all gen-api gen-fix",
"gen-api": "zeus http://localhost:54044/graphql src/api --ts",
"gen-fix": "npx replace-in-file --configFile=zeus-fix.js",
You dont have to close somebody else will take it for sure :)
Ah sorry :)
Taken over
@aexol : Is this one fixed already, if yes then how can I use this feature...
I'm starting to dig in in an attempt to make a PR to add custom scalar functionality, and I'd appreciate some confirmation/discussion on what I'm learning:
- All custom scalar types are treated as strings
- Zeus assumes that all field arguments can be serialized directly to JSON without any schema-based translation
- Zeus rewrites the JSON received from the server and reinterprets it
So let's assume we've got a CustomScalar
type defined as such:
type CustomScalar<T> = {
stringify(val: T): string;
parse(text: string): T
}
I'm starting to lean towards wrapping the zeus API so that field arguments are rewritten according to custom scalars' stringify(...)
function, the JSON-serializable field arguments are handed to Zeus, then the result is reinterpreted calling parse(...)
on all the string values that are custom scalars. This would also involve rewriting the types generated from the schema so that queries' types would expose the custom scalar types instead of strings, so that query results' types wouldn't be string, but whatever those custom types are. I don't love that it'd require an extra layer of translation but that's the path I'm headed down right now.
Thoughts? Recommendations?