Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Nikita Shilnikov
@flash-gordon
ahh, yes, this time plain merge will work better
Joe Van Dyk
@joevandyk
i'm assuming there's a way to get dry-v to pre-process that sort of thing and set a default?
Nikita Shilnikov
@flash-gordon
well, didn't see that :) you can then check for nil in a constructor block, right?
Piotr Macuk
@macuk

Hi. First of all thank you for great dry-rb gems. Dry-v is awesome! :) I have a problem. I would like to build form schema where some fields are known and some other fields should be dynamically created. I thought that I use Form.with(custom_struct: custom_struct).(params) with option within configure block [like here: http://dry-rb.org/gems/dry-validation/custom-validation-blocks/] but it doesn't work. I cannot use custom_struct inside the schema definition:

Form = Dry::Validation.Form do
  configure do
    option :custom_struct
  end

  required(:name).filled(:str?)
  required(:surname).filled(:str?)

  optional(:custom).schema do
    # error: "undefined method `each' for #<UnboundMethod:0x007f91b9978608> (NoMethodError)"
    custom_struct.each do |element|
      required(element.name)
    end
  end
end

I've found this topic [https://discuss.dry-rb.org/t/build-dry-validations-dynamically/164] in the forum but need some examples. Could you help me somehow? Thanks!

Sergey Kukunin
@Kukunin
is there a way to inherit form schema? I found I can pass basic schema via constructor Dry::Validation.Form(BaseSchema), but it requires a class there
John Backus
@backus
I've been working on a tool for checking the correctness of YARD docs and I've been using Dry::Types as my sample library. Figured I would share here :P https://github.com/backus/yardcheck
I also use Dry::Types as an example in the readme
Nikita Shilnikov
@flash-gordon
wow
AWESOME
@backus :+1:
John Backus
@backus
:D
It has been something I've wanted for a long time haha
Every time a co-worker of mine is like "I don't like documentation because it goes stale"
I'm like why is there not a tool to check
Tool is still rough around the edges but it is already very useful
John Backus
@backus
Also I have a super pedantic branch I've been working on which fixes some of these documentation things I found while testing the tool
Will PR eventually
I suggested adding a Dry::Types::Type so that a ton of the params and returns didn't have to be like
# @return [Constrained, Definition, Sum, Safe]
Nikita Shilnikov
@flash-gordon
ahh, right, this makes sense
Joe Van Dyk
@joevandyk
How do you guys typically structure your interactors/use cases, entities/value objects, etc?
Like we have a process that wants to ensure a card is charged. And another one that wants to check to see if a shipment is late. And another one that generates all types of reports.
Jeff Dickey
@jdickey
@joevandyk well, my own personal take on that would be that your first two sound like discrete use cases operating on orders, payment methods (associated with customers), and shipments (with due-date attributes); your last "all types of reports" is probably a collection of different, related use cases that each may involve different entities for input depending on the reports you're generating. That's just my take, though, without actually knowing anything about your code or domain. Work from the domain to build bounded contexts, and then inward from there
Aaron Burrow
@burrows-labs
How do I tell if my dry-validation failed or succeeded?
Do I have to look at the error messages?
Or is there some method that will give me a boolean result.
success? maybe
Tim Riley
@timriley
@burrows-labs yep, success?
David Strauß
@stravid
Good morning folks! Is there a way / interface to get all defined keys from a dry-validations schema? Currently I have a little duplication going on so I want to use the schema as source of truth:
require_relative '../../common/command'

class StartProjectCommand
  include Command

  schema do
    required(:project_id).filled(:str?)
    required(:short_name).filled(:str?)
    required(:name).filled(:str?)
  end

  attributes :project_id
  attributes :short_name
  attributes :name
end
Alexey Zapparov
@ixti
is it possible to silently overwrite previously defined attributes of dry-struct?
hanami uses code reloading in development console... which leads to Dry::Struct::RepeatedAttributeError for me
Hannes Nevalainen
@kwando
You
Oskar Szrajer
@gotar
I just wondering, why require(:foo).fillled(:int?) is valid for float, for exmaple (123.123) (just convert float to int in return but do not raise error?)
it doesn't feel right
Nikita Shilnikov
@flash-gordon
@gotar for me it's not
Dry::Validation.Schema { required(:foo).value(:int?) }.(foo: 123.123)
 => #<Dry::Validation::Result output={:foo=>123.123} errors={:foo=>["must be an integer"]}>
Oskar Szrajer
@gotar
ah I'm using Form
>> Dry::Validation.Form { required(:foo).value(:int?) }.(foo: 123.123)
=> #<Dry::Validation::Result output={:foo=>123} errors={}>
still odd for me it's vaid for Form
it should be that way? any reason behind?
Nikita Shilnikov
@flash-gordon
@gotar two reasons, Integer(123.123) #=> 123 and that you're passing a float, not a string which is normally understood when you're working with Form
because params values are strings
and for string the check doesn't pass
Integer("123.123")
ArgumentError: invalid value for Integer(): "123.123"
Oskar Szrajer
@gotar
ah ;/ sorry. unit testing against reality :p my bad. They should better reflect reality ;]
of course inside my unit tests I use numers not strings
Nikita Shilnikov
@flash-gordon
and you're not the first :)
you can stringify values with a simple preprocessor
Oskar Szrajer
@gotar
yeah