These are chat archives for dry-rb/chat

27th
Nov 2015
@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
Andy Holland
@AMHOL
Nov 27 2015 11:16
Ahh so it will symbolize keys by default?
Piotr Solnica
@solnic
Nov 27 2015 11:17
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 ^
Andy Holland
@AMHOL
Nov 27 2015 11:20
Yeah that makes sense
What do you mean by cater for the fact we may have unexpected keys?
Piotr Solnica
@solnic
Nov 27 2015 11:21
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
Andy Holland
@AMHOL
Nov 27 2015 11:22
Oh, yeah, think it should defo ignore keys outside of the validation schema
Piotr Solnica
@solnic
Nov 27 2015 11:22
so if you receive { foo: ‘bar’, email: ‘jane@doe’ } while not having foo specified it should be a validation error
Andy Holland
@AMHOL
Nov 27 2015 11:22
Thought you meant something different :)
Piotr Solnica
@solnic
Nov 27 2015 11:22
ignore or apply a rule?
Andy Holland
@AMHOL
Nov 27 2015 11:22
Oh wait
Piotr Solnica
@solnic
Nov 27 2015 11:22
I think it should be strict by default
Andy Holland
@AMHOL
Nov 27 2015 11:23
Hmm, it's an interesting one
Piotr Solnica
@solnic
Nov 27 2015 11:23
it is
Andy Holland
@AMHOL
Nov 27 2015 11:23
I guess we could validate the structure of the input too
Piotr Solnica
@solnic
Nov 27 2015 11:23
I definitely do not want to make too many assumptions
yeah me too
Andy Holland
@AMHOL
Nov 27 2015 11:23
Don't know whether that adds any value though
Piotr Solnica
@solnic
Nov 27 2015 11:23
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
Andy Holland
@AMHOL
Nov 27 2015 11:24
Fair enough, makes sense to do that then
Piotr Solnica
@solnic
Nov 27 2015 11:24
ie {} is not the same as { email: nil } even though {}[:email] happily returns nil
but that’s just our wonderful ruby world :joy:
Andy Holland
@AMHOL
Nov 27 2015 11:25
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:
Piotr Solnica
@solnic
Nov 27 2015 11:26
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 :)
Andy Holland
@AMHOL
Nov 27 2015 12:10
Cool
@AMHOL there we go ^
Andy Holland
@AMHOL
Nov 27 2015 12:56
Nice, so that's separate for when you want coercion too?
Piotr Solnica
@solnic
Nov 27 2015 12:59
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
Andy Holland
@AMHOL
Nov 27 2015 13:21
Explicitly?
Piotr Solnica
@solnic
Nov 27 2015 13:22
yes
Andy Holland
@AMHOL
Nov 27 2015 13:23
Can't think of any reason not to
Piotr Solnica
@solnic
Nov 27 2015 13:41
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? ^
Piotr Solnica
@solnic
Nov 27 2015 13:46
this would be less trivial to implement though :)
Andy Holland
@AMHOL
Nov 27 2015 13:50
As opposed to:
key(:address).hash? do |address|
  address.key(:age).int? & address.key(:age).gt?(18)
end
?
Piotr Solnica
@solnic
Nov 27 2015 13:51
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
Andy Holland
@AMHOL
Nov 27 2015 13:52
Ahh OK
Piotr Solnica
@solnic
Nov 27 2015 13:52
so having it outside of the block would make sense
I dunno, will see, not gonna do that now, just wondering
Andy Holland
@AMHOL
Nov 27 2015 13:53
So the predicate would be a pre-requisite to the validations running inside of the block?
Piotr Solnica
@solnic
Nov 27 2015 13:53
yes
Andy Holland
@AMHOL
Nov 27 2015 13:53
That makes sense :+1:
Piotr Solnica
@solnic
Nov 27 2015 13:53
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
Andy Holland
@AMHOL
Nov 27 2015 13:54
Yep, that works for me
Piotr Solnica
@solnic
Nov 27 2015 13:54
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
Andy Holland
@AMHOL
Nov 27 2015 14:03
So it's like a normal AND where the right only evaluates if the left passes?
Piotr Solnica
@solnic
Nov 27 2015 14:03
yes
Andy Holland
@AMHOL
Nov 27 2015 14:04
:+1:
Andy Holland
@AMHOL
Nov 27 2015 23:16
@solnic WDYT to removing the message processor from dry-validation?
Piotr Solnica
@solnic
Nov 27 2015 23:57
@AMHOL dunno yet what to do with it tbh
Andy Holland
@AMHOL
Nov 27 2015 23:57
@solnic I'll push what I've got so far, see what you think
Piotr Solnica
@solnic
Nov 27 2015 23:58
@AMHOL sure
Andy Holland
@AMHOL
Nov 27 2015 23:59
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