Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Aug 12 14:30
    SmithWebDev starred dry-rb/dry-system
  • Aug 12 13:28
    ParamagicDev starred dry-rb/dry-system
  • Aug 12 08:09
    flash-gordon commented #442
  • Aug 12 08:06
    solnic commented #442
  • Aug 12 08:06
    solnic commented #442
  • Aug 12 07:59
    flash-gordon commented #442
  • Aug 12 01:40
    hiendinhngoc starred dry-rb/dry-initializer
  • Aug 11 23:47
    robhanlon22 commented #442
  • Aug 11 09:38

    flash-gordon on main

    Ignore compat.rb in Zeitwerk lo… Add more paths to loader exclus… Add spec to test eager loading and 1 more (compare)

  • Aug 11 09:38
    flash-gordon closed #444
  • Aug 11 09:38
    flash-gordon commented #444
  • Aug 10 18:40
    robhanlon22 synchronize #444
  • Aug 10 18:39
    robhanlon22 edited #444
  • Aug 10 18:39
    robhanlon22 edited #444
  • Aug 10 18:36
    robhanlon22 edited #444
  • Aug 10 18:36
    robhanlon22 edited #444
  • Aug 10 18:36
    robhanlon22 synchronize #444
  • Aug 10 18:11
    robhanlon22 commented #444
  • Aug 10 18:11
    robhanlon22 review_requested #444
  • Aug 10 18:11
    robhanlon22 opened #444
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.
Spencer Goh
@dymaxionuk
I have an issue with an intermittent failure in a test, which doesn't manifest locally but only on the CI server. The output of roda flow driven dry transaction is returning a monad with True class as value. The only logging is the final backtrace in the router. But I would be useful to see the data and program flow along the whole execution path of the transaction, into it returns to route
70% of the time it returns my intended value object ... I can track it down but might be nice to have a trace feature. Any other use cases other people have across like this? Do you just add a ton of hand crafted logging manually?
Maybe option trace_transaction, true
Gustavo Caso
@GustavoCaso
I'm not a very experience dry-validations user but I wanted to share a question regarding some bahaviour I found for error messages
Having this schema
BusyPeriods = Dry::Validation.Schema do
  each do
    schema do
      required(:start_date).filled(:date?)
      required(:end_date).filled(:date?)
      required(:utilisation).filled(:int?)

      rule(started_before_ended: [:start_date, :end_date]) do |start_date, end_date|
        end_date.gt?(value(:start_date))
      end
    end
  end
end
If I try to validate some data if the error is related with the required attributes I will get a message with the format { index => error_message } but if the error comes from the rule I will get just the error with out the index. Is that expected?
{0=>{:utilisation=>["must be an integer"]}}
{:started_before_ended=>["must be greater than 2018-03-21"]}
Piotr Solnica
@solnic
@GustavoCaso end_date.gt?(start_date)
Gustavo Caso
@GustavoCaso
Thanks @solnic