Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Piotr Solnica
@solnic
ie dry-v builds up a coercible hash using dry-d for Schema::Form, it does form coercions for you and symbolizes keys
there are different types of hashes in dry-d, so you have a strict one, a non-strict one, non-strict with symbolized-keys (that's the one that dry-v is using)
dry-d structs and values are meant to be used as your domain data types, strictness is encouraged too
not just wrt type primitives but also any possible constraints
Piotr Solnica
@solnic
there’s a lot tbd to improve errors coming from dry-d though, it’s a bit rough right now
Chris Richards
@cmrichards
So how would you do something simple like this in drd? https://gist.github.com/cmrichards/364920a5ffd6c49420c5
Piotr Solnica
@solnic
gimme a minute, I actually just added new features to dry-v to allow this
Piotr Solnica
@solnic
class BarcodeSchema < Dry::Validation::Schema::Form
  key(:barcode, &:filled?)
  key(:job_number) { |v| v.none? | v.int? }
  key(:sample_number) { |v| v.none? | v.int? }

  rule(:barcode_only) do
    rule(:barcode) ^ (rule(:job_number) | rule(:sample_number))
  end

  def self.messages
    Dry::Validation::Messages.default.merge(
      en: { errors: {
        barcode_only: 'Can only enter data into barcode OR job/sample fields, not both'
      }}
    )
  end
end
@cmrichards something like that will be possible starting from dry-v 0.4.0
I’m not sure if people will like using logic in the long term so maybe we can introduce higher-level macros, but I dunno, I kinda like it, forces you to think in terms of pure logic
Chris Richards
@cmrichards
I agree.
It looks pretty good
and you do BarcodeScheme.new(params[..]) ?
Piotr Solnica
@solnic
oh and typically you want to put error messages in a yaml file
uhm, actually this is not an equivalent of your example, seems like we need a negation support there
Chris Richards
@cmrichards
I get the idea though
Piotr Solnica
@solnic
ok cool :)
Chris Richards
@cmrichards
is there a "valid?" method or is that done differently?
Piotr Solnica
@solnic
no, it’s stateless
so it’s schema = MySchema.new and schema.call(params)
it returns a result object back with a ton of information
Chris Richards
@cmrichards
And the result object is a hash?
Piotr Solnica
@solnic
it’s a validation result object, it responds to #messages which gives you compiled error messages as a hash with access to string error messages and the input for each error
{:barcode_only=>[["Can only enter data into barcode OR job/sample fields, not both"], "123"]}
sth like that
Chris Richards
@cmrichards
I see. So there will be more work needed for it to work with Rails form_for helpers?
I look forward to using it. For now I gotta go. Thanks.
This seems a bit like reform contracts?
the "reform" gem
Piotr Solnica
@solnic
reform will use it soon (or even already has support for it)
we collaborate with Nick a lot lately
Chris Richards
@cmrichards
excellent
Piotr Solnica
@solnic
btw the missing ingredient is this:
rule(:barcode_only) do
  rule(:barcode) ^ not(rule(:job_number) | rule(:sample_number))
end
notice not
I gotta add it, it’s gonna be useful in many places anyway
Chris Richards
@cmrichards
What's the ^?
Piotr Solnica
@solnic
xor
Chris Richards
@cmrichards
k
Piotr Solnica
@solnic
either side must be true to make it all true
Chris Richards
@cmrichards
I know my CS ;-)
Piotr Solnica
@solnic
:)
Chris Richards
@cmrichards
Although I didn't know it was a ruby operator until now!
Piotr Solnica
@solnic
hah yeah, it’s a native operator in ruby
true ^ true => false
true ^ false => true
Chris Richards
@cmrichards
yeah I just tried that
Piotr Solnica
@solnic
cool :)
Piotr Solnica
@solnic
class BarcodeSchema < Dry::Validation::Schema::Form
  key(:barcode, &:filled?)
  key(:job_number, &:int?)
  key(:sample_number, &:int?)

  rule(:barcode_only) do
    rule(:barcode) ^ (rule(:job_number) | rule(:sample_number))
  end
end
@cmrichards so, that’s the most concise way of writing this ^^^…but, there are a couple of things I realized while writing this
it seems like we have two concerns here, first one being the validation schema for valid types, the second one being high level rules that should be applied to already validated input