Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 07 14:03

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 10:01
    Travis dry-rb/dry-view (master) errored (636)
  • Dec 07 09:58
    Travis dry-rb/dry-view (master) errored (635)
  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:56

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:54

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:54

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:54

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:54

    dry-bot on master

    [devtools] config sync (compare)

  • Dec 07 09:54

    dry-bot on master

    [devtools] config sync (compare)

Gustavo Caso
@GustavoCaso
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:
Jaromír Červenka
@Cervajz
Is there a way where I could catch failed operations and revert them? Or is that out of the scope?
For example, if the last step would fail, I'd like to delete the record from DB.
Aaron Barthel
@abrthel
it's been awhile since I've used dry transaction but I do seem to remember there was a way to handle the failed branch.
As for deleting a record from the DB I imagine a much safer method would be wrapping the transaction in a DB transaction using 'around steps'
Jaromír Červenka
@Cervajz
Got it, I am going to look in to that, thanks
Jonah
@jonahx
Curious if anyone here has used this gem and, if so, what you thought of it: https://github.com/egonSchiele/contracts.ruby
Aaron Barthel
@abrthel
That's ironic, just looked at this gem like 20 minutes ago. Personally I like to do something like https://silkandspinach.net/2011/05/23/contract-tests-in-rspec/ instead of a contracts gem