Export executeOperation method on /execution/execute

[estrada9166]

Feature requests

Is possible to export executeOperation? I'm working on a package to test/mock some queries/mutations/subscriptions and that'll be really useful because that way the operation can be executed against the mock.

If it's possible I can create the PR

[IvanGoncharov]

@estrada9166 Can you please describe your use case in more details?

[estrada9166]

@IvanGoncharov Sure thing! I'm working on easygraphql-tester and after some refactor and going throw the source code of graphql-js I can do something like this:

const exeContext = buildExecutionContext(
    schema, 
    doc, 
    undefined,
    undefined,
    variableValues,
    undefined,
    undefined,
    undefined,)

  const result = executeOperation(exeContext, exeContext.operation, mock[operation])

instead of doing all this

That way I can get the query from the mocked schema that I previously created with easygraphql-mock

This package will be used to test the operations on the front-end and backend as well + you can mock you operations

[IvanGoncharov]

@estrada9166 Note: only things exported from root index.js or from <folder>/index.js are part of public API all other functions including buildExecutionContext are subject to breaking changes even at patch releases, e.g. 14.1.2.

Can you use fieldResolver & typeResolver resolvers instead? #1332 (comment)

[IvanGoncharov]

@estrada9166 Also why you can't you use execute which is part of public API?

const operationNode = getOperationAST(document, optionalOperationName);
const result = execute({
  schema,
  document,
  variableValues,
  rootValue: mock[operationNode.operation]
});

[estrada9166]

@IvanGoncharov much better!! thank you so much!

[IvanGoncharov]

@estrada9166 Always happy to help. Just as a clarification for other devs having the same issue and finding this thread, what was your solution in the end?

[estrada9166]

@IvanGoncharov sure thing, I do this + set a fixture if it exists but basically, it was:

  if (!isObject(doc)) {
    doc = parse(doc)
  }

  const operationNode = getOperationAST(doc)

  // This is a method on the project
  const operation = schemaDefinition(parsedSchema, operationNode.operation)

  const rootValue = mock[operation]

  const result = execute({
    schema,
    document: doc,
    variableValues,
    rootValue,
    typeResolver: defaultTypeResolver
  })

Here is the complete file with the solution and here is the PR with all the refactor done and

Also, can you help me with something that might be blocking to merge that PR... I'm trying to set some custom directives to be ignored, those directives are the ones of Relay I tried extending those directives to the schema and also building the schema and set those directives (this partially works but if the directive is defined on the schema it'll fail, also I can't have values inside the directive...) can you give me a hint about how can I solve this!

Thanks! :)

[IvanGoncharov]

Also, can you help me with something that might be blocking to merge that PR... I'm trying to set some custom directives to be ignored, those directives are the ones of Relay I tried extending those directives to the schema and also building the schema and set those directives (this partially works but if the directive is defined on the schema it'll fail, also I can't have values inside the directive...) can you give me a hint about how can I solve this!

@estrada9166 Not sure that I fully understand but if you just want to add directives to the schema you can always do:

let schema = buildSchema(userProvidedSDL);
schema = extendSchema(schema, parse(`
  directive @customDirective(arg: String) on FIELD
`))

If this doesn't address your issue can please provide an example of user SDL, user query and expected output.

[estrada9166]

@IvanGoncharov is there a way to ignore the arguments on the directive? I mean those arguments can change.

for example @argumentDefinitions

@argumentDefinitions is a directive used to specify arguments taken by a fragment.

or there's a way to ignore any extra directive different from the ones that are permitted on GraphQL?

[IvanGoncharov]

As a workaround you can disable this rule:
https://github.com/graphql/graphql-js/blob/master/src/validation/rules/KnownArgumentNames.js

or there's a way to ignore any extra directive different from the ones that are permitted on GraphQL?

No, since spec states that all directive should define arguments.

[artola]

@IvanGoncharov @estrada9166 Thanks a lot.

@michaelstaib to follow up.

[michaelstaib]

@IvanGoncharov just one question here:

No, since spec states that all directive should define arguments.

The spec marks the arguments as optional ... it is valid to have directives without arguments if the directive does not define any arguments.