These are chat archives for dry-rb/chat

27th
Oct 2016
George Millo
@georgemillo
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
@georgemillo
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
required(:age)...

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
@solnic
Oct 27 2016 10:41
@georgemillo that would be very helpful, you can always open a PR in the repo https://github.com/dry-rb/dry-rb.org
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/dry-rb.org#52
it’s probably quite out-dated already
Ricky McMillen
@ricky-crichq
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
@solnic
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 discuss.dry-rb.org and we can take it from there
Ricky McMillen
@ricky-crichq
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
@solnic
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 YourSchemaClass.new(your_rules)
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
@ricky-crichq
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
@solnic
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
@georgemillo
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
@solnic
Oct 27 2016 14:04
ugh, this should be changed to simply call !empty?(input)
(applies to other cases)