Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 07:49
    Travis dry-rb/dry-view (docsite-0.7) still failing (612)
  • 07:47

    solnic on master

    Add docsite for version 3.0 [docsite] fix links Merge pull request #69 from skr… and 1 more (compare)

  • 07:46

    solnic on docsite-3.0

    [docsite] fix links Merge pull request #69 from skr… (compare)

  • 07:46
    solnic closed #69
  • 07:46
    Travis dry-rb/dry-view (master) errored (611)
  • 07:44

    solnic on docsite-0.7

    Fix specific typo (compare)

  • 07:43
    solnic commented #136
  • 07:43
    Travis dry-rb/dry-view (master) errored (610)
  • 07:41

    solnic on master

    [docsite] fix parts link Merge pull request #137 from sk… Merge branch 'docsite-0.7' (compare)

  • 07:38

    solnic on master

    [devtools] config sync (compare)

  • 07:32
    Travis dry-rb/dry-view (master) errored (609)
  • 07:27

    solnic on master

    Add sync_configs workflow (compare)

  • 07:26
    Travis dry-rb/dry-view (docsite-0.7) still failing (608)
  • 07:22

    solnic on docsite-0.7

    [docsite] fix parts link Merge pull request #137 from sk… (compare)

  • 07:22
    solnic closed #137
  • Oct 15 22:01
    timriley commented #136
  • Oct 15 21:55
    parndt commented #136
  • Oct 15 21:54
    parndt commented #136
  • Oct 15 17:18
  • Oct 15 17:12
    skryukov edited #137
Opan Mustopah
@opan
Is it possible to do? Thanks in advance
Tim Riley
@timriley
@opan we don’t support that, no. We encourage you to require files you need :)
Adding require or require_relative for any other constants I need to refer to (like Zoo in your case) to the top of my struct class files is exactly what I do in my apps.
Opan Mustopah
@opan
I see, thanks @timriley for your answer
Chris Richards
@cmrichards
With dry-rb validation, how would I validate that 2 dates aren't more than 2 months apart?
Sean Winner
@swinner2
in dry-validation. If I use type_specs = true do I have to declare a type for each rule? Any way to only define a type spec for one rule?
Tim Riley
@timriley
@swinner2 you have to declare a spec for every key, yeah
Tim Riley
@timriley
@cmrichards something like this?
require "dry/validation"
require "time_math"

schema = Dry::Validation.Schema do
  configure do
    def self.messages
      super.merge(en: {errors: {ends_at_within_two_weeks_of_starts_at: 'must be within two weeks of start time'}})
    end
  end

  required(:starts_at).filled(:time?)
  required(:ends_at).filled(:time?)

  validate(ends_at_within_two_weeks_of_starts_at: [:starts_at, :ends_at]) do |starts_at, ends_at|
    two_weeks = 2 * 7 * 24 * 60

    (ends_at - starts_at) <= two_weeks
  end
end

valid_input = {
  starts_at: TimeMath.day.decrease(Time.now, 10),
  ends_at: Time.now,
}

schema.(valid_input).messages
# => {}

invalid_input = {
  starts_at: TimeMath.day.decrease(Time.now, 20),
  ends_at: Time.now,
}

schema.(invalid_input).messages
# => {:ends_at_within_two_weeks_of_starts_at=>["must be within two weeks of start time"]}
I did two weeks instead of two months, but you get the idea
Sean Winner
@swinner2
@timriley I’m trying to find a way to make the default type_spec Types::Anysorry I’m pretty new to dry-validation. Is there an easy way to go about this?
Tim Riley
@timriley
@swinner2 why are you trying to avoid specifying stricter types? The whole idea of dry-validation is to avoid such looseness as comes with an “any” type.
Chris Richards
@cmrichards
@timriley yeah thanks!
Chris Richards
@cmrichards
custom-validation-blocks seem more comprehensible than high-level-rules to me
i.e. I wouldn't need to to refer back to the dry-validation docs when writing them
Ah... i see you get free error-message-creation with high level rules
Piotr Solnica
@solnic
@cmrichards in dry-v 1.0 there will only be custom validation blocks
Chris Richards
@cmrichards
@solnic why?
Piotr Solnica
@solnic
because they are simpler
Sean Winner
@swinner2
@timriley that makes sense and I agree. I guess it’s more of a convenience for the other developers. I wanted a generic schema to validate input for trailblazer operations that would whitelist and coerce, specifically ”true” => true. For now we’ll go with just whitelisting. Some people freak out when seeing types in ruby :scream_cat:
Markus Unterwaditzer
@untitaker
Hi, is there any way to have a Dry::Struct with private fields?
Piotr Solnica
@solnic
@untitaker just do private :attr_name
Markus Unterwaditzer
@untitaker
ah thanks. I only tried private; attribute :foo which wasn't working
Piotr Solnica
@solnic
@untitaker private is a method, it accepts name of a method that you want to mark as private
Markus Unterwaditzer
@untitaker
yes, but in plain classes I can write a line that just says private and all methods below that line are then private, that's why I tried it out
Tim Canty
@timmcanty
Hi, I'm trying to do something specific with dry-validations, but am having a tough time. I have a field that needs to: 1. be optional 2. be an array, if it is present 3. have an each predicate run on the contents. It seems like chaining maybe(:array?).each(predicate) does not throw errors when the value is not an array.
Eugene Khutko
@FoboCasteR
Hi!
What is the Dry::Types::Definition#try method for?
Gustavo Caso
@GustavoCaso
I checks if the value provided is the valid
If so returns a Success object with the value
If is not valid it will return Failureobject with the value and the error message
Gustavo Caso
@GustavoCaso
@FoboCasteR did it help?
Eugene Khutko
@FoboCasteR
Thanks. I already use it this way. But I not found any docs or code examples.
Eugene Khutko
@FoboCasteR
Also, it seems to me inconvenient that Result from Dry::Types instead of Dry::Monads
Piotr Solnica
@solnic
@FoboCasteR we could consider changing it to use Dry::Monads
Gustavo Caso
@GustavoCaso
I should not be a hard change to make
Eugene Khutko
@FoboCasteR
@GustavoCaso Maybe. But this change will make dry-monads a hard dependency.
Gustavo Caso
@GustavoCaso
Yes definitely it will make a dependency of dry-types
Pablo Herrero
@pabloh
Any Idea why this works:
class SubForm < Form
  define! do
    required(:foo).filled(:int?)
    optional(:bar).maybe(:int?)
  end
end

class MainForm < Form
  define! do
    required(:qux).filled(:int?)

    optional(:bar).maybe do
      schema(SubForm.new) # Using new
    end
  end
end
But this doesn't?:
class SubForm < Form
  define! do
    required(:foo).filled(:int?)
    optional(:bar).maybe(:int?)
  end
end

class MainForm < Form
  define! do
    required(:qux).filled(:int?)

    optional(:bar).maybe do
      schema(SubForm) # Using class directly
    end
  end
end
Gustavo Caso
@GustavoCaso
:clap: :clap:
Jeff Dickey
@jdickey
:tada:
Vasily Kolesnikov
@v-kolesnikov
:fire: :+1:
Chris Richards
@cmrichards
Is Factory Girl a good technique to create dB objects use during testing with a new app that will use dry-validation heavily when creating records from form data? Or would it be better to create servicey-type objects and only use them to setup initial DB data in tests?
Piotr Solnica
@solnic
@cmrichards whatever works, we use rom-factory but it's not as mature as FactoryBot (reminder: they renamed the gem)
Chris Richards
@cmrichards
ok. I thought you'd use the same service objects you create in your app to make the objects required in your tests. e.g. CreateCompany.({...}).
Chris Richards
@cmrichards
My concern with using something like factory-bot is that it's a third place you need to maintain the idea of what a valid object is: tests, normal-code, and factory-bot.
Chris Richards
@cmrichards
The functional style of dry-validation::Form is great. The way simple_form and rails renders forms using the form-object/AM-interface is also great. I want some way of living in both worlds, but im not sure if it is possible