These are chat archives for dry-rb/chat

6th
May 2016
kaushik vinay TG
@kaushikvinaytg
May 06 2016 01:02
@AMHOL that was exactly what i was looking for, thank you.
Andy Holland
@AMHOL
May 06 2016 01:40
NP
Aditya Tiwari
@aditya01933
May 06 2016 07:14
This message was deleted
This message was deleted
Luca Guidi
@jodosha
May 06 2016 08:55

Hi all, I've got a couple of questions about dry-v forms whitelisting.

First of all:

form = Dry::Validation.Form { required(:id) }
puts form.call('id' => '23').output # => {}

I have to use required(:id).maybe to get the output that I'm looking for: {id: '23'}

Is that intended, or it's an issue? It isn't intuitive for me :(
Luca Guidi
@jodosha
May 06 2016 09:04

Second issue - output is unpredictable :(

form = Dry::Validation.Form { required(:id).maybe }
puts form.call('id' => '23', 'foo' => '1').output # => {:id=>"23"} # SUCCESS
puts form.call('id' => 23, 'foo' => 1).output     # => {"id"=>23, "foo"=>1} # FAILURE - keys are strings, it didn't filtered "foo"
puts form.call(id: 23, foo: 1).output             # => {:id=>23, :foo=>1} # FAILURE - it didn't filtered "foo"

I understand that Form was designed to deal exclusively with strings, but it may happen that a Rack middleware returns an integer value, instead of a string. Or a developer wants to pass IDs as integers in unit tests.

Do you think this should be addressed?

Andy Holland
@AMHOL
May 06 2016 10:17
@jodosha in form both keys and values should be strings, this problem has come up a lot but I know Solnic has mentioned in the past that it expects string keys and values, it does seem to be the source of a lot of confusion tho
Luca Guidi
@jodosha
May 06 2016 10:19
@AMHOL Thanks. Well, I'm integrating dry-v forms with hanami actions. For unit tests we allow syntax like this: action.call(id: 23), hence my questions. ;)
@AMHOL So, I need to force strings everywhere before to hit dry-v, or is that something that will change in the future?
Nikita Shilnikov
@flash-gordon
May 06 2016 10:20
@jodosha probably dry-v could generate robust error messages about type mismatch
Luca Guidi
@jodosha
May 06 2016 10:21
@flash-gordon So, better to convert to strings ;)
Nikita Shilnikov
@flash-gordon
May 06 2016 10:21
yep
Luca Guidi
@jodosha
May 06 2016 10:21
@AMHOL @flash-gordon Thanks for this clarification! :green_heart:
Andy Holland
@AMHOL
May 06 2016 10:35
@jodosha it's certainly something to discuss with Solnic when he's back from his break
Luca Guidi
@jodosha
May 06 2016 10:38
@AMHOL I'm gonna open a ticket to keep track of this issue. Thanks!
Andy Holland
@AMHOL
May 06 2016 10:39
Cool, thank you too :+1:
Andy Holland
@AMHOL
May 06 2016 11:50
:anger: Why do people use rescue without specifying exceptions to rescue from
kaushik vinay TG
@kaushikvinaytg
May 06 2016 19:30
Not sure if im doing something wrong here
BudgetSchema = Dry::Validation.Schema do

    key(:total_budget).maybe(:int?)
    key(:daily_budget).maybe(:int?)
    rule(total_or_daily: [:total_budget, :daily_budget]) do |total_budget, daily_budget|
      total_budget.filled? ^ daily_budget.filled?
    end

end

BudgetSchema.call({total_budget: 100, daily_budget: 10})

# /.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/dry-validation-0.7.4/lib/dry/validation/error_compiler.rb:30:in `visit': undefined method `visit_xor' for #<Dry::Validation::ErrorCompiler::Input:0x007faee927aa98> (NoMethodError)
# Did you mean?  visit
#                visit_error
#                visit_attr
#                visit_el
#                visit_result
#                visit_val
#                visit_set
#                visit_key
Im trying to validate if any one must be filled, but seem to get this error
Tanner Donovan
@ttdonovan
May 06 2016 19:42
@kaushikvinaytg maybe that's a bug not sure what if you tried something like this for now? Rules Depending On Values From Other Rules from http://dry-rb.org/gems/dry-validation/high-level-rules/
total_budget.none?.then(daily_budget.filled?) || daily_budget.none?.then(total_budget.filled?)
I've only recently started digging into Dry::Validation
kaushik vinay TG
@kaushikvinaytg
May 06 2016 19:44
@ttdonovan thanks that seems to work
Tanner Donovan
@ttdonovan
May 06 2016 19:45
I wonder if you should open an issue with that example and share your solution - not really sure which is the correct way
Andy Holland
@AMHOL
May 06 2016 19:49
@kaushikvinaytg I think the method you had originally should work, please open an issue
kaushik vinay TG
@kaushikvinaytg
May 06 2016 19:50
@ttdonovan @ttdonovan okay i will open an issue, thanks
John Backus
@backus
May 06 2016 20:48

So if I have a validator like this

require 'dry/validation'

schema =
  Dry::Validation.Schema do
    required(:name) { filled? & str? & max_size?(2) }
  end

schema.call(name: nil).messages # => {:name=>["must be filled", "size cannot be greater than 2"]}

is it intended behavior that it attaches this second error message ("size cannot be greater than 2") is attached even though the validation that would normally determine that error message isn't even run?

Tim Riley
@timriley
May 06 2016 20:50
@backus yes, that's the intended behavior.
Dry-v has an error messages compiler that builds messages out of all the applicable rules, even if they don't execute.
The idea is that it can give the user enough information to put in a correct value based on all the rules that will eventually run.
John Backus
@backus
May 06 2016 20:53
Thanks @timriley
John Backus
@backus
May 06 2016 20:58
@timriley Is there any way currently to configure dry-validation to not do this?
John Backus
@backus
May 06 2016 21:04
@timriley also can you define "all applicable rules" or point to me to something (can be a commit or code) that explains what is deemed as applicable for being included as an error message?
I ask because it seems like the messages that are provided, in the case of some validations not being executed, seem to be inconsistent
For example: why is this different?
require 'dry/validation'

schema1 =
  Dry::Validation.Schema do
    required(:name) { filled? & str? & max_size?(2) }
  end

schema2 =
  Dry::Validation.Schema do
    required(:name) { filled? & max_size?(2) & str? }
  end

schema1.call({}).messages # => {:name=>["is missing", "size cannot be greater than 2"]}
schema2.call({}).messages # => {:name=>["is missing"]}
(Also I don't want to just complain I'm happy to open an issue and possibly a PR once I know clearly what the desired behavior is)
Tim Riley
@timriley
May 06 2016 22:34
@backus that might be a bug, I reckon. Worth filing an issue.
John Backus
@backus
May 06 2016 22:37
Alright
I also think this "returning all possible errors" thing is questionable and at least worthy of being configurable. Mind if I open an issue for that too?