I do think that dry-rb is doing many things right, but some of the parts seems a bit too DSL for my.
how is this "simply"? what's the difference between inside and outside `configure`? why do I need a completely different syntax when I want to share predicates?
@judofyr dry-validation is currently slated for a big overhaul. Now's a great time to share your thoughts with us - it'd be great to have them inform future development!
@timriley ah, cool. I'll try to write a proper PoC to see how it works in practice. how do dry-rb communicate/work/collaborate?
@judofyr mostly we’re in gitter.im/dry-rb/chat and longer discussions on github or discourse.dry-rb.org. Would be great to hear your thoughts!
@timriley yeah, I have some opinions on how this should work, but it doesn't combine so well with e.g. Rails' "auto-parse formdata/queryparams into one big Hash" and other conventions
@judofyr yeah, that’s not our style either. FWIW, this maybe a useful read about our future plans: https://discourse.dry-rb.org/t/plans-for-dry-validation-dry-schema-a-new-gem/215
@timriley @solnic thanks for the link. I'll see if I can make something concrete. I already have published a variant of it (https://github.com/judofyr/ippon/blob/validate/lib/ippon/validate.rb), but after using it in practice I realized it needs to be tweaked more (and https://ruby.social/@judofyr/100759635363029152 was the result)
@judofyr oh and I guess I should mention that this DSL is actually optional. You can just have a class, define methods as custom predicates, and define schema inside `define do..end` block. Then you can simply instantiate your class. That DSL was introduced as a convenience to cover most common case - defining a schema *object*.
@solnic the documentation makes this rather difficult to understand. I don’t really know how the the different objects are working together. I miss some reference docs instead of just cookbook examples
@solnic but then, I’m looking at this from a perspective where I want to fully understand it. someone who just wants to use it might have a different preference.
@judofyr the intention of user docs is to explain how to use a given gem, so I'm not surprised. Understanding fully how dry-validation works will be very difficult, due to *extreme* internal complexity.
If you have questions, shoot, it'll be faster.
@solnic I don't need to know how everything works beneath the hood, but I do wonder:
- what other choices than `required` are there? is there a full list somewhere?
- what does `filled` do? what are the alternatives? what happens if I don't call it?
- what is the difference between `required` without `filled` and `optional`?
- what are the values yielded in custom rules? what's `true?`?
- what's the difference between rules and validation blocks? when should I choose one over the other?
@solnic I don't understand the concepts. there's a (1) schema-object, (2) the thing that `required` returns, (3) predicates like int?, (4) custom rules and (5) validation blocks. it's hard for me to understand how they are connected and how you combine them.
@solnic thanks! that makes things a bit more clear.
A Mastodon instance for Rubyists & friends