Support for @oneOf directive using native Elm types

[kioan000]

Hi! 👋 First of all, thanks for your work on this library — we’ve been using it with great results.

We were wondering if there’s any interest or plan to support the GraphQL @OneOf directive in a way that maps to native Elm types — for example by generating a union type when a @OneOf input object is detected in the schema.

This would allow more type-safe modeling and better ergonomics when consuming GraphQL APIs that use @OneOf semantics (which is now being adopted by tools like Apollo Federation and OpenAPI-to-GraphQL converters).

Would this be something you’d consider supporting ?

Thanks again!

Some references:

• RFC proposal discussion
• @oneOf is now RFC3

[dillonkearns]

Hey @kioan000, I don't have bandwidth to work on that myself, but I would be happy to review PRs if you or someone else would like to tackle it! I'm not sure off the top of my head whether we would have access to that annotation in the introspection schema or not, so that would be probably a good first thing to check to see if it's viable to build something like this.

[kioan000]

Hi Dillon,

To expose that information from the introspection query, it’s enough to request the isOneOf field inside the FullType — so it should be fairly straightforward to extend the current introspection query and parse that value from the schema.

I’d be interested in giving it a try in my spare time, but I’m still not entirely clear on how the whole project works in detail to get it running locally (and I’m also running into some library compatibility issues on Apple Silicon).
Do you have any tips or guidance?

[dillonkearns]

Nice, great that there is a straightforward way to figure out that information!

I use Apple Silicon and it works well for me. I would start by running npm install && npm test and see if you can get that running.

From there, my basic process that I've used for development is to use the end to end testing functionality which generates the full GraphQL API for a schema, and then does a diff-test (also known as approval test, snapshot test, etc.). Here it is in the test script:

elm-graphql/bin/approve

Lines 22 to 27 in 7b7bdc2

	cd ../ete_tests
	# elm-graphql https://elm-graphql-normalize.onrender.com/api --base Normalize --output src
	elm-graphql --schema-file ../schemas/end-to-end-schema.json --base Normalize --output src
	elm-graphql --introspection-file ../examples/github-schema.json --base GithubNoFormat --output no-format-example --skip-elm-format
	elm-graphql --schema-file edge-cases.gql --base EdgeCases --output src
	find no-format-example src -type f -name '*.elm' -print0 | xargs -0 npx elm make --output /dev/null

I also like to manually generate some target code as a first step to verify that it is actually viable. So if I were you, I would probably start by getting a starting point for your testing - could be a new sub-project in the ete_tests folder that you setup in the approve script. Get a minimal schema that demonstrates the behavior you want to test, ideally pointing to a real service so you can test it out. Then build some hardcoded "generated" code to test out your proof of concept and make sure the API you want is viable. At that point we could discuss different options to make sure we're on the same page before you work on the actual real code generation for that target.

Then once you've decided on the codegen target, you can finally go in and change the codegen to generate that.

I'm not sure if any changes would be needed to the schema parsing to pull in those additional fields. And you may need to change the introspection query?

elm-graphql/generator/src/introspection-query.ts

Line 4 in 7b7bdc2

name

Another thing to consider is whether the different avenues of pulling in a schema all support it correctly:

elm-graphql/generator/src/Main.elm

Line 100 in 7b7bdc2

FromUrl options ->

elm-graphql/generator/src/Main.elm

Line 115 in 7b7bdc2

FromIntrospectionFile options ->

elm-graphql/generator/src/Main.elm

Line 128 in 7b7bdc2

FromSchemaFile options ->

Hope that is some helpful context! Feel free to ask more questions here or in the #elm-graphql slack channel.