Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
I have a question, when I execute http://dry-rb.org/gems/dry-validation/custom-predicates/ I get errors
Dry::Validation::MissingMessageError: message for email? was not found
@alex-lairan as it states at the end of the page, you need to add a message for the custome predicate
I'm so stupid ^^
@solnic did you expect these to start failing?
rspec ./spec/integration/schema/using_types_spec.rb:44 # Dry::Validation::Schema defining schema using dry types fails when sum-type rule did not pass
rspec ./spec/integration/schema/using_types_spec.rb:36 # Dry::Validation::Schema defining schema using dry types correctly responds to messages
rspec ./spec/integration/schema/using_types_spec.rb:25 # Dry::Validation::Schema defining schema using dry types passes when input is valid
rspec ./spec/integration/schema/using_types_spec.rb:30 # Dry::Validation::Schema defining schema using dry types fails when input is not valid
rspec ./spec/integration/schema/using_types_spec.rb:66 # Dry::Validation::Schema defining schema using dry types structs handles nested structs
rspec ./spec/integration/schema/using_types_spec.rb:70 # Dry::Validation::Schema defining schema using dry types structs fails when input is not valid
rspec ./spec/integration/schema/using_types_spec.rb:86 # Dry::Validation::Schema defining schema using dry types custom coercions applies custom types to input prior validation
rspec ./spec/integration/schema/using_types_spec.rb:103 # Dry::Validation::Schema defining schema using dry types custom types applies custom types to input prior validation
make sure you’ve got latest-and-greatest dry-types/logic from master
except now I get these two:
rspec ./spec/integration/schema/predicates/array_spec.rb:216 # Predicates: Array as macro with required when using an input_processor with nil input is not successful
rspec ./spec/integration/schema/predicates/array_spec.rb:224 # Predicates: Array as macro with required when using an input_processor with blank input is not successfulFailures:
1) Predicates: Array as macro with required when using an input_processor with nil input is not successful
Failure/Error: processed_input = input_processor[input]
NoMethodError:
undefined method `map' for nil:NilClass
Did you mean? tap
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/array/member.rb:13:in `call'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:15:in `block in call'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each_with_object'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `call'
# ./lib/dry/validation/schema.rb:203:in `call'
# ./spec/support/predicates_integration.rb:5:in `result'
# ./spec/integration/schema/predicates/array_spec.rb:217:in `block (6 levels) in <top (required)>'
2) Predicates: Array as macro with required when using an input_processor with blank input is not successful
Failure/Error: processed_input = input_processor[input]
NoMethodError:
undefined method `map' for "":String
Did you mean? tap
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/array/member.rb:13:in `call'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:15:in `block in call'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `each_with_object'
# /Users/francesworley/.rvm/gems/ruby-2.3.0/bundler/gems/dry-types-861c0b2619a2/lib/dry/types/hash/schema.rb:13:in `call'
# ./lib/dry/validation/schema.rb:203:in `call'
# ./spec/support/predicates_integration.rb:5:in `result'
# ./spec/integration/schema/predicates/array_spec.rb:225:in `block (6 levels) in <top (required)>'
and I'm using the latest dry-logic/types:
Using dry-logic 0.2.3 from git://github.com/dry-rb/dry-logic.git (at master@8f8dffb)
Using dry-types 0.7.2 from git://github.com/dry-rb/dry-types.git (at master@861c0b2)
ooops my bad, forgot to push dry-v commit :laughing:
Thats better ! Just adding a spec so we can close dry-rb/dry-validation#114
dry-rb/dry-types#93 <= wdyt? /cc @timriley
and dry-rb/dry-validation#137 Do you know why the hint compiler doesn't pick up the input @solnic?
it should pass
expected and current now because we automatically grab args from predicates
obviously should be verified with a spec so that we know it can be closed
I removed most of the custom
options_for_* methods because they were not needed anymore
Yeah and it does, but if I do:
def self.messages
Dry::Validation::Messages.default.merge(
en: { errors: { with_lots_of_args?: '%{foo} %{bar} %{baz} %{value}' } }
)
end
def with_lots_of_args?(foo, bar, baz, input)
false
end
I get:
Failure/Error:
expect(schema.(email: 'email').messages).to eql(
email: ['foo bar baz email']
)
expected: {:email=>["foo bar baz email"]}
got: {:email=>["foo bar baz email", "foo bar baz "]}
(compared using eql?)
Diff:
@@ -1,2 +1,2 @@
-:email => ["foo bar baz email"],
+:email => ["foo bar baz email", "foo bar baz "],
# ./spec/integration/custom_predicates_spec.rb:148:in `block (2 levels) in <top (required)>'
Yeah I know, it seems to ignore the input value and then because they aren't the same we get them both
so we get two msgs in such cases :(
I gotta improve hint-related stuff
@solnic I think the odd thing about that bug report is that providing a
.constructor on Strict::String overrides the existing constructor applying the strictness semantics. So I don’t actually see any reason why someone would want to actually make a custom type on top of Strict::String, in this case.
@timriley yeah that’s my thinking too, but maybe it’s not intuitive
maybe on KRUG one day
@solnic now that we have the new ast, could we get around this by just using the predicate args as tokens and not injecting 'value' at all?
@fran-worley yeah we should do that but I’m not entirely sure if we get
value in all cases yet
@solnic I think the “intuitive” thing to happen there would be that existing constructor(s) run first, and the custom-supplied constructor runs on the final output of those existing constructor(s)
@solnic after the summer break we might figure out a way to bring you in if you would be interested :)
@mensfeld sounds good although I’m gonna be away in September
@solnic And I think, if we can’t support that - or don’t want to - then perhaps we shouldn’t offer
#constructor on top of existing types like that? It should be a “build it yourself from scratch” thing instead.
@solnic KRUG is back after summer break in October ;) so we have plenty of time
@timriley yeah feels like the api should be narrowed down a bit
yeah count me in
@solnic with the new ast, you would do though it would be called whatever you named the arg in your predicate. the only case you wouldn't is if you had no args but then you shouldn't be trying to find it in your message
shall I try it and see?
@solnic I agree. I think contracting the API a little as a first step makes sense. Then we could expand it to offer behaviours like I described later on.
@fran-worley it’d be AWESOME if we could get rid of
ErrorCompiler::Input
it’s being created every time we generate a message, slows stuff down a lot
BUT be aware that handling
each errors with messages for specific elements is tricky
Well can you decide what you want to do about tokens? how do we enable '%{list.join}' in the yaml ?
so assuming
each results have predicates with proper info in the args…then we’re good
I think my specs in dry-logic were coming out correctly but I'll see what blows up :)
oh right this is covered in dry-logic specs…so theoretically it should just work™ (famous last words)
re
list we could introduce some conventions, ie an arg named list would be transformed with list.join(‘, ‘)
we could define arg transformation procs and map them to specific arg names or sutin
doesn't that cause issues with thigs like
def some_validate?(list1, list2) ... end etc
@timriley so you think
Constrained#constructor should raise an error that this makes no sense?
I assume that introducing something like mustache is a bit overkill...
why would that cause issues? it’d be a simple name-based convention ie “if you want your message to include a list of things, call predicate arg “list”`
I don't but we support custom predicates and it's not unreasonable that someone mmight
welllll we can match on the type and have a type-based convention
if an arg is an array then it’ll be
join-ed
not sure I can get rid of the whole thing at this point, but certainly remove all the
options_for stuff
@solnic Yeah, I think so (was just looking over the code). For
Constrained types it’s important that their original #call is run, and not overridden by someone else’s constructor, because otherwise we’re losing their constraints.
That is, I think this is what would be a reasonable step to prevent misunderstandings, until perhaps we could consider a more sophisticated “layering” of constructors later on.
it’s just that the person who reported that issue thought it would apply constraints before his constructor
so basically he thought it would check if the input is valid for his constructor
but it doesn’t work like that, constructors are called in reversed order of definition
so last is called first
Yeah, I get this now.
WONTFIX?
“Write your constructor better?"
I think it’s a not unreasonable expectation for constrained types to check their own constraints first, though.
yeah
that makes sense
it’s the outermost layer
a constructor can transform invalid input to valid, hence it’s on top
ie stripping a string may make a string valid according to
size constraint
stuff like that…
@fran-worley I've done this:
en:
errors:
valid_role?: 'isn\'t a valid role'How I can bind
configure do
config.messages_file = '/path/to/errors.yml'
def valid_role?(value)
Role.all.map(&:name).include?(value)
end
endwith the errors.yml? :)
Thank for your help :)
@alex-lairan if that is where your errors file is located then that should 'just work'
I got
did not find expected key while parsing a block mapping at line 3 column 5
that would imply that there is something wrong with your yml file
Try copying the default one from the gem and checking that you get the missing message error (that would prove that your picking up your custom messages yml correctly) then try adding your message back in
I use this predicate with: key(:name).required(:str?, :valid_role?)
ok I try it :)
Ok one of the problem is \'
another problem now :)
ArgumentError: +valid_role?+ is not a valid predicate name
@alex-lairan what version of dry-validation are you using?
With version 0.7.4 you may have to use a block instead of the macro for custom predicates:
key(:name) { filled? & str? & valid_role? }
And this is ok?
configure do
config.messages_file = '/path/errors.yml'
def valid_role?(value)
Role.all.map(&:name).include?(value)
end
end
@alex-lairan I can't remember what you have access to inside custom predicates in 0.7.4 but at the very least you should get a different error ...
@solnic, @timriley I just read about that issue, and I would expect that
Strict::String runs before my own constructor, since I'm using it as a "base" for my type. So this base type basically is there to identify the final valid type, I could have a Strict::String::TrimmedDowncasedAndSnaked but in the end it would just be a String. We might just need some improvements on the docs to explain that the custom constructors will run before the base and it's your responsibility to check the types, if needed.
@mrbongiolo that too, or we can have an API for handling this somehow
@fran-worley my project look like this:
@schema = Dry::Validation.Schema do
# Some stuff
key(:values).schema(values_schema)
.
.
.
end
def values_schema
Dry::Validation.Schema do
configure do
config.messages_file = '/path/to/errors.yml'
def valid_role?(value)
Chef::Role.all.map(&:name).include?(value)
end
end
optional(:roles).each do
schema do
key(:name) { filled? & str? & valid_role? }
end
end
end
end
@alex-lairan try with
i18n IIRC there’s a known bug in plain-yaml messages where custom messages are not being merged correctl with defaults :/
most people use i18n so plain yaml-based messages didn’t receive much attention
@solnic doesn't all dry::types already do type checking? they are meant to be the very smallest case, that's why I thought they would run first, if the input isn't a string I don't even want my constructor to run. And when I have to check type on it, I'll end up sending it down and the type would be checked again, which seems strange...
constructors are meant to receive a potentially invalid input and turn it into valid so…
something like this:
input.is_a?(::String) ? input.gsub(/\D/, '') : input, if it's a String then get the numbers, if not then send it to strict.string to raise an error...
it really depends on the context and what you’re trying to do, the way it works now makes perfect sense for things we need in dry-v and other places
I’m not against an API that would work like you want though
I have another problem ^^
undefined method `merge' for #<Dry::Validation::Messages::I18n:0x00000004d217d0>
My configure:
configure do
config.messages = :i18n
config.messages_file = '/home/lairan/Documents/selfdeploy/app/validators/errors.yml'
def valid_role?(value)
Chef::Role.all.map(&:name).include?(value)
end
end
I do understand why they are layered like that now, it's just that as the issue shown, people will expect it to work the other way :D
fine, no problem, I'm just saying because that behavior was a "surprise" to me
fwiw if something is strict then it shouldn’t need a constructor
and remember you can do stuff like this:
irb(main):008:0> Types::Coercible::String.constructor(&:strip).constrained(type: String)[" foo "]
=> "foo"
irb(main):009:0> Types::Coercible::String.constructor(&:strip).constrained(type: String)[1]
=> “1”require 'dry-validation'
schema = Dry::Validation.Schema do
configure do
config.messages_file = './errors.yml'
def valid_role?(value)
%w(Admin Viewer Actor).include?(value)
end
end
optional(:roles).each do
schema do
key(:name) { filled? & str? & valid_role? }
end
end
end
pp schema.call(roles: [{name: 'Admin'}, {name: 'Test'}]).messages/home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:195:in `[]': +valid_role?+ is not a valid predicate name (ArgumentError)
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:54:in `visit_predicate'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:254:in `block in initialize_rules'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each_with_object'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `initialize_rules'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:174:in `initialize'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:46:in `new'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema_compiler.rb:33:in `visit_schema'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `block in call'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `map'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:13:in `call'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:45:in `visit_set'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:49:in `visit_each'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:59:in `visit_and'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:32:in `visit_key'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:74:in `visit_implication'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-logic-0.2.3/lib/dry/logic/rule_compiler.rb:18:in `visit'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:254:in `block in initialize_rules'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each'
from /home/lairan/.rvm/gems/ruby-2.2.3/gems/dry-validation-0.7.4/lib/dry/validation/schema.rb:253:in `each_wit
I create issue
@alex-lairan oh that’s an interesting use-case, pls report. as a workaround you can define an external schema with the predicate and do
schema(RoleSchema)
that configure block defines predicate methods on the main schema, and inside each we create a new one, which doesn’t inherit outer schema predicates hence the error
@solnic maybe what we need is some kind of "filters" or "transformers", those would apply after everything else. So the constructor would be used only for complex cases.
ex: my api could accept all these as valid date:
ex: my api could accept all these as valid date:
"10/02/2016", '2016-02-10', [2016, 10, 02], 02/10/2016 and so on, so the constructor would check all the possibilities and return a Date, after that we could transform that value, if needed. I'm not sure if Dry::Types is aiming for this type of data transformation, but some constructors are used like that.
constrained types are meant to be used for type-checking in places like structs where input is expected to be valid, they are not meant to be used as a sanity check for custom constructors. so we basically need a new concept
let’s postpone this for 0.9.0 though, I’m WAY behind my schedule already