Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Tim Riley
@timriley
Hmm, right
Yeah, I get this
(The role of the container to connect things)
Piotr Solnica
@solnic
it’s gonna be really cool to build a tool that looks at your setup and generates a visual representation of what happens when a request comes in :D
rack middlewares => final routing end-point => application end-point => specific objects that process data => perrsistence operations => db result => app result => http response
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 =)
Andy Holland
@AMHOL
http://confreaks.tv/videos/railsconf2016-get-a-whiff-of-this
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...