Migration Guide & Breaking Changes
Creating and customing Aurelia Validation rules to ensure data is validated.
This section outlines the breaking changes introduced by @aurelia/validation*
as compared to the predecessor aurelia-validation
. However, it is recommended that you read the documentation, as many new features have been added.
A list of differences
Functionality is now in three different packages
Instead of a single validation package, the functionalities are arranged in three different packages. These are @aurelia/validation
(provides core functionalities), @aurelia/validation-html
(provides integration with the view), and @aurelia/validation-i18n
(provides localization support for validation in view).
Rules are defined differently using ValidationRules
Usage of ValidationRules
in terms of defining rules is a bit different. The example below shows the difference. Refer to the Defining rules section for the details.
Named registration of custom rules is no longer supported
Named registration of reusable custom rules is no longer supported in favor of simply using an instance of the rule implementation. The example below shows the difference. Refer to the Customizing rules section for the details.
The validator interface only has one method
The validator interface has been changed to have only one validate
method equipped with validation instructions. Refer to the Validator and validate instruction section for the details.
Validation controller factory usage changed
The usage of the validation controller factory is changed. Instead of using controllerFactory.createForCurrentScope();
, you need to inject the newInstanceForScope(IValidationController)
(example: resolve(newInstanceForScope(IValidationController))
). Refer to the Injecting a controller instance section for the details.
Validation renderer has been removed
No validation renderer in favor of ValidationResultsSubscriber
. Refer to the addSubscriber
and removeSubscriber
section for the details.
Last updated