Description
This is currently a known limitation, a non-critical bug. It does not affect the correctness of the response returned, but affects readability and is non-compliant to current spec. Will be addressed some time, but low priority for now, I guess. PR welcomed of course 😄
According to specs (as of April 2016),
Field Ordering When querying an Object, the resulting mapping of fields are conceptually ordered in the same order in which they were encountered during query execution, excluding fragments for which the type does not apply and fields or fragments that are skipped via
@skipor@include directives. This ordering is correctly produced when using the CollectFields() algorithm.Response formats which support ordered maps (such as JSON) must maintain this ordering. Response formats which do not support ordered maps may disregard this ordering. https://facebook.github.io/graphql/#sec-Objects
For eg:
{
foo
...Frag
qux
}
fragment Frag on Query {
bar
bad
}
Should produce the ordered result:
{
"foo": 1,
"bar": 2,
"baz": 3,
"qux": 4
}
Current implementation does not fulfil this requirement.
The return JSON response order is at the mercy of default encoding/json marshaller implementation and how maps are handled in Go (non-deterministic ordering).
PR welcomed! Cheers