Is it still possible to inject a operation, even if i’m using inside other operation:
i.e:
class CheckAccess
include Dry::Transaction::Operation
def call(user)
return Success(user.licenses.first) if active_license_for?(user)
check_purchase = CheckPurchase.new
check_purchase.call(user.purchases.first) do |result|
result.success do |purchase|
Success(purchase)
end
result.failure do
if user.on_trial?
Success(Trial.new(user: user))
else
Failure(user)
end
end
end
end
private
def active_license_for?(user)
user.licenses.first_or_initialize.active?
end
end
I prefer not using that block syntax at all. It’s a kind of dry-matcher Class enhancement.
I think it’s just a sugar-syntax that’s hard to write tests.
Just use normal Result matcher.
Or better, with the nature of your code, use Do notation
I think it’s just a sugar-syntax that’s hard to write tests.
Just use normal Result matcher.
Or better, with the nature of your code, use Do notation
check_purchase.call(user.purchases.first).or {
if user.on_trial?
Success(Trial.new(user: user))
else
Failure(user)
end
}
if you want it to be an injected dependency, you need to pass it to initialize
e.g.
def initialize(check_purchase:)
@check_purchase = check_purchase
end
Then you can use it from inside
#call and also inject a test double during your tests
@pablocrivella https://www.rubypigeon.com/posts/dependency_injection_containers_vs_hardcoded_constants/ may be a helpful read for you
For now i went for the “hybrid” approach:
# frozen_string_literal: true
require "dry/transaction/operation"
class CheckAccess
include Dry::Transaction::Operation
def initialize(check_purchase: CheckPurchase.new)
@check_purchase = check_purchase
end
def call(user)
return Success(user.licenses.first) if active_license_for?(user)
@check_purchase.call(user.purchases.first).or(
if user.on_trial?
Success(Trial.new(user: user))
else
Failure(user)
end
)
end
private
def active_license_for?(user)
user.licenses.first_or_initialize.active?
end
end
@pablocrivella I take a similar approach, plus you can always use the following gem: https://github.com/dry-rb/dry-initializer for your initializer
flattening by default will ruin the semantics
it won't "type check"
Thanks!
The question above was because we tried to combine Try and Result monads, but we found a solution:
irb(main):003:0> Try { Failure(5) }.to_result.bind(&:itself)
=> Failure(5)
irb(main):004:0> Try { raise RuntimeError.new }.to_result.bind(&:itself)
=> Failure(#<RuntimeError: RuntimeError>)
irb(main):005:0> Try { Success(1) }.to_result.bind(&:itself)
=> Success(1)
can you explain this project please?
@hasimisikli that might get you started
Working with a legacy app where a lot of logic is based on a nested hash. I'm convinced some keys have become obsolete and some keys contain typos, so I'm trying to work backwards to a schema where every entry of the hash adheres to, that gives a starting point to see what keys exactly exist. So I want the validation to error if extra keys are given.
I could also use dry-struct for it, but I'm not interested in the resulting struct (yet), and dry-validation gives more readable errors
because Types::Params::Bool already converts everything to true or false