-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature request: support for "catch all" error in val-default-errors #264
Comments
Hi @david-bulte Thanks for your issue. Even though we think, that, to have a better UX, specific error messages are better than a generic message, we also agree that this use-case can be useful, at least to display a generic error rather than nothing at all if an unexpected or forgotten validation error happens on a control. We think however that it would probably be clearer and simpler to introduce an additional directive. The code would look like this, inside <ng-template valDefaultError let-label><span>{{ label || 'this field' }} is invalid</span></ng-template> If the If one chooses to display all the errors, the message for Does that suit your expectations? I think this should also address your request in #265 (see discussion in this issue for details) |
I chose to design it the following way - name it valFallback instead of valDefaultError, to avoid confusion with the default-validation-errors directive - expose the label, the error, and the type of the error to the fallback template - if the display mode is ALL, then all the errors are displayed. So if two or more errors are not handled by specific error directives, the fallback template is displayed several time. I expect this to rarely happen. But it allows using the error type as an i18n key to display all the errors the same way. If the fallback is used to handle forgotten error types, then it will at least make it clear that several types have been forgotten. - if the display mode is ONE, then the fallback template is only displayed once, if no error is handled by a specific error directive. Since there might be several errors handled by the fallback, the order is undefined, and we thus have no guarantee over which of the error will be displayed. fix #264
I chose to design it the following way - name it valFallback instead of valDefaultError, to avoid confusion with the default-validation-errors directive - expose the label, the error, and the type of the error to the fallback template - if the display mode is ALL, then all the errors are displayed. So if two or more errors are not handled by specific error directives, the fallback template is displayed several time. I expect this to rarely happen. But it allows using the error type as an i18n key to display all the errors the same way. If the fallback is used to handle forgotten error types, then it will at least make it clear that several types have been forgotten. - if the display mode is ONE, then the fallback template is only displayed once, if no error is handled by a specific error directive. Since there might be several errors handled by the fallback, the order is undefined, and we thus have no guarantee over which of the error will be displayed. fix #264
I chose to design it the following way - name it valFallback instead of valDefaultError, to avoid confusion with the default-validation-errors directive - expose the label, the error, and the type of the error to the fallback template - if the display mode is ALL, then all the errors are displayed. So if two or more errors are not handled by specific error directives, the fallback template is displayed several time. I expect this to rarely happen. But it allows using the error type as an i18n key to display all the errors the same way. If the fallback is used to handle forgotten error types, then it will at least make it clear that several types have been forgotten. - if the display mode is ONE, then the fallback template is only displayed once, if no error is handled by a specific error directive. Since there might be several errors handled by the fallback, the order is undefined, and we thus have no guarantee over which of the error will be displayed. fix #264
@david-bulte I've published version 5.1.0-beta.1. It would be nice if you could try it and tell us if it works fine for you. |
Hi @jnizet It works great! Thanks! Just to give you an idea I tested it like this and it's perfect:
|
Hi, I was wondering what you think of some sort of "catch all" error. Then you could have something like so in your default errors:
That way you could don't have to list all possible errors in the default errors component.
The text was updated successfully, but these errors were encountered: