Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 03 20:46
    nbcraft review_requested #101
  • Oct 03 20:46
    nbcraft opened #101
  • Oct 03 20:15
  • Oct 03 15:12
    hi-tech-jazz commented #162
  • Oct 03 15:11
    hi-tech-jazz commented #162
  • Oct 03 12:13
    hi-tech-jazz commented #162
  • Oct 03 12:13
    hi-tech-jazz commented #162
  • Oct 02 16:22
    angel-mora starred dry-rb/dry-system
  • Oct 02 04:20
    timriley commented #85
  • Oct 01 09:06
    solnic commented #85
  • Sep 30 02:13
    kihaya starred dry-rb/dry-system
  • Sep 29 17:17
    kid1z starred dry-rb/dry-system
  • Sep 29 11:26
    AbdallahMH starred dry-rb/dry-initializer
  • Sep 28 21:17
    flash-gordon commented #40
  • Sep 28 13:23
    zacheryph commented #40
  • Sep 28 09:45
    flash-gordon commented #40
  • Sep 27 19:54
    zacheryph commented #40
  • Sep 27 07:26
    flash-gordon commented #85
  • Sep 25 21:20
    timriley edited #248
  • Sep 25 21:19
    timriley synchronize #248
Roman Glebov
@r-glebov
@gotar I need to pass the new property ip_and_netmask_converted_to_range built from ip and netmask as an option to validate block. This is only way to show the value of this property in error message.
Roman Glebov
@r-glebov
input preprocessing with dry-types processes only 1 property. It’s not possible to get one property as an argument into another and preprocess it whatever I like.
Oskar Szrajer
@gotar
there is no possibility to access another properties
you only have access to single one
if you need extra preprocessing you need to add another step, like preproces -> validate
no preproces during validate
Piotr Solnica
@solnic
yeah, this is one of the things that will be improved in 1.0
Roman Glebov
@r-glebov
Good to know that it is in upcoming list of features :)
Piotr Solnica
@solnic
in general, dry-v 1.0 will be mostly about high-level domain validations
and it'll use dry-schema under the hood for basic data processing and type checks
Oskar Szrajer
@gotar
still it's more natural and separated for me to do this in another step. But for sure it's more convenient to do everything at once
Roman Glebov
@r-glebov
depends on point of view, in my opinion what happens in validation stays in validation )
Oskar Szrajer
@gotar
but validation and processing are 2 different stuff. if you got from behind the wall (for example internet) stuff like age: '123', you pre-process to have a number, so you have 123 now and then you validate if it's matching requirements like 18>age>80
but as you said, depend from point of view
and needs in current place
Steve Clarke
@srcnix
Dry-System container, am I right in thinking that bootable components will only run when you first access them? So if you have a bootable component named "testing" and register a component within the bootable as "testing", when you resolve "testing" it would work?
Steve Clarke
@srcnix
Ahah! Ok, it does work as I expected by dry-system stubs doesn't correctly stub bootable components.
Lairan
@alex-lairan

How can I configure i18n for Dry-validations?

Can I put something like this on initializer (I am using rails)

Dry::Validation.Schema do
  configure { config.messages_file = '/path/to/my/errors.yml' }
end
Alexander
@cutalion

@alex-lairan try this

Dry::Validation.Schema do
  configure { config.messages = :i18n }
end

You can read about I18n here: http://dry-rb.org/gems/dry-validation/error-messages/

Max Kuzmin
@maximkuzmin
hi there!
i'm kinda newby with dry-rb and wanted to use dry-types for my pet-project
i used to use rails autoload but now it's sinatra and i have some issues with loading all my types module
is there any way to not implement all rails autoload system Doppelganger and still not write all relative imports by hand?
Vasily Kolesnikov
@v-kolesnikov
Yes, it is. Look at dry-system.
Alfonso Uceda
@AlfonsoUceda

Hi folks, I'm experiencing a weird behaviour with rules, it seems they aren't nested and
they always are in the high level, take a look:

inner_schema = Dry::Validation.Schema do
  required(:vendor)    { type?(String) & filled? }
  required(:starts_on) { type?(String) & filled? }
  required(:ends_on)   { type?(String) & filled? }

  rule(time_range: [:starts_on, :ends_on]) do |starts_on, ends_on|
    ends_on.gt?(starts_on)
  end
end

schema = Dry::Validation.Schema do
  required(:contract).schema(inner_schema)
end

schema.call(contract: {vendor: '', starts_on: '2019-01-01', ends_on: '2018-01-01'}).messages
# => {:contract=>{:vendor=>["must be filled"]}, :time_range=>["must be greater than 2019-01-01"]}

inner_schema.call({vendor: '', starts_on: '2019-01-01', ends_on: '2018-01-01'}).messages
# => {:vendor=>["must be filled"], :time_range=>["must be greater than 2019-01-01"]}

is this a bug?

Spencer Goh
@dymaxionuk
I'm trying to unit test a dry transaction, however several problems.
Spencer Goh
@dymaxionuk
The transaction steps normally dynamically look up the operations from the container, however in spec, I'm manually instantiating the transaction, and passing a double into the constructor... But the original operation is being resolved instead... Am I supposed to use the container stub, instead of manually injecting a double?
Spencer Goh
@dymaxionuk
Ah mea culpa, <delete above! > the problem is actually my inability to stub a transaction step, which is defined locally in a transaction class. Sorry can't type example easily on mobile phone. def mylocalstep... expect(transaction).to receive(:mylocalstep).and_return(blah)
Doesn't seem to intercept the transaction step... Would be good to have a comprehensive set of testing examples for the dry family ....
Spencer Goh
@dymaxionuk
allow_any_instanceof(MyTransactionClass).to receive(:mylocalstep) does work. By not the above... Is there some magic going on?
Piotr Solnica
@solnic
@dymaxionuk expect-to-receive doesn't stub methods
Guilherme Moreira
@gmmoreira
IMHO if the step is defined locally in the class I would not stub it, otherwise I'm not testing all the behavior in my class. I would only stub operations injected by the container..
Piotr Solnica
@solnic
yes this

I'm manually instantiating the transaction, and passing a double into the constructor... But the original operation is being resolved instead

this looks like a bug, btw

Spencer Goh
@dymaxionuk
@solnic on the injection of double, I had a typo on the instance variable name. No bug oops
The reason I'm subbing out one of the steps (2nd step), is that the first step basically exits fast, on certain condition. So I only want my test to check that on one condition the second step is called, as other condition the second step is not called.
The downside of allowing my second step to be executed fully, is that it then pulls another operation from my container... That operation then auto injects some repos etc and the injection then forced me to pull in my db spec helper instead of just vanilla spec helper. I don't need to test such a bit surface area in this case.
Spencer Goh
@dymaxionuk
In testing that full code path for step two in my full end to end tests, as there is little value unit testing that. So bottom line is I should be able to do: ```expect(transction).to receive(:blah_step).and_return(dummy_data)
Piotr Solnica
@solnic
maybe it's using method objects, so rspec expectation can't work with it, not sure
@dymaxionuk Sounds like you’ve hit this issue? dry-rb/dry-transaction#75
Someone has promised to fix it, but they’ve taken months. I’ll see if I can do it myself sometime soon (or I’d be happy if you wanted to have a go, too!)
Jonah
@jonahx
:thumbsup: to new release!
@flash-gordon ^
Vasily Kolesnikov
@v-kolesnikov
:+1: :clap:
Nikita Shilnikov
@flash-gordon
pretty cool huh :)
Gustavo Caso
@GustavoCaso
:clap: :clap:
Spencer Goh
@dymaxionuk
Thanks @timriley wish I had time to explore, between slaving away at work and looking after baby, not much time left! I'll have a look if I get a breather.
On another note, is anyone interested in a trace/debug logging default for the dry transaction program flow? Given that the shape of the data will change significantly between each operation, and not all Failure states are necessarily triggered by Exception/Error, it can be useful in DEV deployment to have more colour over what caused failures. When one can't debug locally.