Follow

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?

dry-rb.org/gems/dry-validation

@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

@timriley @solnic thanks for the link. I'll see if I can make something concrete. I already have published a variant of it (github.com/judofyr/ippon/blob/), but after using it in practice I realized it needs to be tweaked more (and ruby.social/@judofyr/100759635 was the result)

@timriley @judofyr yeah dry-validation went bonkers. This will all be simplified in 1.0.0 like I outlined in the linked thread on discourse.

@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.

Sign in to participate in the conversation
Ruby.social

A Mastodon instance for Rubyists & friends