Closed semenovDL closed 6 years ago
@semenovDL Looks interesting; why not put the conditional inside the pay
method and remove the need to create an operation to handle just that?
@cored The case above - just simple example. Any of this steps (under cond
/tee
) can be shared as another operation and injected through container.
We can go even further:
cond :ok?, with: 'other_complex_process'
# other steps
def ok?(input)
super(input).success?
end
This is ok, when we don't need pattern matching on other operation, but we just need to check, that it success.
Also, we always could pattern matching on our cond
step:
Order::Pay.new.call(order) do |m|
m.success do
redirect_to order_path(order)
end
m.failure(:can_be_paid?) do
flash[:message] = "Can't be paid"
end
m.failure do |err|
flash[:alert] = err
end
end
@timriley what do you think about it?
@semenovDL sorry for the delay in my response!
Yeah, I think something like this would be nice and it'd be even more useful now that we support local methods as steps.
So I'd love to see a PR for this.
My only other thought was about naming. I wonder if check
is a bit more expressive than cond
?
@timriley check
is fine for me.
Make PR https://github.com/dry-rb/dry-transaction/pull/73
upd. probably guard
will be better alternative for naming?
I find myself in a lot of situations, where I check some conditions in transaction flow. I wrote adapter which send input to Right/Left track based on step result. It feels very native. Maybe we could add it to the core?
Simple usecase: