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)
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
andreform-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:
Errors as displayed to user if all are triggered:
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!