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

Custom Sorting #8

Closed
KyleAMathews opened this issue Jul 2, 2015 · 4 comments
Closed

Custom Sorting #8

KyleAMathews opened this issue Jul 2, 2015 · 4 comments

Comments

@KyleAMathews
Copy link

Didn't see anything in the spec about this. I assume it's coming?

@devknoll
Copy link
Contributor

devknoll commented Jul 2, 2015

I believe that something like this popped up in one of @leebyron's slides at ReactEurope. The gist of it is that you would expose the type of sorting that you want through field arguments.

{
  user(id: 4) {
    events(first: 1, order: IMPORTANT) {
      ...
    }
  }
}

That is, GraphQL itself doesn't have any notion of sorting. If you want results to be sorted, you would implement the appropriate arguments and semantics that you want. The reason being that GraphQL is storage and backend independent and can't really reason about that.

@KyleAMathews
Copy link
Author

Cool! Seems very reasonable.

@leebyron
Copy link
Collaborator

leebyron commented Jul 2, 2015

Thanks, @devknoll. Right on point. A field argument like order or orderBy means as much to GraphQL as fooBar. It's just a key/value pair that gets provided to the underlying function.

In the example @devknoll provided, you might imagine the backing function looking something like:

function (user, { first, order }) {
  return doSomeWorkToGetEventsForUser(user, { limit: first, orderByKey: order });
}

Where that function does something interesting like a mongodb, sql, or parse query. where ensures the understood semantics for an ordering is applied.

This is important as different backing stores have different semantics for ordering and different orderings may be more expensive and shouldn't be exposed (e.g. large tables where some columns don't have indexes, or a field that is derived information) so the implementing type system may completely choose how to represent and resolve this.

@gajus
Copy link

gajus commented Nov 2, 2015

Would be nice if this somehow got standardised.

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

No branches or pull requests

4 participants