my initializer looks like
def initialize(params, options)
@options = options #this is the dependency hash
end
so i kinda want to avoid the overriding from Ai
because we don't need separate instance variables per dependency, i store them all in one hash
@yuriidanyliak what does
Schema#output do?
@apotonick, usually using like
validation = schema.call(params)
validation.success? ? validation.output : validation.messages
@yuriidanyliak ok, but what's the meaning of "output" in this specific case?
so basically
form.sync
starting to try to replace my Virtus addiction by dry-types 😜
I have a domain object that maps a remote API resource object ... and for example some of the attributes are DateTime instances
& for example, the responsability of coercion for DateTime values should be done outside of the object itself?
it won't coerce anything and will just put a string on the object state
User.new(schema.call(some_data_from_api)) <= just this
of course validation can fail so you may want to handle this however you want
but that forces the schema to be defined twice somehow, right?
on the struct, and on the schema definition
and the schema definition contains validation logic, also
and how will a DateTime coercion/parsing will be done on a Schema object :/
I’d do something like this:
UserSchema = Dry::Validation.JSON do
required(:created_at).value(:date_time?)
end
class User < Dry::Struct
attribute :created_at, Types::Strict::DateTime
end
user_attrs = UserSchema.(user_data)
User.new(user_attrs)
in 1.0.0 dry-validation will support infering schemas from struct definitions, for now you need to have it defined explicitly in both places
this is the service object where I'm trying to inject that Schema logic you're talking about
so that you understand the context a little better
anyhow, yes it will enforce coercions
let's say ... users that never logged in, the last_sign_in_at datetime doesn't exist