These are chat archives for dry-rb/chat

21st
Sep 2017
Alfonso Uceda
@AlfonsoUceda
Sep 21 2017 06:59

Hi folks! I need advise related to one behaviour with dry-validations in this issue hanami/validations#131, as you know we use dry-validation in hanami-validations.

It seems when you build something like:

required(:user).filled.schema  { … }

it doesn’t filter very well nested params inside (:user), but if you use:

required(:user).schema  { … }

it filters the params, I think the user is using wrong the DSL but can it be a bug?

Piotr Solnica
@solnic
Sep 21 2017 08:16
@AlfonsoUceda it's a limitation, chaining is not supported, and unfortunately we don't raise an error when somebody tries to do that
I'll be working on improving this in dry-v 1.0
Alfonso Uceda
@AlfonsoUceda
Sep 21 2017 08:20
thank you so much @solnic
Rafael George
@cored
Sep 21 2017 14:48
is there a way for me to force floor for a coercible float type?
I'm getting in some cases 0.01 for a price which should be 0.00 so I was wondering if I could do something like Types::Coercible::Float.floor
Alexander Chernik
@achernik
Sep 21 2017 16:11
Hi, I'm trying out dry-system, and struggling to understand the need for use method in definitions of finalizers. Resolving component boots it, so it seems that use :redis is not needed. What purpose does it serve?
Here's my code:

App::Container.finalize(:redis) do |container|
  start do
    require 'redis'
    redis = Redis.new(url: ENV['REDIS_URL'])
    container.register(:redis, redis)
  end
end

App::Container.finalize(:cache) do |container|
  start do
    require container.root.join('lib', 'redis_cache')

    # use :redis

    cache = RedisCache.new(container['redis']) # boots :redis component
    container.register(:cache, cache)
  end
end
Rafael George
@cored
Sep 21 2017 18:15
is this even possible
Nikita Shilnikov
@flash-gordon
Sep 21 2017 18:32
@cored right, but you need to replace do ... end with { ... }, otherwise the block will be passed to the attribute method
Rafael George
@cored
Sep 21 2017 18:39
oh
nice
thanks
does it make sense to wrap types that have custom constructor with specific type naming
in this case I would have a PurchasePrice type in my Types module definition
does that make sense?
Nikita Shilnikov
@flash-gordon
Sep 21 2017 18:40
it depends, you should try :)
Rafael George
@cored
Sep 21 2017 18:40
yes, totally will try that
I'm fascinated by the fact that extracting new types/structs from a particular class remove the entire class and the rules/logic is now specific to a particular type
like for instance that coercion will remove an if statement
Nikita Shilnikov
@flash-gordon
Sep 21 2017 18:43
yeah, we can have more complex type constructors than even in statically compiled languages, although people used to solve such problems with a function there
and in ruby we don't have functions but we can emulate them, sooo it works
Rafael George
@cored
Sep 21 2017 18:44
interesting
looks like this approach won't work
is Float type wrapping a BigInt ?
Nikita Shilnikov
@flash-gordon
Sep 21 2017 18:45
wdym by that? Float is equal to calling Kernel::Float(value)
coercible.float I mean
Rafael George
@cored
Sep 21 2017 18:46
got it
I think for this particular case I need Decimal type
because the older code looks like this
def purchase_price_properties(item)
      { purchase_price_per_each: BigDecimal.new(purchase_price(item)) }
    end

    def purchase_price(item)
      if item.xpath('purchaseprice').text == "0.01"
        "0.00"
      else
        item.xpath('purchaseprice').text
      end
    end
as you can see it uses a BigDecimal so the right type for this case would be Decimal
however looks like sometimes I'll get "0.01" from the input data
Nikita Shilnikov
@flash-gordon
Sep 21 2017 18:52
@cored it's better not to use Float when you're working with money :grin:
Rafael George
@cored
Sep 21 2017 18:52
yeap
I made a mistake on that
switched to Decimal now
but still I'll have the same problem
I can't floor the value
so I need to research on why in some context we are getting "0.001"