module TargetRequests
CreateSchema = Dry::Validation.Schema(ApplicationSchema) do
required(:customer_id).filled { valid_db_id? & record_exists?(Customer) }
required(:parse_request_id).filled { valid_db_id? & record_exists?(ParseRequest) }
optional(:webhook_id).filled { valid_db_id? & record_exists?(Webhook) }
optional(:target_email_id).filled { valid_db_id? & record_exists?(TargetEmail) }
rule(target: %i[webhook_id target_email_id]) do |webhook_id, target_email_id|
webhook_id.filled? | target_email_id.filled?
end
end
end
What do you think? :)
The only thing that bothers me is the model class "hardcoded"
But that won't change that often, so it's OK I suppose
My initial idea was to somehow incorporate this:
class ApplicationSchema < Dry::Validation::Schema
configure do |config|
option :record
option :user_repository, User
option :customer_repository, Customer
option :document_repository, Document
option :document_content_repository, DocumentContent
option :vendor_repository, Vendor
option :template_repository, Template
option :source_email_repository, SourceEmail
option :parse_request_repository, ParseRequest
option :target_email_repository, TargetEmail
option :webhook_repository, Webhook
config.messages_file = 'config/locales/validations.yml'
end
...
end
Is there any way of Dry::Validation returning only the keys which are part of the schema? I was under impression that this is done automatically, especially with .to_monad extension. But it looks like I was wrong. Or maybe that was some older version as I remember it worked.
I'd like to get rid of strong params
I am looking thru the documentation and source code and can't find any option (or method on Result object) which would help me with that. Or I am blind :))
MySchema.call({i_dont_want_you: 'xxx', customer_id: 1, parse_request_id: "0266fa8b-6878-44aa-ad2e-a1d6e9dffa9d", webhook_id: 1}).to_monad
=> Success({:i_dont_want_you=>"xxx", :customer_id=>1, :parse_request_id=>"0266fa8b-6878-44aa-ad2e-a1d6e9dffa9d", :webhook_id=>1})
@Cervajz Using type specs (
config.type_specs = true) does that. see: https://dry-rb.org/gems/dry-validation/input-preprocessing/
also, it improves over time, see dry-rb/dry-auto_inject#48
@flash-gordon Please, see:
class DependencyContainer
extend Dry::Container::Mixin
register("dependency") { Object }
end
Injector = Dry::AutoInject(DependencyContainer)class MyClass
include Injector["dependency"]
def initialize(name:)
@name = name
@object = dependency.new
end
end
MyClass.new(name: "Foo")
# ArgumentError: unknown keyword: dependency
# from (pry):10:in `initialize'class MyClass2
include Injector["dependency"]
def initialize(name:, **params)
@name = name
@object = dependency.new
end
end
MyClass2.new(name: "Foo")
# NoMethodError: undefined method `new' for nil:NilClass
# from (pry):21:in `initialize'def initialize(name:, **deps)
super(deps)
@name = name
@object = dependency.new
end
And maybe you can give me some examples of use-cases of
dry-initializer in compare with dry-struct?
I find out that I need use this gems for objects of different purposes. But what does it mean technically?
and
dry-struct is ADT in ruby, basically
that is plain structures or combinations via sums
I don't have custom constructors for structs, it would feel wrong
Where is the source to the documentation and how can I contribute to it?
@flash-gordon cool, thanks.
@flash-gordon fwiw, there is an issue with the dry-initializer doc, I believe (last example of the type-constraints section: https://github.com/dry-rb/dry-rb.org/blob/master/source/gems/dry-initializer/type-constraints.html.md
@nepalez ^^ I think location shall be an option and not an param in that last example. And also the naming "param" is weird for the first reader. It assumes some knowledge about the second argument. Arguably it could be named "this_param" for clarification (or something like that).
thanks.
not to take away from the awesomeness; anything that lets devs use their favourite/existing-products' languages in new ways is almost by definition a Good Thing
Hi, I've been thinking about opening a pull request for dry-struct to make it quack a bit more like a hash in order to enable validating it with dry-validation. Nowadays an attempt to call a schema with a struct object throws an error. I don't understand if this is a conscious design decision because it seems like a useful use case.
What I want to enable is this:
schema = Dry::Validation.Schema { required(:age).filled(gteq?: 18) }
User.new(age: 17)
schema.(user)
#<Dry::Validation::Result output=#<User age=17> errors={:age=>["must be greater than or equal to 18"]}>