GraphQL Server for Visma Business

@export and @dependsOn

Use values from one operation in the next, in the same request.

directive @export(as: String, distinct: Boolean) on FIELD
directive @dependsOn(field: String) on FIELD

@export writes a field’s resolved value into a query variable so a later field can read it with $name. The variable must be declared on the operation, normally with a default, because it has no value until the export runs.

Works in mutations

mutation ($orderId: Int = 0) {
  order_create(order: { orderType: NORMAL_ORDER, customerNo: 10002 }) {
    orderNo @export(as: "orderId")
  }
  orderLine_create(orderLine: { orderNo: $orderId, productNo: "1001", quantity: 2 }) {
    orderNo
    lineNo
  }
}

Verified against F0001: the line is written to the order that order_create just made. The variable is read from inside an input object, which is the case that needs the most work internally, and it is handled.

Does not work in queries — and says so

GraphQL only guarantees execution order between the root fields of a mutation. HotChocolate executes a query breadth-first: every field in a selection set resolves before the engine descends a level. So in

query ($customerId: Int = 0) {
  associate(...) { nodes { customerNo @export(as: "customerId") } }
  order(where: { customerNo: { eq: $customerId } }) { nodes { orderNo } }
}

order’s resolver runs in the same level as associate’s, before the nested customerNo leaf that exports has resolved. The export can never arrive in time.

Rather than let order run with the variable’s default and quietly return the wrong rows, it waits and then fails:

'order' reads $customerId, which @export never produced. The exporting field may have
returned no rows, or it may run after this one - a field can only read a variable
exported by a field that runs before it. The variable's default was not used.

extensions.code is EXPORT_NOT_AVAILABLE. Same error if the exporting field returns no rows. This is the one behaviour worth keeping in mind: a query that exports is an error, not a silent wrong answer.

Multiple values

Exporting the same name more than once appends, so declaring the variable as a list type collects every value. distinct: true drops duplicates.

@dependsOn

Holds a field back until a named sibling has resolved, for ordering not expressed through a variable. It is rarely needed - a field that reads an exported variable already waits for the export automatically - and it is subject to the same breadth-first limitation.