These are chat archives for dry-rb/chat

Oct 2016
George Millo
Oct 27 2016 10:23
@solnic just wondering, is there a way to contribute to or suggest edits to the dry-rb doc pages? in the same way that the Rails guides are stored in the git repo and so are open to PRs
as I figure out dry-validation there are a few things in the docs that left me scratching my head. Happy to write and suggest some improvements
(that is, once my understanding of how dry-validation is good enough for me to write docs that are actually correct)
one thing I think would be really helpful is a brief overview of how ActiveModel validations can translate to equivalent(ish) dry validations. (Yes, I know that they won't have a 1:1 relationship).
so in what is probably a very common scenario - someone experienced in Rails is trying to figure out how to switch from AM to dry-v (this is my scenario)
George Millo
Oct 27 2016 10:30

some example code along the lines of:

# active_model:
validates_presence_of :name 
validates_numericality_of :age, greater_than: 18

# dry
required(:name)... # whatever would be a similar validation

and a brief description of how these validations are actually slightly different (e.g. dry is checking for the presence of a key but AM isn't)

would really help Rails guys like me grok dry-rb and ease the switch
Piotr Solnica
Oct 27 2016 10:41
@georgemillo that would be very helpful, you can always open a PR in the repo
there’s actually a WIP doc with AM/AR vs dry-v
nobody had the time to finish it
it’s right here: dry-rb/
it’s probably quite out-dated already
Ricky McMillen
Oct 27 2016 11:11

Hi folks. Really enjoying everyones work on the dry-rb gems. I hope to pull some of them into our projects. I have a question regarding validation, more specifically dynamically defining schemas.

My scenario is that users can configure their own registration forms - basically what fields they see as mandatory - so I need a way to dynamically create a schema and use it for validating the required fields and ideally also enforce sensible formatting validations. Can anyone see a way to accomplish this? Does this scenario fit into the realms of dry-validation philosophy?

Piotr Solnica
Oct 27 2016 11:19
@ricky-crichq yes, in fact, dry-v is very well suited for defining schemas dynamically
also, hi :D
the only problem is that this very part is not documented at all. If you need help please post your questions on and we can take it from there
Ricky McMillen
Oct 27 2016 11:24
Hi @solnic , thanks for the response.
I will take a look through the code and the discussion board!
Piotr Solnica
Oct 27 2016 11:26
@ricky-crichq basically dry-validation schemas generate a set of rule objects, and apply them to the input. These rules are provided by dry-logic gem. You can instantiate a schema by passing existing rules to the constructor. This means that generating a schema dynamically is a matter of generating rules
then it’s just
and rules are generated based on a simple AST format
ie here is an example how to generate a key operation which applies filled? predicate to a value extracted from a hash
solnic @solnic really needs to document this one day
Ricky McMillen
Oct 27 2016 11:36
Ah, thats great! Will definitely need to play around with this for a while to wrestle the JSON config into the AST rules. Thanks again! :sunglasses:
Piotr Solnica
Oct 27 2016 11:40
@ricky-crichq depending on how complex your rules can be, this will be either trivial, simple, or not-so-hard :)
if you need to transform JSON into rule AST, then I suspect it’ll be quite simple
as we’re talking about converting one data structure into another :)
it will especially simple if you’re in control over the JSON structure, as you can make it in a way that’s easy to transform
George Millo
Oct 27 2016 13:28
@solnic thanks, that what I was looking for! I'm definitely interested in contributing... I just should probably wait until I'm more familiar with the gem so that any documentation PRs I open actually contain correct information ;)
one little thing I think should definitely be made clearer in the docs is precisely what's meant by "filled".
filled = !key.nil? && !value.nil? && !value.empty??
is that the right pseudocode?
what happens if the value doesn't respond_to empty?
Piotr Solnica
Oct 27 2016 14:04
ugh, this should be changed to simply call !empty?(input)
(applies to other cases)