These are chat archives for dry-rb/chat

3rd
Aug 2016
When open source projects go uncared for ¯_(ツ)_/¯
Piotr Solnica
@solnic
Aug 03 2016 10:27
haha
Tim Riley
@timriley
Aug 03 2016 10:27
The PR to fix it is literally deleting 5 lines
Piotr Solnica
@solnic
Aug 03 2016 10:27
no response in the PR?
Tim Riley
@timriley
Aug 03 2016 10:27
Nope. I told them about this fork and offered to help: https://github.com/rtomayko/shotgun/pull/61#issuecomment-237200490
Fran Worley
@fran-worley
Aug 03 2016 10:59
@solnic have you got any ruby magic for simplifying this? It enables us to symbolize keys Reform's string keys before passing to dry-v but it's getting a little nasty the more use cases I encounter:
      def symbolize_hash(hash)
        hash.each_with_object({}) { |(k, v), hash|
          hash[k.to_sym] = if v.is_a?(Hash) 
                             symbolize_hash(v) # needed for schema do; end
                           elsif v.is_a?(Array) # needed for each do ; schema do ; end ; end
                             v.map{ |h| symbolize_hash(h) }
                           else
                             v # just plan and simple attributes
                           end
        }
      end
Essentially we are now using Schema and not form as reform has already coerced values. So in Reform we are now symbolizing keys or schema doesn't pick them up at all
I always feel a little unpleasant when I essentially re-write an active support method...
Piotr Solnica
@solnic
Aug 03 2016 11:02
@fran-worley you could use Types::Hash#symbolized from dry-types for that assuming you have property info from Reform
Fran Worley
@fran-worley
Aug 03 2016 11:06
And types will do deeply nested hashes like these?
{"title"=>"Reform", "producers"=>[{"name"=>"some name", "artist"=>{"name"=>"some name"
}}, {"name"=>nil}], "hit"=>{"title"=>"some title"}}
Piotr Solnica
@solnic
Aug 03 2016 11:14
yes
it just needs a schema (dry-t’s hash schema, not dry-v)
Fran Worley
@fran-worley
Aug 03 2016 11:15
Cool I'll take a look. Thanks
Piotr Solnica
@solnic
Aug 03 2016 11:23
Types::Hash.symbolized(
  title: Types::String, 
  producers: Types::Array.member(
    Types::Hash.symbolized(name: Types::String, artist: Types::Hash.symbolized(name: Types::String))
  )
)
sth like that
best to use an ast, we have a type compiler
will be much simpler than building types manually
so if you can dump reform’s properties to type ast, you’re done
just replace :strict with :symbolize
if you don’t require types in properties, you may want to add a passthrough Types::Object to dry-types and default to it
although I wouldn’t recommend that :)
Fran Worley
@fran-worley
Aug 03 2016 11:28
Yes, I've just been reading the docs. In our case, we have already coerced the values so in your examples will types attempt to coerce them again?
Piotr Solnica
@solnic
Aug 03 2016 11:29
no if you use plain definitions!
Types::String is a simple definition, no coercion
Fran Worley
@fran-worley
Aug 03 2016 11:31
Cool. I'll have a chat with Nick. It might end up being more work to extract the schema from reforms property definitions than it's worth. Ideally we would just symbolize the keys when we coerce them but there is a reason they are kept as strings apparently
Piotr Solnica
@solnic
Aug 03 2016 11:35
would be good to know this reason
Fran Worley
@fran-worley
Aug 03 2016 11:35
It's probably legacy AMV stuff that we might now be able to move to reform-rails
Piotr Solnica
@solnic
Aug 03 2016 11:35
I actually start to like the idea that reform does coercion…
it turned out to be very tricky in dry-v
Fran Worley
@fran-worley
Aug 03 2016 11:36
Yeah the decoupling of the two is pretty nice. It also mean that those who still want to use Virtus or any other coercion lib can.
The problem with the current release is that reform passes a string key hash with coerced values to a dry-v form so if anyone has defined type predicates we get nasty errors as form tries to coerce the already coerced values.
Piotr Solnica
@solnic
Aug 03 2016 11:41
well, there must be a weird reason why reform passes stringified hashes
and would be good to get rid of it :)
Fran Worley
@fran-worley
Aug 03 2016 11:41
indeed. Then I can move on to sorting out error message handling and then we will have a pretty stable clean integration of the two
Piotr Solnica
@solnic
Aug 03 2016 11:42
can’t wait, I’ll give it a shot when it’s out
Kiril Dokh
@dsounded
Aug 03 2016 12:01
Hello @solnic Have you done that release with my need ?)
Piotr Solnica
@solnic
Aug 03 2016 12:04
@dsounded hey…no…still recovering after my rom 2.0 sprint… patience is adviced ;)
Kiril Dokh
@dsounded
Aug 03 2016 12:04
I see :)
Fran Worley
@fran-worley
Aug 03 2016 12:04
@dsounded PRs are also welcome if you want to have a go yourself
Kiril Dokh
@dsounded
Aug 03 2016 12:05
I’d asked Piotr, but he recommended not to implement that, because that’s not a good point to start
Piotr Solnica
@solnic
Aug 03 2016 12:05
right, that and the fact we gotta do few improvements in the DSL before making it more complex
Fran Worley
@fran-worley
Aug 03 2016 12:05
Fair enough, then patience my friend :sparkles: Ahh and that's on my list...
Chip Eyler
@freqn
Aug 03 2016 17:37
Quick question on something that I'm possibly overlooking in the docs and fundamentally misunderstanding in reference to Dry Validations.. I'm attempting payload validation and would like an explanation of optional vs required. For example, assume I have required(:person_uid).maybe(:str?) in my validator. I'm trying to understand when to use one vs the other.
This message was deleted
Jeff Dickey
@jdickey
Aug 03 2016 17:38

Blindingly simple question, folks: I understand a Dry::Types example like

email = Types::Strict::String.constrained(
  format: /\A[\w+\-.]+@[a-z\d\-]+(\.[a-z]+)*\.[a-z]+\z/i
)

but how would I code a String.constrained that requires to not match a format?

Sean Collins
@cllns
Aug 03 2016 17:39
@freqn I think the difference is that required...maybe means the value can be nil but the key must exist. For optional, the key doesn't have to be there.
Jeff Dickey
@jdickey
Aug 03 2016 17:39
my brain is going into pumpkin mode; it's after 0130 here :P
Chip Eyler
@freqn
Aug 03 2016 17:40
Thank you @cllns . That actually helps
Jeff Dickey
@jdickey
Aug 03 2016 17:41
Say I've a thing like foo = Types::Strict::String.constrained( not_format: /\s{2,}/); what's the correct way to code that?
Piotr Solnica
@solnic
Aug 03 2016 17:45
@jdickey we don’t have a predicate like that, you could add it yourself via Dry::Logic.predicate(:not_format) { |v| … } IIRC this should do the trick for now
Jeff Dickey
@jdickey
Aug 03 2016 17:48
@solnic Thanks; that's kind of the answer I was expecting; I'll hit that in the morning. Thanks! One last bit: for the obvious example of password/confirmation, is there any way in Dry::Types for me to require that the confirmation be identical to the password, or is that something I'm going to have to write a Dry::Validation schema for?
probably ought to do most of this in Validation, actually; nvm
Piotr Solnica
@solnic
Aug 03 2016 17:51
yes that’s dry-v
Jeff Dickey
@jdickey
Aug 03 2016 17:52
thanks again :)
Piotr Solnica
@solnic
Aug 03 2016 18:33
@jdickey np, and btw, it’s best to ask support questions here https://discuss.dry-rb.org (we’re trying to move from support-channel to more dev-talk-oriented channel)
I check it daily and reply asap
Terry Appleby
@tappleby
Aug 03 2016 19:12
Is it possible to specify default values for a predicate?
whoops. just saw that last message about https://discuss.dry-rb.org