GraphQLObjectTypeConfig<TSource> to GraphQLFieldResolveFn<TSource, TResult>

[iamchenxin]

GraphQLObjectTypeConfig<TSource> to GraphQLFieldResolveFn<TSource, TResult>
Make user can do a whole top-bottom Flow check between their resolvers.
With the Flow typed feature, user can ensure his data structure is correspond to schema . ex: starWarsData.js L103

More details see the src/tests/starWarsSchema.js

A simple demonstration:

  type DCPost;
  type DComment;
  type DUser;
  const Post = new GraphQLObjectType({
    name: 'Post',
    fields: () => ({
      ...
      comment: {
        type: new GraphQLList(Comment),
        resolve: (src:DPost):DComment[] => { // Flow check DPost -> DComment[]
          return ...;
        } }
    }),
  });

  const Comment = new GraphQLObjectType({
    name: 'Comment',
    fields: () => ({
      ...
      user: {
        type: User,
        resolve: (src:DComment):DUser => { // DComment -> DUser
          return ...;
        }
      },
    }),
  });

  const User = new GraphQLObjectType({
      ...
  });

Note: Because in v0.61 ,in source code use a any type to force cast TSource. So it is user's responsibility to check the Data Type is not typo. In above code , if resolve: (src:DPost):DComment[] is typo to resolve: (src:DPost):DSomeAnotherType[](and user return a wrong data), Flow will still pass. Flow will not check DSomeAnotherType is DComment,cause of DSomeAnotherType -> any -> DComment

[leebyron]

could you remove this to keep this PR single-purpose?

[leebyron]

Thanks for your hard work on this! I've left some comments inline, but please reduce the scope of this to only the changes necessary for this change - otherwise it's difficult to follow what was necessary and what was not

[iamchenxin]

to fix Flow error: non-string literal property keys not supported, like:

const droidData = {
  2000: threepio,
  2001: artoo,
};

[leebyron]

Ah, thanks for the explanation!

I think you actually want {numbers: true} rather than keywords to handle this case.

I just landed a change which applies this across the whole project so that we would not need this special case, so now it can be removed here

[iamchenxin]

Its cool, will remove them.

[iamchenxin]

Amended code style.
Separate .gitignore to #437 .

[leebyron]

are these resolve function type hints necessary? I would expect that Flow would not require them since you already typed getFriends

[iamchenxin]

Maybe it is necessary, the input and output datatype should be a part of schema's design. A explicit declare give the resolver a constraint.(Makes it clear to other people, what data should be in and what data should be out).Will explain this below.

[leebyron]

stylistic issue: please use spaces inside the { } in import to match the others in the project