@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
Ahh so it will symbolize keys by default?
no, it’s tmp, I think it should go like this:
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 ^
Yeah that makes sense
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
Thought you meant something different :)
ignore or apply a rule?
Oh wait
I think it should be strict by default
Hmm, it's an interesting one
it is
I guess we could validate the structure of the input too
I definitely do not want to make too many assumptions
yeah me too
Don't know whether that adds any value though
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
Fair enough, makes sense to do that then
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:
ok, I’ll figure something out
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 :)
Cool
@AMHOL there we go ^
Nice, so that's separate for when you want coercion too?
yes
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
Explicitly?
yes
Can't think of any reason not to
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? ^
this would be less trivial to implement though :)
As opposed to:
key(:address).hash? do |address|
address.key(:age).int? & address.key(:age).gt?(18)
end
?
not exactly
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
Ahh OK
so having it outside of the block would make sense
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?
yes
That makes sense :+1:
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
Yep, that works for me
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?
yes
:+1:
@solnic WDYT to removing the message processor from dry-validation?
@AMHOL dunno yet what to do with it tbh
@solnic I'll push what I've got so far, see what you think
@AMHOL sure
dryrb/dry-validation@cbc17e5
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