This version of graphql-js introduces a breaking change to the method signature of the resolve() method.
Previously, resolve() had this method signature:
type GraphQLResolveInfo = {
fieldName: string,
fieldASTs: Array<Field>,
returnType: GraphQLOutputType,
parentType: GraphQLCompositeType,
schema: GraphQLSchema,
fragments: { [fragmentName: string]: FragmentDefinition },
rootValue: mixed,
operation: OperationDefinition,
variableValues: { [variableName: string]: mixed },
};
resolve(
source: mixed,
args: {[argName: string]: mixed},
info: GraphQLResolveInfo
): mixedTypically, when you wanted to thread request or other context-specific information down to the resolve functions, you might have included it in rootValue when calling graphql():
// Pre 0.6.0
graphql(req => {
return {
rootValue: {viewer: req.userID},
schema,
};
});Now there exists a bonafide context property that you can set for exactly this purpose:
// New in 0.6.0
graphql(req => {
return {
context: {viewer: req.userID}, // NEW
schema,
};
});graphql-js 0.6.0 will make this context prop available to each one of your resolve() methods as the third argument:
resolve(
source: mixed,
args: {[argName: string]: mixed},
context: mixed, // NEW
info: GraphQLResolveInfo // MOVED
): mixedNote that the info argument has moved to the fourth position. Anyone previously making use of the info argument will have to update the method signatures of their resolve() methods.
Now that there's this
contextproperty, what are the different intended use cases forcontextandrootValue? Why wasn't the user info sufficient being inrootValueand now that it is calledcontextfixes? I guess I'm more curious whatrootValueis intended for that should not go incontext?