You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
If you do this:
You get intellisense on the
job.variables
andjob.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:
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.
The text was updated successfully, but these errors were encountered: