How to pass arguments from one field to the next

[sgrove]

This is related to #28, trying to have an argument for a field that allows explicit depth, e.g.

item(id: 1) { 
  comments(depth: 10) {
    text
    id
    comments
  }
}

Assuming comment is an io_field,

1. How do I provide a default value for depth? ~default:(Some 1) causes a type error I can't quite get around
2. Each time before recursing into comments, I want to check if depth is positive, and if so recurse into comments while decrementing the depth argument.

Would you mind providing an example?

[andreas]

First of all, thanks for continuing to try ocaml-graphql-server and providing feedback! It seems you have hit a bug wrt. default values for arguments. It currently only works in very naive cases. I'm working to fix this now and will back to you with a solution soon (I hope!).

About recursing into comments a variable number of times: this is a little tricky to express as a GraphQL query. The query you show would only return comments and their comments (2 levels). I'm not aware of a clever way to achieve this without actually writing out each level in the query itself. As such, this is not a shortcoming of ocaml-graphql-server, but of GraphQL itself. If you find otherwise, please let me know.

[sgrove]

Yes, you're correct about that, and Lee Byron has made a suggestion using fragments + spread + manually writing out the depth graphql/graphql-spec#91 (comment) - I was hoping I could express that as an argument at the top level via the depth to comments, and when it went to resolve comments in its field, the depth parameter would have been passed along and used to determine if it should recur further. That's may not be possible, though, unless you can think of some way of allowing it?

[martijnwalraven]

Hmmm, I don't know anything about the implementation of the OCaml server, but I don't really see how this could work within the GraphQL type system. What is the type of the nested comments field? If it is a list of objects, you'll have to specify a selection set. And the executor will only resolve those fields, it will never implicitly recurse.

#28 refers to recursive type definitions in a schema, which other servers also support and which is perfectly fine in GraphQL. But there is no way to express recursion in a query without fragments, and recursive fragments are explicitly disallowed.

[andreas]

@sgrove, unfortunately I don't have a better suggestion than what was mentioned by Lee Byron.

I have fixed default arguments, though (see #30) 😄