These are chat archives for dry-rb/chat

13th
Sep 2016
Don Morrison
@elskwid
Sep 13 2016 03:05
@cored not sure what you’re doing but you may be running into an issue with coercion.
Muhammad Hilmy Fauzan
@muhifauzan
Sep 13 2016 12:17

Hi all. I have a question to ask. How do you handle one-to-many nested attributes from rails form?
If for example I have params like this

"office"=>
  {"name"=>"Off 1",
   "directors_attributes"=>{"0"=>{"name"=>"Dir 1", "_destroy"=>"false", "id"=>"0"},
                            "1"=>{"name"=>"Dir 2", "_destroy"=>"false", "id"=>"1"}}}

How do I write the schema so it can handle the hash index? I hope this question is not annoying.

I'm sorry, I'm asking about dry-validation
Thank you in advance
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 12:20
@muhifauzan I would transform the data
Muhammad Hilmy Fauzan
@muhifauzan
Sep 13 2016 12:21
So, it's better to transform the data before doing the validation? I'm trying to take advantage of accept_nested_attributes_for
I'm wondering in which case is nil a meaningful value?
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 12:44
@muhifauzan accept_nested_Attributes_for sucks like hell, it makes code harder to understand I would not use it
@muhifauzan the less magic thebetter
Muhammad Hilmy Fauzan
@muhifauzan
Sep 13 2016 13:34
@cdennl Hmm. Fair enough. LOL
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 13:36
@muhifauzan from an architects point of view and as somebody who already made those mistakes don't let too much magic happen in your business logic, it will become a nightmare sooner or later;
@muhifauzan define strict borders between the outside world and where your own business logic begins
@muhifauzan and if the outside world does not match with your business logic, then you can always write a converter class to map it
@muhifauzan my advice is to keep your business logic as clean as possible and let the mud be in the outside world
@muhifauzan I made good experience with this type of structuring but needs some discipline and experience
Muhammad Hilmy Fauzan
@muhifauzan
Sep 13 2016 14:14
@cdennl I see. You're talking from experience, good value for me. Thank you very much for your advice
I don't really like the magic rails gave actually. Too many implicit stuff going on there
Dario Hamidi
@dhamidi
Sep 13 2016 14:17
Hey! I've spent the last ~30 minutes trying to figure out how to implement a URL type using the standard library's URI class. Any hints on how one would go about this?
Andy Holland
@AMHOL
Sep 13 2016 14:34
@dhamidi depends on what behaviour you need from it
Dario Hamidi
@dhamidi
Sep 13 2016 14:45
basically I just want to leverage URI.parse as a validation rule
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 14:47
@muhifauzan yes thats true. I am using rails myself but I stripped out the magical and implicit stuff because after some time it is a maintenance nightmare
@muhifauzan I am using the trailblazer framework and stripped activerecord for sequel and actionview for cells
Rafael George
@cored
Sep 13 2016 15:16
I'm trying to understand in which context virtus call the default: key
at construction time ?
Piotr Solnica
@solnic
Sep 13 2016 17:44
@cored don’t use virtus, you can be way more successful with dry-validation/types, unless you’re not comfortable with these gems being below 1.0.0
Rafael George
@cored
Sep 13 2016 17:45
well I'm using what is already in the codebase
that's why I'm using virtus for now
Piotr Solnica
@solnic
Sep 13 2016 17:45
if it’s not a big and complex thing, you could port it :)
Rafael George
@cored
Sep 13 2016 17:45
I'm totally with you on that
the thing is that this team :-)
maybe won't like the idea
Piotr Solnica
@solnic
Sep 13 2016 17:45
gotcha
@cdennl there are API changes but nothing drastic. also some hints are now different (read: more correct), there’s one feature that was removed but it was stupid and I bet nobody used it anyway (defining more than one rule inside when block). in general, this is a huge release that’s mostly focused on improving message compiler and hints, that gets us closer to 1.0.0
Piotr Solnica
@solnic
Sep 13 2016 17:51
@cdennl oh and there’s one last-moment addition that I think will be very helpful - support for arbitrary validation logic via validate + block
I think it could replace high-level rules completely as personally I’ve found them to be too confusing and they make DSL implementation harder
having predicate logic operators there is cool but I’m not sure if it’s worth the effort when it can be easily replaced with conditionals and standard ruby operators, which probably is not a big deal
we should have a discussion about it and decide what to do prior 1.0.0
oh and I should mention that validate block works the same wrt dependencies, so you provide a list of things your block depends on and dry-v will execute your block only when basic checks passed
Rafael George
@cored
Sep 13 2016 17:54
@solnic for a weird reason the defaults doesn't happen if you pass a nil to the attribute
is that expected?
to me there's no context in which nil is meaningful but maybe I'm wrong on that assumption
Piotr Solnica
@solnic
Sep 13 2016 17:55
@cored asking about virtus?
Rafael George
@cored
Sep 13 2016 17:55
oh yes
virtus
so I have something like identity_provider_url, default: ""
Piotr Solnica
@solnic
Sep 13 2016 17:55
@cored I don’t remember, IIRC there’s allow_nil option or something
Rafael George
@cored
Sep 13 2016 17:55
but if I initialize my form object for that attribute wiht nil it's gets nil instead of the default
gotcha
I wonder if conditional validation is a good idea
from active record point of view
stuffs like this validates_presence_of :card_number, :if => :paid_with_card?
let me check how dry-validation solve that
Piotr Solnica
@solnic
Sep 13 2016 18:01
@cored in dry-v validation is always conditional, I’d like to “remove” the notion of “conditional validation” as I think it’s confusing
Rafael George
@cored
Sep 13 2016 18:02
totally
I don't see a better way to write it
maybe I should just write a custom validation and check internall for the needed fiels
Piotr Solnica
@solnic
Sep 13 2016 18:04
@cored that’s a job for a high-level rule ie in 0.9.5 you can do this: rule(check_card: %i[paid_with_card card_number]) { |pwc, cn| pwc.true?.then(cn.filled?) }
there’s also a shorcut for that ie required(:paid_with_card).value(:bool?).when(:true?) { value(:card_number).filled? }
Rafael George
@cored
Sep 13 2016 18:04
hm
I like the second one
Piotr Solnica
@solnic
Sep 13 2016 18:05
that’s why it exists :laughing:
I haven’t spent much time on high-level rule syntax yet
Rafael George
@cored
Sep 13 2016 18:05
thanks you are so considered to think of me for that DSL :-P
hehehe
I need to remove my custom policy engine with dry-validations at some point
that will be the best way to do it
Piotr Solnica
@solnic
Sep 13 2016 18:05
there are LOTS of common patterns for data validation and we can have lots and lots of macros that are doing really complex checks and can be expressed on a single line
we’ll get there
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 18:23
@solnic I am perfectly fine with arbitrary validation blocks and removing high_lvel rules
sounds good
Piotr Solnica
@solnic
Sep 13 2016 18:24
one thing though - the idea is the same, I was talking about specifics of the DSL exclusively
so rule + predicate DSL or just validate with arbitrary code
high level rule as a concept is exactly the same
Christopher Dennl-Ortega Arrieta
@cdennl
Sep 13 2016 18:25
ok
I can live with both :) most often I try to avoid too fancy things anyway when it is not necessary