Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 18 21:30
    ArtemRakov starred dry-rb/dry-monads
  • Feb 18 16:10
    marselmustafin starred dry-rb/dry-monads
  • Feb 18 09:52
    preetsethi starred dry-rb/dry-initializer
  • Feb 17 23:12
    Karnaj starred dry-rb/dry-types
  • Feb 17 23:12
    Karnaj starred dry-rb/dry-monads
  • Feb 16 23:37
    asoules starred dry-rb/dry-system
  • Feb 16 20:37

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:37

    flash-gordon on master

    Update CHANGELOG (compare)

  • Feb 16 20:36

    flash-gordon on v1.3.1

    (compare)

  • Feb 16 20:34

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:33

    flash-gordon on master

    Fix version number (compare)

  • Feb 16 20:32

    dry-bot on master

    [devtools] sync (compare)

  • Feb 16 20:32

    flash-gordon on master

    Update CHANGELOG (compare)

  • Feb 16 20:27

    flash-gordon on master

    Bump version to 1.3.1 (compare)

  • Feb 16 20:26

    flash-gordon on impove-predicate-inferrer

    (compare)

  • Feb 16 20:26

    flash-gordon on master

    Infer hash? predicate for hash … Merge pull request #395 from dr… (compare)

  • Feb 16 20:26
    flash-gordon closed #395
  • Feb 16 20:26
    dry-bot commented #395
  • Feb 16 20:24
    flash-gordon opened #395
  • Feb 16 20:23

    flash-gordon on impove-predicate-inferrer

    Infer hash? predicate for hash … (compare)

Oskar Szrajer
@gotar
NewRelic^2 ;]
Piotr Solnica
@solnic
right, this would be taken to the next level
esp with monitoring capabilities
Tim Riley
@timriley
Oh man, Michael at Icelab would love this
Piotr Solnica
@solnic
:)
Oskar Szrajer
@gotar
idea for product - $$$
Hannes Nevalainen
@kwando
@timriley more customizable / less restrictive auto_registration for dry-component would be nice, read that you were going to spend some quality time with dry-component =)
Worth a watch if anyone hasn't seen it yet
Piotr Solnica
@solnic
@kwando if you don’t like default behavior just register your objects yourself
I wouldn’t want dry-component to turn into a highly customizable object construction framework
Hannes Nevalainen
@kwando
@solnic I already got my own registration strategies
some of them is rather app specific though
Maciej Mensfeld
@mensfeld
@solnic will there be a strict mode for dry-validations? I mean now I can pass a field that I haven't declared and it is there
Piotr Solnica
@solnic
yes there will be a predicate which checks that
Maciej Mensfeld
@mensfeld
I really need that for what I do ;) (and all the other magic you guys work on :D)
Piotr Solnica
@solnic
@kwando this is not a DI/IoC framework and it won’t be, for complex object construction strategies we could create an interface for integration with external libs that handle that
personally I’m not interested in such a thing
Hannes Nevalainen
@kwando
well, I ditched dry-component and rolled my own instead
Piotr Solnica
@solnic
is it OSS?
and did you try to use it in a rails app or dry-web stack or something else?
Hannes Nevalainen
@kwando
no it is not, it will be if I ever get to extract it from this app though =)
Piotr Solnica
@solnic
we can have a way of registering custom handlers
but this would be external, so dry-component would have its own simple one (the existing stuff) and you could configure your own
Hannes Nevalainen
@kwando
really enjoying how omakase the dry ecosystem is =)
Piotr Solnica
@solnic
yeah man it’s omakase and you consume it with really sharp knifes :laughing:
Hannes Nevalainen
@kwando
:laughing:
lol
Nikita Shilnikov
@flash-gordon
it would be great if dry-component supported namespaces. This PR seems to be abandoned dry-rb/dry-component#6 :(
this was a deal breaker for me
Piotr Solnica
@solnic
@flash-gordon it will support it
nobody had the time to take care of this, that’s all
Chase Gilliam
@Ch4s3
I'm hitting a place where dry-validation-rails is going to be very useful soon. Where are we in that discussion?
Oskar Szrajer
@gotar
it's only me, who have odd feeling when every gem need another one with -rails to support it, why not to just use dry-validation ?
Chase Gilliam
@Ch4s3
I understand the sentiment. I think the idea was to give rails users an easier on-ramp for dry-rb, but I think @solnic can explain the rationale much better
Nikita Shilnikov
@flash-gordon
@solnic that's why I mentioned it ;) Personally I didn't do anything about it because I don't know how it should be implemented
Piotr Solnica
@solnic
Rails needs integration. And I don't want it to be part of main code bases
Chase Gilliam
@Ch4s3
I'm trying to build something in my application and see if I can extract a sensible integration...
I'm including a dry-validation schema class on my models and checking it before saving. It works, but I'm not sure how happy I am with it.
Jeff Dickey
@jdickey
Hi, guys; I'm having trouble with a Types::Strict::DateTime initialisation. When I use the "raw" Gem-supplied types to define everything, all is well; when I use a self-defined module constant, I get a NoMethodError running what looks like the exact same code. Gist with short single-source-file demo code here
Initialising with DateTime.now works when using Types::Strict::DateTime.default { DateTime.now }; it does not work when attempting to use a constant defined as Types::Strict::DateTime.default { DateTime.now }
Nikita Shilnikov
@flash-gordon
@jdickey try DateTimeOrNow = Types::Strict::DateTime.default { ::DateTime.now }
in Types module you have a clash with Types::DateTime constant
Piotr Solnica
@solnic
@rusilko heyyy sorry for this late reply, so in a nutshell: let's start with strong-params replacement, this is basically a schema that defines which keys are required and optional and what the types should be. Once we have that, along with some railitie that sets things up for you, we can think about what to do with model validation, I think the next natural would be to move validation out from AR models and provide some smooth integration with AM (although that is, IIRC, covered by gems like reform, so maybe makes no sense to go that far). All this stuff should go to a separate gem dry-validation-rails which provides Dry::Validation::Rails namespace with all the needed APIs. /cc @Ch4s3
oh and yes, we could create a separate channel for dry-validation, it's probably the biggest gem we have with adoption growing fast...
@gotar apologies for my rough reply, I was...driving :P anyhow, re keeping rails stuff separate - this will speed up development, ie I don't use rails (I guess you know that already :)) so I don't want to deal with rails-related code when working on OSS, that's pretty much it, it adds friction to dev cycles that I really don't like, and don't have time/energy to deal with this
one minor benefit is also that it screams "look how many gems need rails-specific code just to make them usable with rails"
at least I see some value in this kind of manifestation (maybe not the right word)
Ralf Schmitz Bongiolo
@mrbongiolo
@mensfeld I'm not sure if I understood you correctly, but for what you what you should use the Sanitizer input_processor, it will ignore any fields that are not declared in your schema.
configure do
  config.input_processor = :sanitizer
end
Tomek Rusiłko
@rusilko
@solnic hey, no probs. Thanks for clarifing things. So, pls set up a channel and lets start hacking away on it :) cc/ @Ch4s3