The props added by your firstQuery component will be available to the component below (inside) it, so you can do something like: export default compose( graphql(firstQuery, { name: ‘firstQuery’ }), graphql(secondQuery, { name: ‘secondQuery’, skip: ({ firstQuery }) => !firstQuery.data, options: ({firstQuery}) => ({ variables: { var1: firstQuery.data.someQuery.someValue } }) }) )(withRouter(TestPage)) Notice that we … Read more
You’ll need to parse the info object that’s passed to the resolver as its fourth parameter. This is the type for the object: type GraphQLResolveInfo = { fieldName: string, fieldNodes: Array<Field>, returnType: GraphQLOutputType, parentType: GraphQLCompositeType, schema: GraphQLSchema, fragments: { [fragmentName: string]: FragmentDefinition }, rootValue: any, operation: OperationDefinition, variableValues: { [variableName: string]: any }, } You … Read more
It’s possible but generally not a good idea because: It breaks the spec. From section 6.3.1: Because the resolution of fields other than top‐level mutation fields must always be side effect‐free and idempotent, the execution order must not affect the result, and hence the server has the freedom to execute the field entries in whatever … Read more
From the spec: Fields may accept arguments to configure their behavior. These inputs are often scalars or enums, but they sometimes need to represent more complex values. A GraphQL Input Object defines a set of input fields; the input fields are either scalars, enums, or other input objects. This allows arguments to accept arbitrarily complex … Read more
GraphQL relies on both the server and the client knowing ahead of time what fields are available available for each type. In some cases, the client can discover those fields (via introspection), but for the server, they always need to be known ahead of time. So to somehow dynamically generate those fields based on the … Read more