These are chat archives for dry-rb/chat

30th
May 2018
Roland Laurès
@ShamoX
May 30 2018 08:50
@GustavoCaso Hi again, it seems that my problem is coming from the fact I validate my arrays like this :
  required(:architecture).filled(:array?).each do
    schema(RequestRoom.validation_schema)
  end
  required(:interconnections).each do
    schema(Interconnection.validation_schema)
  end
(this is inside the Form do end block
the first one (:architecture) will fail only if the architecture field is not filled.
If the field exist and it is an array, it is enough to validate (it seems)
It seems that in that case, RequestToom.validation_schema validation is not called on the data.
I try to make a consistent example that show the bug (maybe it is a behavior :D)
Roland Laurès
@ShamoX
May 30 2018 09:00
nested_schema = Dry::Validation.Schema do
  required(:name).filled(:str?)
end

global_schema = Dry::Validation.Schema do
  required(:working_array).each { schema(nested_schema) }
  required(:notworking_array).filled.each { schema(nested_schema) }
end

invalid_input = {
  working_array: [{ not_name: 'test' }],
  notworking_array: [{ not_name: 'test' }]
}

result = global_schema.call(invalid_input)

puts "notworking_array in error? #{result.errors.include?(:notworking_array)}"
puts "working_array in error? #{result.errors.include?(:working_array)}"
I probably miss use .filled or .value predicates.
Roland Laurès
@ShamoX
May 30 2018 09:05
But in my understanding it should be an 'and' logic. Because I also want the fields not to be nil.
Ok, I read back the doc : http://dry-rb.org/gems/dry-validation/nested-data/ and it was not clear to me that each would also validate not nil field.
global_schema.call(working_array: nil, notworking_array: nil)
=> #<Dry::Validation::Result output={:working_array=>nil, :notworking_array=>nil} errors={:working_array=>["must be an array"], :notworking_array=>["must be filled"]}>
global_schema.call(working_array: nil, notworking_array: nil).errors
=> {:working_array=>["must be an array"], :notworking_array=>["must be filled"]}
they are both invalidated, but not the same way.
Gustavo Caso
@GustavoCaso
May 30 2018 09:09
Yep
I was playing with your example
Roland Laurès
@ShamoX
May 30 2018 09:09
Then I just have to fix all my array required field declaration
Gustavo Caso
@GustavoCaso
May 30 2018 09:10
If you want to check that they are Array use the each method
Jonah
@jonahx
May 30 2018 12:35
is it considered bad practice to add methods to Dry::Struct objects? Eg, methods like to_json that would format the structured data object as a json string?
Andy Holland
@AMHOL
May 30 2018 15:46
@jonahx I'd add a serializer object for that
I don't think an object should be responsible for the way it is presented, context-specific presenters is the way to go IMO
Jonah
@jonahx
May 30 2018 15:47
@AMHOL meaning a serializer that delegates to the Dry::Struct rather than adding the method to Dry::Struct itself?
Andy Holland
@AMHOL
May 30 2018 15:47
@jonahx yeah
i.e. the Dry::Struct instance would be passed to #call or #serialize or whatever
Jonah
@jonahx
May 30 2018 15:48

I don't think an object should be responsible for the way it is presented, context-specific presenters is the way to go IMO

I agree in general, but I’m a bit torn in this case because the presentation is essentially the sole use of the object

but ty, you’ve answered my question
Andy Holland
@AMHOL
May 30 2018 15:53
:+1: NP (BTW I'm talking in an ideal world, sometimes it's easier to just stick it in a #to_json method and have done with it for a simple application, and think about it later if necessary)
Jonah
@jonahx
May 30 2018 15:56
:thumbsup:
Nikita Shilnikov
@flash-gordon
May 30 2018 16:16
:+1: to @AMHOL
ojab
@ojab
May 30 2018 16:49
Is there any way to check base type for another type?

i. e. in case

t = Dry::Types['integer']
optional_t = t.optional

is there any way to check that optional_t is t?

Gustavo Caso
@GustavoCaso
May 30 2018 16:55
Are you talking like optional_t === t
ojab
@ojab
May 30 2018 16:56
> optional_t === t
=> false
Gustavo Caso
@GustavoCaso
May 30 2018 16:56
because they are not the same
ojab
@ojab
May 30 2018 16:57
yeah, I want to check that type is derived from another type
something like
expect(optional_t).to be_derived_from(t)
Nikita Shilnikov
@flash-gordon
May 30 2018 16:58
it is possible via type compiler but this is rather advanced
I doubt you would to it
https://github.com/dry-rb/dry-struct/blob/master/lib/dry/struct/struct_builder.rb this is a pretty simple example of using it in dry-struct
ojab
@ojab
May 30 2018 16:59
thank, will take a look
Nikita Shilnikov
@flash-gordon
May 30 2018 17:00
but we don't expose is it as a public API
but if cover your implementation with tests, you should be fine
ojab
@ojab
May 30 2018 17:02
so .to_ast output is not meant to be stable and may change in new versions?
Nikita Shilnikov
@flash-gordon
May 30 2018 17:06
yes
like all of dry-types until it reaches 1.0
but it's pretty stable nowadays, I would even push 1.0 already but we decided to hold on the release until Hanami 2.0 is here
ojab
@ojab
May 30 2018 17:38
Dry::Types['coercible.string'].default('qwe')[nil]
 => ""
is it expected behaviour?
Nikita Shilnikov
@flash-gordon
May 30 2018 17:39
it is
[23] pry(main)> String(nil)
=> ""
nil doesn't trigger default values
it did in previous version but now it doesn't
you can use Dry::Types::Undefined as a replacement
ojab
@ojab
May 30 2018 17:40
Dry::Types::Undefined?
yep
Gustavo Caso
@GustavoCaso
May 30 2018 17:42
so Dry::Types['coercible.string'].default('qwe')[Dry::Types::Undefined]