Add ActiveModel::Errors#details #18322
Conversation
| message.to_sym | ||
| end | ||
|
|
||
| { code: code }.merge(options.except(*CALLBACKS_OPTIONS + MESSAGE_OPTIONS)) |
There was a problem hiding this comment.
Why return code as key? If we are requesting the codes and we are getting only the codes there is no need for this key.
There was a problem hiding this comment.
Ah, we also return other options. Got it. So I'd not call this method codes. But I can't think in a better name right now.
|
I'm not sure I understand what the |
|
There are validators that have additional parameter If you think that those can be omitted, it would simplify returned structure to |
|
I think that structure would be much nicer. And I like model.errors.to_hash to produce this.
|
|
There is already implemented Actually, when there are no additional attributes like |
|
Hmmm. Not in love with codes either, but can't come up with a better name off the top of my head either. |
|
(Like slugs even less, though) |
|
I changed it to flat structure without extra attributes. |
|
May be |
|
Reasons could just as well be a full message rather than just a symbol. I say codes is reasonable in the absence of something better.
|
|
I will work on changes in documentation. We should encourage to adding errors via |
|
@zzak is it possible to document |
|
For what I got from the original discussion is that this feature is to make possible to return these codes as API response and the clients are responsible to show its messages to the users. But just returning the code would not make this behavior possible for error messages that needs dynamic values, this is why the If I got the discussion correctly, we need to think a way to return these attributes. |
|
Yeah, I think the deeply nested hashes are necessary for this to be useful. I suggest AFAICS, none of the |
|
I'd like just to confirm what @rafaelfranca and @matthewd said - deeply nested hashes are necessary, as otherwise it won't we possible to display dynamic messages like: "Password needs to have at least 8 characters". The list of all built-in validations that use |
|
I added back deep hash structure with custom options. |
|
|
|
Additionally I think we could change initializing user = User.new
user.errors.get(:email) #=> nil
user.errors[:email] #=> []
user.errors.get(:email) => [] |
|
@morgoth is worth to try, but I think this is a separated PR. |
|
sure, I will try to do some refactoring after this is merged |
morgoth
force-pushed
the
add-error-codes
branch
from
52bc271 to
a578e68
Compare
|
How about one of |
|
I think keys is too close to Hash#keys which is not what we’re returning. I think “error code” is a pretty well-established term that we’d do well to follow in this case.
|
|
What about
|
|
Both those are used in other contexts too. The only alternative I’ve heard so far that’s worth considering is #symbols, but I don’t think it’s worth the bike-sheeding at this point. #codes is Good Enough.
|
|
Can we all agree on one naming? I already changed documentation examples, so it would be the last change in this PR. |
|
#codes. Done. |
|
Actually, fuck it. It doesn't matter. Details is fine. This is not nearly important enough to warrant the back'n'forth. |
|
I know that you don't like pinging on pull requests. |
|
@morgoth what happen now if people do? errors.add(:name, "can't be blank") |
|
@rafaelfranca it will work in the same way as currently, but the code hash will look like: |
|
The patch seems good. Lets change the guides about it in the same PR. |
To be able to return type of validator, one can now call `details`
on Errors instance:
```ruby
class User < ActiveRecord::Base
validates :name, presence: true
end
```
```ruby
user = User.new; user.valid?; user.errors.details
=> {name: [{error: :blank}]}
```
morgoth
force-pushed
the
add-error-codes
branch
from
e85526c to
cb74473
Compare
|
@rafaelfranca I added information about using |
Add ActiveModel::Errors#codes
|
will this be included in an upcoming rails 4 version aswell or only in rails 5? |
|
@marczking It will be in Rails 5 only. In the meantime you can use https://github.com/cowbell/active_model-errors_details which backports this feature |
|
thanks @morgoth , this is great :) |
Mirror the documented new behavior of including details, when performing errors test.
|
Thanks this is awesome ! I think details could contain more information, like a fully detailed object of what happened. class File < ActiveRecord::Base
validates_inclusion_of :format, in: %w(jpg png)
validates_length_of :name, maximum: 10
end
file = File.create(format: 'pdf', name: 'Too long file name')
file.errors.details[:format]
# => {error: 'inclusion', value: 'pdf', in: ['jpeg', 'png'], message: 'is not included in the list'}
file.errors.details[:name]
# => {error: 'too_long', count: 18, maximum: 10, message: 'is too long (maximum is 10 characters)'}This would really help on making simple errors for apis: For example with json.error :validation_failed
json.message 'The record is not valid'
json.errors file.errors.detailsWould render: {
"error": "validation_failed",
"message": "The record is not valid",
"errors": {
"format": [
{
"error": "inclusion",
"value": "pdf",
"in": ["jpeg", "png"],
"message": "is not included in the list"
},
],
"name": [
{
"error": "too_long",
"count": 18,
"maximum": 10,
"message": "is too long (maximum is 10 characters)"
}
]
}
}For now I have to do this manually. What do you think? |
To be able to return type of validator, one can now call
detailson Errors instance:
The first attempt was to return structure similar to messages, like:
{name: [:invalid, :blank]}, but there was problem with missing additional options such as:countin some validators.If the idea is accepted I will add documentation and changelog.
There is ongoing discussion on https://groups.google.com/forum/#!topic/rubyonrails-core/0lxM684Tqas