-
Notifications
You must be signed in to change notification settings - Fork 18
Description
If you do this:
export interface EmailJobData {
email?: string;
firstName?: string;
lastName?: string;
}
interface Headers {
'template': string;
}
@ZeebeWorker('email:send', {
fetchVariable: ['email', 'firstName', 'lastName'],
})
async emailService(job: Job<EmailJobData, Headers>, complete) {
this.logger.info('Email service');
const template = job.customHeaders.template;
const { email, firstName, lastName } = job.variables;
complete.success();
}
You get intellisense on the job.variables and job.customHeaders.
This disadvantages of this approach are that you need to specify the interface and the fetchVariables independently, and there is no run-time validation, so you have to specify everything as optional (meaning: may not be present), when what you really want to say is either must be present (not optional), or is optional.
What would be really cool is to inject a DTO object to the callback handler (or the ZeebeWorker decorator) and have both fetchVariables and the type of Job inferred from that, as well as some run-time validation.
So it would look something like this:
class JobDTO {
readonly email: string
readonly firstName?: string
readonly: lastName?: string
}
@ZeebeWorker('email:send')
async emailService(@JobDTO() job, complete) {
this.logger.info('Email service');
const template = job.customHeaders.template;
const { email, firstName, lastName } = job.variables;
complete.success();
}
And this would set the fetchVariables on the worker and set the type on the job parameter.
Not sure if you can reach back up from the handler to the Worker decorator, or if it would need to be the other way, or if it would need to be done twice - once in each place.
I'm not sure how you deal with the customHeaders / variables part of it either... The incoming job object has two sub-fields that have variable shapes. In the zeebe-node library this is handled by taking two type parameters.