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
The current implementation of tap decorator had issues.
First issue: it was not really fit to purpose, especially when trying to use asyncrhonous functions as input (it did not work and when there was timeouts or rejected promises involved, literally it could crash or cause bad behaviour).
Second issue: Its definition when implemented was not consistent with the canonical definition of tap (which never parallelizes and it works as a way to eenable side effects to the main flow of the pipeliines)
Third issue: it was not multi parameter, now it can support as a pipeline various step functions
Basically the reason of this issue and the related pr is to enable a pattern that we have been using that involves asynchronous validations.
Currently we have to use a pattern using pairwise that is cumbersome, the option to use tap would simplify the code, because instead of using something like this:
You can see that using pairwise here is cumbersome because we have to add an artificial step only to map the object that comes in an array from pairwise, that is only used to not lose the reference to the original object in the previous step (Which is not the original target use case for pairwise decorator).
tap either returns the first object received by the first step, or an exception if it has been thrown inside any step function inside the decorator tap.
if you want to know details about tap definition you can check here or here.
The text was updated successfully, but these errors were encountered:
The current implementation of tap decorator had issues.
First issue: it was not really fit to purpose, especially when trying to use asyncrhonous functions as input (it did not work and when there was timeouts or rejected promises involved, literally it could crash or cause bad behaviour).
Second issue: Its definition when implemented was not consistent with the canonical definition of tap (which never parallelizes and it works as a way to eenable side effects to the main flow of the pipeliines)
Third issue: it was not multi parameter, now it can support as a pipeline various step functions
Basically the reason of this issue and the related pr is to enable a pattern that we have been using that involves asynchronous validations.
Currently we have to use a pattern using pairwise that is cumbersome, the option to use tap would simplify the code, because instead of using something like this:
You can see that using pairwise here is cumbersome because we have to add an artificial step only to map the object that comes in an array from pairwise, that is only used to not lose the reference to the original object in the previous step (Which is not the original target use case for pairwise decorator).
instead, with tap we should be able to do this:
tap either returns the first object received by the first step, or an exception if it has been thrown inside any step function inside the decorator tap.
if you want to know details about tap definition you can check here or here.
The text was updated successfully, but these errors were encountered: