Pass `operation` type to @populatedBy directive as fourth argument

[andreloeffelmann]

Is your feature request related to a problem? Please describe.
Within the callback code of a @populatedBy directive I need to know wether the code is evaluated in context of a CREATE or UDPATE mutation. Depending on that, I need to return different values.

Describe the solution you'd like
It would be great to have the operation type passed to the callback function as a fourth argument. Either as plain string or as enum, I don't care about that. Since the callback is called from within translate-create.js resp. translate-update.js it should be easy to pass the operation type to the call of callbackBucket.resolveCallbacks() and then to await callbackFunction(cb.parent, {}, this.context, OPERATION_TYPE)

Describe alternatives you've considered
I have tried to use the @populatedBy directive twice on a field with different callback function names and different operation types each, one for CREATE and one for UPDATE - but this fails since the schema validator allows this directive only once per field.

[angrykoala]

Hi, this makes sense. As you say this should be fairly easy to implement, although we need to make sure it doesn't have any breaking behavior or ill side effects.

In the meantime, I've been playing around and there may be a workaround using @alias directive:

type User {
  username1: String @alias(property: "username") @populatedBy(callback: "createCB", operations: [CREATE])
  username2: String @alias(property: "username") @populatedBy(callback: "updateCB", operations: [UPDATE])
}

This effectively allows to use populatedBy with the 2 different fields, which in the DB are mapped to the same property

One downside of this is that the extra fields are now available in the mutation and read operations, but this can be sorted with the settable and selectable directive:

username: String
    @alias(property: "username")
    @populatedBy(callback: "createCB", operations: [CREATE])
    @settable(onUpdate: false)
username2: String
    @alias(property: "username")
    @populatedBy(callback: "updateCB", operations: [UPDATE])
    @settable(onCreate: false)

This feature request is still valid, as this approach is very much a workaround, but the effective behavior should be the same

[angrykoala]

Implementation detail: The arguments of populatedBy are intended to be compatible with resolvers, so any extra argument should not conflict with these if we want to keep this compatibility.

There are alternatives to consider such as using the context object