These are chat archives for dry-rb/chat

11th
Mar 2016
Hannes Nevalainen
@kwando
Mar 11 2016 08:12
where do I find the default error messages for dry-v?
(looking for the file)
Piotr Solnica
@solnic
Mar 11 2016 08:12
@kwando config/errors.yml
Hannes Nevalainen
@kwando
Mar 11 2016 08:13
doh
I was only looking in the lib dir
:facepalm:
btw, there is a missing message for the type?: validation
Piotr Solnica
@solnic
Mar 11 2016 08:34
Right. I'll add it
Piotr Solnica
@solnic
Mar 11 2016 13:11
[√] configuring input processors
[√] rule name translations in messages
[√] setting options with default values for injecting deps
[√] support for :type? in messages
@kwando ^^
Hannes Nevalainen
@kwando
Mar 11 2016 13:12
:clap:
Piotr Solnica
@solnic
Mar 11 2016 13:12
I’m done with dry-v…please keep testing and report any issues/concerns, I’ll be only focusing on bug fixes from now on
now I’m moving to dry-types, I just need to add support for default values in hash schemas…and maybe a couple smaller improvements here and there before releasing it
btw dry-logic was just released, so no need to rely on master
Hannes Nevalainen
@kwando
Mar 11 2016 13:13
woho, I'll try to integrate it with some "real" code on monday =)
Piotr Solnica
@solnic
Mar 11 2016 13:13
updating docs will be a PITA haha
Hannes Nevalainen
@kwando
Mar 11 2016 13:14
yeah, docs is important. and no docs is better than outdated docs
Piotr Solnica
@solnic
Mar 11 2016 13:16
oh noez, another naming dillema
how to name a hash constructor that will fill in missing keys/values?
Hannes Nevalainen
@kwando
Mar 11 2016 13:18
will that "default hash" still error on missing keys that does not have a default value?
Piotr Solnica
@solnic
Mar 11 2016 13:18
depends on schema definition
I want to introduce required and optional APIs for defining keys
Hannes Nevalainen
@kwando
Mar 11 2016 13:20
I think a "strict hash with optional defaults" would be nice to have, would dry up some of my ROM-command inputs
Piotr Solnica
@solnic
Mar 11 2016 13:21
I guess we could start with a hash that will set defaults regardless of the presence of keys
so nil and missing key would be treated the same
in dry-v you’d get a validation error anyway if a key is missing
Hannes Nevalainen
@kwando
Mar 11 2016 13:26
input(Input::Defaults { {created_at: Time.now, ref_entity: 'incident', private: false} } >> Dry::Data['hash'].strict(
        body:          'strict.string',
        ref_entity_id: 'coercible.int',
        ref_entity:    'strict.string',
        created_at:    'strict.time',
        from_id:       'strict.int',
        sender:        'strict.string',
        private:       'strict.bool'
    ))
I go my "Input module" which basically is a set of functions
Input::Defaults is returnning a "callable" which just merges its input with the output from the block
Piotr Solnica
@solnic
Mar 11 2016 13:29
ah yeah, you’re gonna benefit from new stuff for sure
Hannes Nevalainen
@kwando
Mar 11 2016 13:31
In a few cases I have a "key renaming"-step also
Piotr Solnica
@solnic
Mar 11 2016 13:54
it’s better when a command receives attributes that don’t need any mappings
Michał Pietrus
@blelump
Mar 11 2016 13:59
Hi @solnic , may I take a while?
Piotr Solnica
@solnic
Mar 11 2016 14:05
@blelump what’s up?
Michał Pietrus
@blelump
Mar 11 2016 14:14
I'd like to return to the rule chains, consider this gist:
https://gist.github.com/blelump/6ef879b3a7bae47287a5
the chain_example.rb is a part of reform, but unveils the problem. I mean, that execution of rule x depends on rule y. On the other hand, the dry.rbone is your proposal, but it doesn't work as expected
any idea how to deal with it with current dry-v DSL ?
Piotr Solnica
@solnic
Mar 11 2016 14:16
I’ll check it out, thanks
I’m not sure if I understand this
you want to check username when email is set to true?
Michał Pietrus
@blelump
Mar 11 2016 14:18
sure, I can explain :-)
yep, that's an abstract use case
Piotr Solnica
@solnic
Mar 11 2016 14:19
and check password only if email’s value == ‘john@trb.org’?
Michał Pietrus
@blelump
Mar 11 2016 14:19
yup, let's I'd like do that
the goal is to make execution of dependent rules conditional. I mean if rule x is false, then rule y does not fire
Piotr Solnica
@solnic
Mar 11 2016 14:20
yeah you can express that
Michał Pietrus
@blelump
Mar 11 2016 14:21
and rule y depends on x
Piotr Solnica
@solnic
Mar 11 2016 14:21
in fact, I don’t like how it would work with these validation blocks, because you don’t have valid schema structure defined in a single place
Michał Pietrus
@blelump
Mar 11 2016 14:21
yep, I sort of agree with that
Piotr Solnica
@solnic
Mar 11 2016 14:21
which means you’re not gonna be able to benefit from input processors
so ie in form coercion won’t be possible
you can do sth like that:
key(:username).maybe

key(:email).required(:bool?)

key(:password).maybe

rule(username: [:email, :username]) do |email, username|
  email.true?.then(username.filled?)
end

rule(password: [:email, :password]) do |email, password|
  email.eql?(‘john@trb.org’).then(password.valid?)
end
Michał Pietrus
@blelump
Mar 11 2016 14:25
uhm
Piotr Solnica
@solnic
Mar 11 2016 14:25
first step is to define how a valid schema should look like, then think about additional rules that must be applied
Michał Pietrus
@blelump
Mar 11 2016 14:27
OK, lets consider rule :password. if email is not john@trb.org then it doesnt check password.valid? and the result is false
and so, it adds appropriate errror msg, right?
Piotr Solnica
@solnic
Mar 11 2016 14:29
no, result is true, because it’s an implication
if it’s john@trb.org and password is not valid, then you’ll get an error msg
if it’s not jogn@trb.org then it won’t execute valid? for password and you won’t get an error msg
Piotr Solnica
@solnic
Mar 11 2016 14:41
I actually just checked this schema, works correctly
Michał Pietrus
@blelump
Mar 11 2016 14:45
I'm actually expecting weird behaviour of maybe:
schema = Dry::Validation.Schema do
  key(:password).maybe
end

p schema.({}).messages
 # => {:password=>["is missing"]}
Piotr Solnica
@solnic
Mar 11 2016 14:45
maybeis for values not keys
do optional(:password).maybe
it’s something to learn and remember when using dry-v, it makes a distinction between missing keys and values
Michał Pietrus
@blelump
Mar 11 2016 14:47
looking into spec and haven't noticed it..., thanks!
Piotr Solnica
@solnic
Mar 11 2016 14:52
I’ll make sure to highlight this fact in docs
Michał Pietrus
@blelump
Mar 11 2016 14:57
got into another issue...
consider this:
form = Dry::Validation.Form do
  key(:password).required
  rule(password: [:email, :password]) do |email, password|
    password.valid?
  end

  configure do
    def valid?(pass)
      false
    end
  end
end
p form.('email' => 'john@trb.org', 'password' => '123').messages
and the result is it's valid
whereas I'd expect the opposite
Piotr Solnica
@solnic
Mar 11 2016 15:06
you didn’t specify key(:email).required
full schema spec is a prerequisite for high-lvl rules
Michał Pietrus
@blelump
Mar 11 2016 15:10
I see, everything plays smoothly :-)
Piotr Solnica
@solnic
Mar 11 2016 15:11
great :)
Piotr Solnica
@solnic
Mar 11 2016 15:46
@kwando in dry-types master, default values are now set in hash constructors