dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

Gustavo Caso

@GustavoCaso

I think this will do the trick

class User < Dry::Struct
  transform_types do |type|
    type.meta(omittable: true)
  end

  attribute :name, Types::Strict::String
  attribute :age,  Types::Strict::Integer.default(18)
end

Please let me know if that solved the problem

Damien Timewell

@idlefingers

Ahaaaa, I get it. It works! Perfect, thanks a ton for your help @GustavoCaso :)

Gustavo Caso

@GustavoCaso

My pleasure :smile:

Damien Timewell

@idlefingers

Hmmm, but now the meta is included in Hash values :/ ...

class User < Dry::Struct
  transform_types do |type|
    type.meta(omittable: true)
  end

  attribute :foo, Types::Hash.default(Hash.new)
end

User.new.foo # => {:meta=>{:omittable=>true}}

Gustavo Caso

@GustavoCaso

class User < Dry::Struct
  transform_types do |type|
    type.optional
  end

  attribute :name, Types::Strict::String
  attribute :age,  Types::Strict::Integer.default(18)
end

Could you try that one?

Damien Timewell

@idlefingers

That just means it can be nil, but the key is still required, right?

Dry::Struct::Error: [User.new] :name is missing in Hash input

Gustavo Caso

@GustavoCaso

You can set a deafult value if what you are looking is for avoid the meta

Does it helps you? @idlefingers

Damien Timewell

@idlefingers

I'm not sure I follow. In the example class I pasted above, I set the default to be a new hash, but when the class is initialized, that hash includes became {:meta=>{:omittable=>true}}

so instead of User.new.foo # => {:meta=>{:omittable=>true}} I'm trying to get User.new.foo # => {} (which is what constructor_type :schema did before)

Gustavo Caso

@GustavoCaso

All your attributes are hashes?

class User < Dry::Struct
  transform_types do |type|
    type.optional.deafult({})
  end

  attribute :foo, Types::Hash
end

Damien Timewell

@idlefingers

No, they could be anything

Gustavo Caso

@GustavoCaso

I think this will do trick for that case you mentioned

Damien Timewell

@idlefingers

I don't think that will work :( It needs to be able to handle any type

Gustavo Caso

@GustavoCaso

@idlefingers how about this to avoid the extra meta attribute

class User < Dry::Struct
  transform_types do |type|
    if type.default?
      type
    else
      type.meta(omittable: true)
    end
  end
  attribute :foo, Types::Hash.default({})
  attribute :bar, Types::String
end

User.new
=> #<User foo={} bar=nil>

Damien Timewell

@idlefingers

nice! Seems to work. Will test around some more

Gustavo Caso

@GustavoCaso

Sure let me know if you need anything

Damien Timewell

@idlefingers

thanks

Gustavo Caso

@GustavoCaso

your welcome

Nikita Shilnikov

@flash-gordon

this looks like a bug to me, something's not quite right with defaults where

Gustavo Caso

@GustavoCaso

@flash-gordon I'm happy to have a look

Gustavo Caso

@GustavoCaso

@idlefingers I have open a PR fixing the issue dry-rb/dry-types#250

Damien Timewell

@idlefingers

Awesome @GustavoCaso. So with that change, this should work?

transform_types do |type|
  type.meta(omittable: true)
end

Gustavo Caso

@GustavoCaso

It should work I will try running more test with dry-struct

Damien Timewell

@idlefingers

:thumbsup:

Gustavo Caso

@GustavoCaso

but if you want to try and let me know that would be great

Nikita Shilnikov

@flash-gordon

I wouldn't call meta on defaults anyway, it doesn't make sense to me

@idlefingers don't forget, you can create a base class if you don't want to call transform_types many times

Damien Timewell

@idlefingers

@flash-gordon that's exactly what led me down this path :)

https://github.com/iZettle/api-blueprint/commit/c0adae89cdf859f5da3c3c7206b9834315661bfd#diff-3b508d340ef84e8f63319e83336423a1R1

since it's an api wrapper I'm building, it's very hard to be sure all expected attributes are in responses, so I needed to make it a little less strict (constructor_type :schema style :P )

Nikita Shilnikov

@flash-gordon

yeah, it was always hard to control the desired behavior with constructor_type, now it's crystal clear

Damien Timewell

@idlefingers

:+1: it was a little confusing before. Much prefer the new approach, even if my implementation was a bit of a rocky road

Daniel Sandbecker

@daniels

In Dry::Struct, can a default value depend on the value of another attribute?

Nikita Shilnikov

@flash-gordon

however, you can override the constructor

Daniel Sandbecker

@daniels

Ok. Thanks, that was quick.

Grant Shangreaux

@gcentauri

hm, did the little pop-up window just tell me i shouldn't ask user questions here? i'm new to dry and very excited about getting it into my development at work

Dean Chuang

@bluekites

Hello, I have a question about dry-validation. I want to be able to validate an array and that the elements within the array are integers. I also would like to be able to accept an empty array. Currently I have something something that looks like this optional(:group_ids, [:int]).value(:array?) but am having trouble figuring out how the element validation would work. Any advice?

Jaromír Červenka

@Cervajz

Hi guys :) I am learning (and trying to implement) dry-transaction, I am going thru the Introduction and found this:
Each operation shouldn’t accumulate state, instead it should receive an input and return an output without causing any side-effects.

What do you mean by that? Especially this part without causing any side-effects?

I understand that I should not keep some state across operations on the "transaction class" level, but isn't "causing side-effect" a natural outcome of an operation?

Thanks in advance for clarifying

Where communities thrive

People

Repo info

Activity