Could you try that one?
Dry::Struct::Error: [User.new] :name is missing in Hash input
Does it helps you? @idlefingers
so instead of
User.new.foo # => {:meta=>{:omittable=>true}} I'm trying to get User.new.foo # => {} (which is what constructor_type :schema did before)
class User < Dry::Struct
transform_types do |type|
type.optional.deafult({})
end
attribute :foo, Types::Hash
endclass User < Dry::Struct
transform_types do |type|
if type.default?
type
else
type.meta(omittable: true)
end
end
attribute :foo, Types::Hash.default({})
attribute :bar, Types::String
end
User.new
=> #<User foo={} bar=nil>
@idlefingers don't forget, you can create a base class if you don't want to call
transform_types many times
since it's an api wrapper I'm building, it's very hard to be sure all expected attributes are in responses, so I needed to make it a little less strict (
constructor_type :schema style :P )
however, you can override the constructor
Hello, I have a question about dry-validation. I want to be able to validate an array and that the elements within the array are integers. I also would like to be able to accept an empty array. Currently I have something something that looks like this
optional(:group_ids, [:int]).value(:array?) but am having trouble figuring out how the element validation would work. Any advice?
Hi guys :) I am learning (and trying to implement) dry-transaction, I am going thru the Introduction and found this:Each operation shouldn’t accumulate state, instead it should receive an input and return an output without causing any side-effects.
What do you mean by that? Especially this part without causing any side-effects?
I understand that I should not keep some state across operations on the "transaction class" level, but isn't "causing side-effect" a natural outcome of an operation?
Thanks in advance for clarifying
Dry-transaction's naming is a bit weird to me but think of it like a process instead of a database transaction. The idea is you create a transaction object that has all the steps needed to handle a process. Then you reuse that transaction object again and again and the only difference is what input you've given it.
So each step would be a pure function that doesn't hold state and acts on the input and returning everything needed in the output
module ApiTokens
class Create
include Dry::Transaction
step :validate
step :persist
step :regenerate_token
def validate(input)
validation = ApiTokenSchema.call(input)
validation.success? ? Success(input) : Failure(validation.errors)
end
def persist(input)
api_token = ApiToken.new(input)
api_token.save ? Success(api_token) : Failure(api_token.errors)
end
def regenerate_token(api_token)
api_token.regenerate_token!
Success(api_token)
end
end
end
This is my testing class ^^ Should be as you described
The only side-effect is the DB one