Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
@AMHOL ^^ :tada:
now I’m wondering how to add that to the schema, should be configurable I believe
we can’t assume you always want a built-in input handler
I started writing but now I’m having doubts lol
here’s the issue
we should cater for the fact we may have unexpected keys
it should be possible to have a rule for that too
but we also want to symbolize keys, because you create rules against symbolized names
we also cannot assume we always have stringified keys :)
@AMHOL ^
What do you mean by
cater for the fact we may have unexpected keys?
I think first rule should be created for you, and it goes like this: for all key rules, create a rule that those keys are the only ones we accept
well, schema should define the whole structure
Oh, yeah, think it should defo ignore keys outside of the validation schema
so if you receive
{ foo: ‘bar’, email: ‘jane@doe’ } while not having foo specified it should be a validation error
yeah me too
it does, there are cases where you really do want to validate the structure, not just values
ie in my current project at work it is the requirement
ie
{} is not the same as { email: nil } even though {}[:email] happily returns nil
but that’s just our wonderful ruby world :joy:
I guess if you validate, then send the data straight to the database, writing key-value pairs, it would make sense to validate the structure
Yeah :joy:
the data type we build is a hash with explicit schema (from dry-data)
it ignores unknown keys and handles only the ones you specified
so it’s gonna coerce what is needed
then it’s on the validation side to do what’s appropriate :)
@AMHOL there we go ^
it still blindly symbolizes all keys, gotta work on that part now
maybe it’s not a bad idea to add key coercion to dry-data hash
heh adding support for passing a block to predicates in the dsl was too easy, it’s a very good sign #happypanda
to make the dsl more concise I’m considering this now:
key(:address).hash? do |address|
address.key(:age).int? { |value| value.gt?(18) }
end
@AMHOL WDYT? ^
As opposed to:
key(:address).hash? do |address|
address.key(:age).int? & address.key(:age).gt?(18)
end
?
type check is kind-of special
first of all you specify the expection for the type so we can infer coercion logic from it
secondly it’s the very first check that needs to be done before we can do anything else with the value
I dunno, will see, not gonna do that now, just wondering
So the predicate would be a pre-requisite to the validations running inside of the block?
I just added support for passing blocks to predicate checks, which does the very same thing, but for type-check you get one more level of nesting
hence my thought about moving it to the outer block
you can do
value.int? & value.gt?(18) and the equivalent of this is using a block like this; value.int? { value.gt?(18) }
in general a block ==
AND
So it's like a normal
AND where the right only evaluates if the left passes?
@solnic WDYT to removing the message processor from dry-validation?
So the idea is that we can have a dry-validation-i18n gem for error messages
BTW, now I've got to grips with it a lot more, you've done a fantastic job so far