reform: Error Message Api

Hello

According to the documentation `#errors returns validation messages in a classic ActiveModel style``

This does not seem to be completely true when using Dry Validations.

For instance errors.full_messages will generate NoMethodError: undefined method 'full_messages' for #<Reform::Contract::Errors:0x007fecf8c3f798 @errors={}>

Same happens for errors.full_message_for(:attribute).

SInce reform is planning to drop support for Active Model Validations, I think that providing a stable errors API would facilitate the migration to dry validations. WDYT ?

BR Dorian

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 6
  • Comments: 17 (5 by maintainers)

Most upvoted comments

Agreed and more so to the point that I just finished running the gauntlet on getting Reform implemented and now just fine tuning my first form that uses a collection and now dealing with errors being displayed back to the user. I’m using reform and reform-rails 2.1 with Rails 4.2.x.

When I drop in a custom validator for the collection and using errors.add(:something, 'at least one is required) it gets added first, then as the rest of the reform validations kick in they get added afterwards.

Example:

property :title
property :date

validates :title, presence: true
validates :date, presence: true
validate :validate_at_least_one_foo

collection :foos do
  property :thing1
  property :thing2
end

def validate_at_least_one_foo
  errors.add(:foos, 'at least one is required') if foos.size == 0
end

Errors as displayed to user if all are triggered:

  • Foos - at least one is required
  • Thing 1 - is required
  • Thing 2 - is required

Any thoughts on how we can control the display order of errors? Ideally, as this deals with a collection of ‘foos’ at the bottom of the UI page, its order in the error messages as displayed to the user should appear last, not first so that they can address issues from the top of the page first and work down.

FYI I jumped on to this ticket as the behavior is different from Rails handling of errors - I can created a new ticket if better?

Cheers and thanks!

For me, ideally a response would look like the example I linked in #410. I know some of that isn’t available yet from dry-validation such as the individual tokens, or being able to get errors for a collection, and its children at the same time, but the general structure gives everything.

I understand that it is way more than most need, so I would be happy if the raw validation result was exposed so that I could do whatever I want with it.

The Errors API with dry-v is still subject to change, it’ll be compatible with the one we have now!