Fix complex default value InputType introspection #537
Conversation
binaryseed
changed the title
|
The code I have now does a hacky thing that gets close... The problem is that I don't have a really solid way to turn the input |
binaryseed
force-pushed
the
fix-complex-input-introspection
branch
from
1b3004b
to
5571ff7
Compare
|
I added a naive encoder to get the example test passing, but I don't think this is the right solution as-is |
|
Any thoughts on this @bruce or @benwilson512 ? |
|
I’ll give this a look this weekend. Thanks, @binaryseed! |
There was a problem hiding this comment.
Thanks for taking a crack at this! Unfortunately it's a fair bit more complicated than this, since any custom scalars need to be serialized correctly, as do enums. Consequently it isn't enough to just walk through the Elixir value itself, you need to walk through the type information on the input simultaneously so that you can have serializers and so forth on hand to properly encode leaf nodes.
|
Yeah, I thought something like that might be the case. This type of capability is essentially a code formatter.. rendering an AST. Might be useful for future schema stitching work, to auto-generate queries for a backend graphql server. I may try to take a further crack at it soon.. |
|
OK I found something interesting... There is already a function in absinthe that can totally render this stuff, it's The only problem is that it takes Any idea how I could leverage that function to do the rendering? Or should I basically clone that module for |
binaryseed
force-pushed
the
fix-complex-input-introspection
branch
2 times, most recently
from
a29feae
to
0471f13
Compare
|
I found a simple way to re-use most of the code that existed, just calling it recursively to render input objects! There may be other cases like lists that I might need to check out |
|
Any progress on that? |
binaryseed
force-pushed
the
fix-complex-input-introspection
branch
from
792fee5
to
284145d
Compare
|
I updated this, it was rendering all the things properly, so I validated that in a test & cleaned up the code. At this point I suspect that master has moved quite far ahead into |
| "{#{object_values}}" | ||
|
|
||
| %Absinthe.Type.Field{type: type, name: name, identifier: identifier} -> | ||
| key = Absinthe.Utils.camelize(name, lower: true) |
There was a problem hiding this comment.
Final note here and then we can merge. Instead of doing the camelize call here, pull the adapter out of the resolution struct on line 279: _, %{schema: schema, source: %{default_value: value, type: type}, adapter: adapter} -> and then pass it in to this function. With that you should be able to do:
key = adapter.to_external_name(name, :field)
This way it will honor adapter settings if people are using custom ones.
|
Sweet, I used Also I found the @benwilson512 any other possible |
|
Is this for the next version? |
|
This looks great, thank you! |
* Test that demonstrates the bug * Dummy implementation of a fix * Add naive GraphQL encoder function * Recursively render the default value * Ensure we render all possible types & cleanup * Use adapter to determine key * Don't un-wrap, handle list / non_nul explicitly
WIP
This PR is an attempt to fix the bug that exists when introspecting a "complex" input value, ie: one that doesn't respond nicely to
to_string...closes #490