do you guys actually use dry-rb in production?
We do
dry-validation and dry-types
works great
hmm... i've refactored a pretty big app to use dry-containers/validation/transactions but i'm feeling a bit reluctant to pull the trigger on deploying it
either way. it seems like a very cool collection of libraries
If you have good tests I think you should be safe although I can't vouch for containers and transactions
just lock yourself to a strict version
yeah... for sure
@mikhailvs what’s your concern?
Honestly, I've only very recently stumbled upon dry-rb, and it's hard to gauge how widely it's being used. I suppose it's not a real concern though, more like curiousity.
@mikhailvs it’s used on production by many people
it is unstable though, so APIs may change from time to time until we hit 1.0.0
Is there a way to set a message for a custom dry-validation predicate without loading a yaml file?
not yet
I mean…it is possible to merge in your own messages
is that not recommended/
what you linked to actually seems like a pretty sane way of doing that
well, I don’t like it but it doesn’t mean it’s not recommended. personally I dislike having core objects of my system cluttered with UI-related configurations
I can see that. I'd still feel like there's UI stuff polluting backend code with a yaml conf file though... especially with api driven apps.
how come? that’s a nice separation, just like you separate html templates from objects that provide data for rendering, it’s somewhat similar here
I mean it's stuff that shows up on the frontend, being defined in files of the backend project.
you could render them on the client side and have message templates defined there
I'm not saying I have a different/better approach though. But it seems like the kind of error something is, is coupled with the text description of it, and since the error is generated on the backend, it's fine for other components of it to be defined there as well.
yeah, that's what I'd do if I felt super strongly about it
it’s actually not coupled, we translate generic result object into whatever we want, but since generating string messages is what most people need, it’s been baked into the library
I just made it work with plain YAML because some times you may want to skip i18n as a dependency
Well when you create a custom predicate for a schema it seems like there's at least a logical coupling of its definition and the error message it could generate
you can still apply that predicate w/o generating a message
messages are generated only when you ask for them
as in, when you call .messages?
right, or in
0.10.0 errors
that makes sense
irb(main):004:0> Dry::Validation.Schema { required(:num).value(:int?) }.(num: 'not num').results[0].ast
=> [:key, [:num, [:predicate, [:int?, [[:input, “not num”]]]]]]
well in my case I do need the message and I'm getting Dry::Validation::MissingMessageError if there isn't one. I think since my schema is in its own file/module it's fine to just put the messages for the custom stuff into the configure block
yep, as I said, if you like it, just do it :)
fair enough. in any case, separating the schema definition (sans predicate implementation) into its own file makes it sort of like a configuration file anyway
i just dont want to feel bad about what i'm doing... :P
it’s gonna be easy to move them to a yaml config when you feel like they make schema defs messy :)
i guess my problem is that i'd have to load the file each time i define a schema...
would doing Dry::Validation::Messages.default.merge!(...) one time on app init work?
nvm, doesnt look like theres a merge! implemented
@flash-gordon https://travis-ci.org/dry-rb/dry-validation/jobs/161531234 is this expected? :)
Is there a way to debug rules in dry-validations? I'm trying to find out what values are actually passed to the rule, but using puts inside the rule leads to
+puts+ is not a valid predicate name
where in the definition are you using puts?
rule(valid_blockname: [:ist_blockname, :name]) do |ist_blockname, name|
puts ist_blockname
end
you should try Kernel.puts
or ::Kernel.puts
That works perfectly, thanks!
Is it possible to model this in dry-v? first_name and last_name must be filled. Unless blockname is true, in which case first_name must not be filled.
@solnic I bet this is not :) looking at it
I think
before(:all) { load_extension } is a bad approach, should be reworked in the same way as in dry-t
@solnic @flash-gordon probably new
dry-logic broke rom-sql build (master) See https://gist.github.com/jodosha/55651fe8033477cba882c2af17ee8c9a.
@solnic I confirm that picking
dry-types (master) in Gemfile fixes the problem. :)
@solnic @flash-gordon just updated dry-v on one of our gems and got the same problem :)
https://gist.github.com/tak1n/79c180ac09fbacbae0f432169798233b
@tak1n have you tried to update dry-logic as well? And, probably, dry-t, dunno
gem 'dry-struct', github: 'dry-rb/dry-struct'
gem 'dry-validation', github: 'dry-rb/dry-validation'
gem 'dry-types', github: 'dry-rb/dry-types'
yea I tried to update everything
bundle update and tried it explicitly on some gems bundle update --source dry-validation etc
I mean actually I should just need to update dry-v as I'm just using dry-v (and dry-v uses those other gems internally) :)
There's also a WIP feature in dry-validation where you can infer validations from a struct definition. It's been in an experimental phase since a couple of releases but we're gonna make it robust prior 1.0.0. (by @solnic)
Is it possible to use this feature, or at lease try it now?
@jodosha yeah I know, I need to update/release types and validation
@solnic No worries man. Just wanted you and the rest of the team to be aware of it.
hmm folks who want to stay on dry-v/t 0.9/0.8 will have to pin dry-l to 0.3.0
I hope nobody is doing
bundle update :laughing:
@flash-gordon looks like types/struct are green on CI :)
@solnic should be :) tbh the changes were small enough
@flash-gordon pls merge dry-v pr when it’s green
k
@solnic What’s about
is custom validation done for now ?
dry-validation ?is custom validation done for now ?
@dsounded wdym?
I mean can I write custom code inside rules ?
@dsounded oh sorry, I’ve read it as “gone” :laughing: yes, they are done in master, I’ll push a release today
Wow, glad to hear :)
@flash-gordon WDYT if
value_or should be in Try monad as well ?
Also it would be OK to implement
Xor monad(right biased Either)
@dsounded re
value_or this would be strange a bit. This means you're silently ignoring exception value which is usually not a good idea
if you really want to do it, you can use
my_try.to_maybe.value_or
@dsounded I'll revisit supported monads in a while, when I finish the monads chapter in that haskell book ;)
I might be missing something obvious but is there no way on gitter to just search the dry-rb/chat room?
@backus I bet you're supposed to love new global search, one field for everything
:'(
But every room in gitter is a software room basically
and I want to search deduplicating schemas
Oh it actually worked alright
Maybe the gitter overlords know better
haha
hm, I just tried using dry-validation and I get an exception when requiring the library
@joevandyk hey, sorry about that…it’s my fault, pin dry-logic to 0.3.0 for now. I’ll release new validation/types later today
dry-rb/dry-validation#256
ah ok
I started release process yesterday and didn’t manage to finish, I’ll do it soooon
no worries
what does the validation look like for validating an array of strings?
(and then an array of strings that contain valid urls)
@joevandyk
required(:urls).each(:str?, :url?)
ah, nice. what about an validating that there's at least one image in the array?
@joevandyk
required(:urls).value(min_size?: 1) { each(:str?, :url?) }
unfortunately chaining doesn’t work yet, so you gotta use a block
@/all hey folks! dry-validation 0.10.0 dry-types 0.9.0 and the new dry-struct 0.1.0 gems have been just released. Please do read CHANGELOGs on GitHub before upgrading :) More info coming soon on our blog!
woooo solnic nice woooooorrrkkkk :tada:
how can I validate in dry-validation that a hash has string keys and string values?
I guess you’d need to use the
input macro for that
/home/monkey/.gem/ruby/2.2.5/gems/dry-validation-0.10.0/lib/dry/validation/schema/value.rb:1:in `require': cannot load such file -- dry/struct (LoadError)
from /home/monkey/.gem/ruby/2.2.5/gems/dry-validation-0.10.0/lib/dry/validation/schema/value.rb:1:in `<top (required)>'
from /home/monkey/.gem/ruby/2.2.5/gems/dry-validation-0.10.0/lib/dry/validation/schema.rb:7:in `require'
from /home/monkey/.gem/ruby/2.2.5/gems/dry-validation-0.10.0/lib/dry/validation/schema.rb:7:in `<top (required)>'
is that expected?
oops
this is when requiring dry-v
@solnic I pushed a fix ^
just removed that line, I overlooked it, sorry
@timriley what's the input macro?
@joevandyk you can see it in action here: https://github.com/dry-rb/dry-validation/blob/master/spec/integration/schema/macros/input_spec.rb#L123
Folks, I just wanted to say: You are awesome
:heart: