These are chat archives for dry-rb/chat

13th
Aug 2018
Jan Stevens
@JanStevens
Aug 13 2018 12:19
I have a custom validation to check for a valid email, I cannot figure out how I can set the correct error messages in I18n
configure do |config|
    config.messages_file = Rails.root.join('config/locales/en.yml')
    config.messages = :i18n

    def email?(value)
      ValidEmail2::Address.new(value).valid?
    end
  end
OrganizationSchema = Dry::Validation.Params(ApplicationSchema) do
    required(:name).filled
    optional(:email).maybe(:str?, :email?)
  end
OrganizationSchema.call(name: 'banana', email: 'cookies').messages
Dry::Validation::MissingMessageError: message for email? was not found
would be handy if the error message also include a hint to which key / thingy it tried to find or use
Igor S. Morozov
@Morozzzko
Aug 13 2018 12:23
lang:
  errors: 
    email?: your email is invalid
as per
https://dry-rb.org/gems/dry-validation/error-messages/
Though I admit it would be better if it displayed the lookup path. It isn’t going to happen until the 1.0 release, I believe
Jan Stevens
@JanStevens
Aug 13 2018 12:25
Ha but then I got conflicts in the yaml file
errors:
    email?: your email is invalid
    email?:
      filled?: "the email is missing"
Ha no thats my bad
Jan Stevens
@JanStevens
Aug 13 2018 12:37
Is there any way to customize the message based on my custom validator? For example setting a different message based on the type of error returned by ValidEmail2:Address
Jan Stevens
@JanStevens
Aug 13 2018 12:50
I guess that using simple_form + dry validations doesn't really work out of the box? full_messages_for is not defined on a Validation::Result any plans of adding support for that? Makes dry-* gems a drop in replacement
Jaromír Červenka
@Cervajz
Aug 13 2018 13:02
@JanStevens Nope, it does not. I can show you my "hack" if you're interested :)
But it's ugly
Jan Stevens
@JanStevens
Aug 13 2018 13:03
Yes that would be nice, I got a hack right now but it isn't pretty
Jaromír Červenka
@Cervajz
Aug 13 2018 13:03
:D Welcome to my world
Jan Stevens
@JanStevens
Aug 13 2018 13:04
def valid?
    validation = OrganizationSchema.call(to_hash)
    return true if validation.success?
    @errors = wrap_errors(validation.errors)
    false
  end

  class ErrorWrapper
    attr_reader :errors
    def initialize(errors)
      @errors = errors
    end

    def full_messages_for(attribute)
      errors[attribute]
    end

    def [](attr)
      errors[attr]
    end
  end

  def wrap_errors(validation_errors)
    ErrorWrapper.new(validation_errors)
  end
That's basically what I got (ha and an attr_reader :errors)
Jaromír Červenka
@Cervajz
Aug 13 2018 13:04
Hmm
Jan Stevens
@JanStevens
Aug 13 2018 13:04
that why simple form finds the attributes and show the errors under the input
Jaromír Červenka
@Cervajz
Aug 13 2018 13:04
yeah
Mine is worse
one sec
Jan Stevens
@JanStevens
Aug 13 2018 13:05
I use that valid? to mimic the typical form pattern of
 def save
    return unless valid?
    # Do stuff
  end
I use it with Dry::Transaction
I wanted to have the model (or AR logic) out of the transactions, so I handle it on the controller level
Jan Stevens
@JanStevens
Aug 13 2018 13:07
Ha I see
Pest and cholora it seems, My other idea was just extending Dry::Validation::Result with a full_messages_for method
Jaromír Červenka
@Cervajz
Aug 13 2018 13:08
But how do you then pass it to simple_form?
Can you show me that?
Jan Stevens
@JanStevens
Aug 13 2018 13:08
def new
    organization = Admin::OrganizationForm.new(client: current_event.client)
    render locals: { organization: organization }
  end

  def create
    params = organization_params.merge(client: current_event.client)
    organization = Admin::OrganizationForm.new(params)
    if organization.save
      redirect_to [:admin, current_event, :organizations]
    else
      render 'new', locals: { organization: organization }
    end
  end
Jaromír Červenka
@Cervajz
Aug 13 2018 13:08
What I do is that I "simple" add errors to the fields of AR instance
Jan Stevens
@JanStevens
Aug 13 2018 13:09
Yea I just use the form object and use it to render the form
Jaromír Červenka
@Cervajz
Aug 13 2018 13:09
Uhm
Jan Stevens
@JanStevens
Aug 13 2018 13:09
typically when I have one big for that creates 4-5 records
in my view I just do simple_form_for [:admin, organization]
Jaromír Červenka
@Cervajz
Aug 13 2018 13:09
I see
Can you show me how the OrganizationForm looks like pls?
Jan Stevens
@JanStevens
Aug 13 2018 13:10
with a include ActiveModel::Conversion in the class Admin::OrganizationForm and defining a def model_name and persited? you get there
Jaromír Červenka
@Cervajz
Aug 13 2018 13:10
How about data types of attributes?
or associations?
simple_form takes care of all of that
based on AR model
Jan Stevens
@JanStevens
Aug 13 2018 13:10
class Admin::OrganizationForm < Dry::Struct
  include ActiveModel::Conversion
  # attributes

  def save
    return unless valid?
    # Do stuff
  end

  def persisted?
    organization.present?
  end

  def model_name
    ActiveModel::Name.new(self, nil, 'Organization')
  end
end
yea that redefining the world again he...
so I have a bunch of attributes in there that mimic the underlying 3-4 models that need to be created
Jaromír Červenka
@Cervajz
Aug 13 2018 13:11
I see
I was thinking about switching to Reform, especially when I encountered accepts_nested_attributes_for which as you can see I solved with ugly piece of code :))
Reform has got Dry::Validation underneath
Jan Stevens
@JanStevens
Aug 13 2018 13:13
Yea but reform is not really that active anymore
Jaromír Červenka
@Cervajz
Aug 13 2018 13:13
o_O really?
I thought it's crucial part of Trailblazer
But I can be mistaken
Jan Stevens
@JanStevens
Aug 13 2018 13:14
Not sure but dry-* gems is moving forward quickly and last stable release of reform is: 31 Jan 2017
Jaromír Červenka
@Cervajz
Aug 13 2018 13:14
Got it
Jan Stevens
@JanStevens
Aug 13 2018 13:16
Could be its rock solid stable but a dependency thats not maintained for over a year is big warning signs for me :)
Jaromír Červenka
@Cervajz
Aug 13 2018 13:16
I agree
Cassio Godinho
@cpgo
Aug 13 2018 21:02

when injecting dependencies on dry-validation if I have something like this

  option :client, Elasticsearch.client
  option :user

and use it like Dry::Validation.Params(MySchema).with(user: Session.current_user)) my client dependency will be te value of Session.current_user and the user dependency will be nil, is this te desired behavior? I am not supposed to mix runtime dependencies with "fixed" ones?