Selecting implementation attributes from interfaces #577
Comments
|
Hey @Hazelfire, thanks for the discussion. I see what you're saying there, that's an interesting point. I think you're right that the Another idea, though a much more drastic change, would be to use Records as the Phantom Types. So taking this example from the Star Wars API example, since I'm looking at this source code in the examples folder for this one: elm-graphql/examples/src/Swapi/Object/Human.elm Lines 60 to 64 in 8dcf2b4 elm-graphql/examples/src/Swapi/Interface/Character.elm Lines 81 to 85 in 8dcf2b4 elm-graphql/examples/src/Swapi/Query.elm Lines 72 to 85 in 8dcf2b4 What if it was something like this: -- in Swapi.Interface.Character
name : SelectionSet String { objectHuman : () }
name =
Object.selectionForField "String" "name" [] Decode.string-- in Swapi.Interface.Character
name : SelectionSet String { interfaceCharacter : (), objectHuman : (), objectDroid : () }
name =
Object.selectionForField "String" "name" [] Decode.stringhero :
(HeroOptionalArguments -> HeroOptionalArguments)
-> SelectionSet decodesTo { character | interfaceCharacter : () }
-> SelectionSet decodesTo RootQueryThis would allow you to have Benefits of Record ApproachThis is lightweight in a few ways.
Downsides of Record Approach
ThoughtsAnyway, just throwing an idea out there, still need to think on it a little to decide if it's good or not. But seems like it might be worth considering that direction more seriously. |
|
I've come back to this several times, trying to understand what you mean and how it could be implemented. I think I get the general idea, but I do think that it might be a bit too on the nose of what's possible, and a much simpler implementation with much more obvious ways to do this might be preferable, at least in my eyes. |
This is a very early stage issue / suggestion. Feel free to ignore it for now, I'll come back to it with better details once I've verified the way we can implement it. Sorry if this is a duplicate.
In my usage of elm-graphql, I came across a use case of interfaces that doesn't seem to be covered by this library.
Say, you have a schema:
With this implementation, I have an interface but no field that actually references that interface. The reason I've defined this is because in Elm code, I can now do:
And I can abstract the way that I retrieve the ID across nodes, so that in my object selection code, I have:
This however fails, because nodeSelector is of type
SelectionSet Node App.Interface.Nodewhen it wants it to beSelectionSet Node App.Objects.Course.Having this functionality, allowing you to select from an object fields from an interface it implements, seems pretty trivial, I haven't properly tested whether this would work, but because the second element in SelectionSet is just a phantom type, I'd imagine adding something similar to the following would work perfectly fine.
This is however, currently completely untested. So consider this issue to be in a draft stage. Feel free to also tell me I'm using GraphQL wrong.
The text was updated successfully, but these errors were encountered: