Directives for the schema definition language about graphql-js HOT 11 CLOSED

This is a great idea and we definitely want to explore this. One issue is that we would want support for multi-line strings and markdown so we would need to think about how to incorporate that

from graphql-js.

@schrockn do you have some ideas how those multiline strings could look like?

The example I posted reuses the directive syntax from GraphQL documents. One option could be to keep that syntax, but let the arguments to be multiline strings (a new construct), e.g.:

type User {
  stories: StoryConnection
  @meta(
    description: "All stories authored by the user."
    examples: """
      Here are some examples written in markdown.

      You can use all the normal arguments.
      ```
      stories(first: $first) { nodes { text } }
      ```
      etc.
      """
    deprecationReason: "You should not use this anymore."
  )
}

Or used with separate directives for all these (argument names make this a bit noisy):

type User {
  stories: StoryConnection
  @description(text: "All stories authored by the user.")
  @examples(text: """
    Here are some examples written in markdown.

    You can use all the normal arguments.
    ```
    stories(first: $first) { nodes { text } }
    ```
    etc.
    """)
  @depracated(
    reason: "You should not use this anymore."
    sinceDate: "2015-08-11"
  )
}

I think the benefit of this approach is that it allows more information to be easily added in the later versions through new directives or new arguments for existing directives. It also borrows the syntax from queries, so there's no new syntax to be learned or implemented besides multiline strings.

from graphql-js.

The annotation syntax is a good idea. I definitely think descriptions should have the simplest possible syntax. We should treat those in a first-class way since they are so pervasive.

Maybe we should investigate doing something similar to literate coffeescript

from graphql-js.

I changed the syntax a bit to move the field directive before the field it applies to. I think this is more readable and also familiar from JS decorators, Java annotations etc.

There is now a pull request that implements directives for fields in type definitions: #180. Please let me know what you think.

from graphql-js.

@schrockn, @leebyron: Ping?

from graphql-js.

Might you consider putting annotations inside multi-line comments?

type User {
    """
    User documentation goes here. Easy to write __Markdown__ here?

    If someone wanted to extend the ability of comments, they could. Maybe a sort of doctest?
    """

    stories: StoriesConnection
    """
    Maybe you could associate this comment with a the stories field. Or should it come before?

    @deprecated: on 11-11-15 for whatever reason.
    """

    other: Int # These comments could stay associated too
}

Just an idea. Obviously inspired by Python.

from graphql-js.

@abuchanan Yeah, also look at @leebyron's suggestion using the existing single-line comments: #180 (comment). I think it could be a nice way to add them without introducing additional syntax.

I experimented a bit with adding annotations inside comments. The only problems were that the parser then needs to be made aware of comments everywhere (at the moment it discards them at the lexing stage), making parsing more complex, and distinguishing description comments from other comments. Parsing should be smart enough to handle cases like this:

# This source code is licensed under the BSD-style license found in the
# LICENSE file in the root directory of this source tree. An additional grant
# of patent rights can be found in the PATENTS file in the same directory.
# (This is not a description for Foo)

type Foo implements Bar {
  # Random note

  # Description for `name`
  name: String
}

Still, I think utilizing comments would probably be the simplest way to add annotations.

from graphql-js.

Even if you want to use annotations instead of comments, please make sure one can read comments from parsed schema. Otherwise information is lost after parse -> print cycle.

from graphql-js.

@fson I just wrote up a related proposal for adding metadata to schemas here: https://github.com/apollostack/graphql-decorators/blob/master/README.md

It needs some more work, but it would be great to get your input. I'm hoping that if we all agree on something, a successful PR can be made.

from graphql-js.

Committed in #382 - thanks for starting this!

from graphql-js.

Awesome, thanks! 👍

from graphql-js.