Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Respect query object field order #612

Closed
ck3d opened this issue Aug 28, 2021 · 6 comments
Closed

Respect query object field order #612

ck3d opened this issue Aug 28, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@ck3d
Copy link

ck3d commented Aug 28, 2021

Description of the feature

According to GraphQL specification the object field order in a query should be respected:

GraphQL Objects represent a list of named fields, each of which yield a value of a specific type. Object values should be serialized as ordered maps, where the queried field names (or aliases) are the keys and the result of evaluating the field is the value, ordered by the order in which they appear in the query.
https://spec.graphql.org/June2018/#sec-Objects

In the current implementation the fields are alphabetically sorted.

@ck3d ck3d added the enhancement New feature or request label Aug 28, 2021
@sunli829
Copy link
Collaborator

Yes, but I think this does not seem to be important? If you really need this, please tell me why. 🙂

@ck3d
Copy link
Author

ck3d commented Aug 28, 2021

I do not rely on this behavior, but I was astonished while comparing Juniper with your great implementation.

@gyzerok
Copy link

gyzerok commented Oct 26, 2021

@sunli829 while I am also not sure why this might be important, I think it does make sense to follow specification strictly. That's the goal of having spec, isn't it? 😄 There could be tools which might rely on this behavior and it might be tricky to debug why something isn't working in this case.

Imagine someone who is using async-graphql with library X on the frontend. This someone might not know GraphQL spec to the word. Now this someone gets unexpected behavior from library X. They could spend hours trying to figure out what's wrong.

Also, to be honest it breaks my head a bit, when I am working in the playground. Because it's a bit hard to match what I see in the query and what I see in the response.

@sunli829
Copy link
Collaborator

sunli829 commented Oct 26, 2021

@sunli829 while I am also not sure why this might be important, I think it does make sense to follow specification strictly. That's the goal of having spec, isn't it? 😄 There could be tools which might rely on this behavior and it might be tricky to debug why something isn't working in this case.

Imagine someone who is using async-graphql with library X on the frontend. This someone might not know GraphQL spec to the word. Now this someone gets unexpected behavior from library X. They could spend hours trying to figure out what's wrong.

Also, to be honest it breaks my head a bit, when I am working in the playground. Because it's a bit hard to match what I see in the query and what I see in the response.

You are right, I will support this now. 🙂

@sunli829
Copy link
Collaborator

Released in v2.10.6.🙂

@ck3d
Copy link
Author

ck3d commented Oct 26, 2021

Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants