Worth a watch if anyone hasn't seen it yet
I wouldn’t want dry-component to turn into a highly customizable object construction framework
some of them is rather app specific though
personally I’m not interested in such a thing
and did you try to use it in a rails app or dry-web stack or something else?
but this would be external, so dry-component would have its own simple one (the existing stuff) and you could configure your own
lol
this was a deal breaker for me
nobody had the time to take care of this, that’s all
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.
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 }
in
Types module you have a clash with Types::DateTime constant
@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)
