Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
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 :)
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
no
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
Aaron Barthel
@abrthel
Dry-transaction's naming is a bit weird to me but think of it like a process instead of a database transaction. The idea is you create a transaction object that has all the steps needed to handle a process. Then you reuse that transaction object again and again and the only difference is what input you've given it.
So each step would be a pure function that doesn't hold state and acts on the input and returning everything needed in the output
Jaromír Červenka
@Cervajz
@abrthel Thanks. so we have the same understanding :c) Input => Output and that's it.
Aaron Barthel
@abrthel
as for causing a side effect, well yeah you definitly have to store something to a database or where ever but you don't want your transaction object holding state.
Jaromír Červenka
@Cervajz
module ApiTokens
  class Create
    include Dry::Transaction

    step :validate
    step :persist
    step :regenerate_token

    def validate(input)
      validation = ApiTokenSchema.call(input)
      validation.success? ? Success(input) : Failure(validation.errors)
    end

    def persist(input)
      api_token = ApiToken.new(input)
      api_token.save ? Success(api_token) : Failure(api_token.errors)
    end

    def regenerate_token(api_token)
      api_token.regenerate_token!
      Success(api_token)
    end
  end
end
This is my testing class ^^ Should be as you described
The only side-effect is the DB one
Aaron Barthel
@abrthel
Seems fine to me
Jaromír Červenka
@Cervajz
Thanks! :c)
Aaron Barthel
@abrthel
np :smile: