Default Field for type

[BLamy]

I'm unsure of whether this is supported but I couldn't find it anywhere. I have a use case where I am representing a tree of values which looks a little something like this

{
  val1: {
     name: "val1",
     value: "test",
     moreMetaData: "foo"
  },
  val2: {
     name: "val2",
     value: "test",
     moreMetaData: "foo"
  }  
}

95% of the time I only care about getting the 'value' property. Unfortunately, My query most of the time look like this:

query {
   val1 {
      value
   }
   val2 {
      value
   }
}

I would like to query like this and have it just get the .value property by default.

{
   val1
   val2
}

However, If the user wants to get more metadata for a variable they can as so

{
   val1 {
      name
      moreMetaData
   }
   val2
}

[robzhu]

Hey @BLamy, you can use a query fragment to avoid the repetition. Here's a good tutorial on fragments.

As for the exact behavior you're asking about, GraphQL queries must specify selections down to scalar fields. In your example schema, the type underlying val1/val2 is an intermediate node, so you cannot have it as the terminating field in the selection.

If you would like share more about your use case, I might be able to offer more suggestions.

[BLamy]

@robzhu
I'm in a situation where I have a medium tree structure (less than 1000 nodes). Most of my users are non-technical but their job will require them to be pretty familiar with this tree structure. Currently, users must use a tag explorer application, browse through the tags, find the values they want, and enter them into a spreadsheet (they don't enjoy it). I believe that GraphQL will represent their tag explorer closely enough that non-technical people will be able to construct their own reusable queries with minimal training thus speeding up the process.

Most users don't really need to know about the metadata embedded in each field (some might even be confused by it). However, I really feel I would be doing an injustice providing an API which doesn't expose access to it for more advanced users.

It's not the end of the world if I need to tell them to always put { value } but it would have been nice if I could have avoided it. Explaining the concept of fragments to them will probably cause their mind to explode. Whereas early termination would make it conceptually simpler and semantically cleaner.

[stubailo]

I think you can easily do this yourself by writing a query visitor that uses the schema to add fields where necessary. I think it would be a huge step back for GraphQL if it wasn't required to list all of the fields you want, since that's one of the primary benefits of the platform especially for building tools and client libraries.

[JeSuisNikhil]

I can think of some hacks.

Make a parallel tree so that you have two root nodes. One which has children and it's fields return {value} implicitly and the other node that provides access to the "advanced" information.

You could also add an additional field to each node for each field that has a {value} e.g. val1Value. One could argue that doing this would mess with the tree structure though.

Ideal solution IMO is to define schema based on user/role. it would require you to add a user/role based check when defining the value resolver for these fields and make it so that field implicitly returns the value for non-technical roles.

[asiandrummer]

@BLamy GraphiQL is already doing something similar - here is the reference. GraphiQL supports automatically completing a query with scalar nodes. I think this is an example of what @stubailo said in terms of writing a query visitor.

[BLamy]

@asiandrummer That is actually exactly what I was looking for.

I just needed to add a value case like these special ones:
https://github.com/graphql/graphiql/blob/master/src/utility/fillLeafs.js#L83-L96