Can't manually validate properties that are not bound

[guiprav]

I'm submitting a feature request

• Library Version: [email protected]

Please tell us about your environment:

• Operating System: Ubuntu 17.10

• Node Version: 8.7.0

• NPM Version: 5.4.2

• JSPM OR Webpack AND Version Gulp (Aurelia CLI 0.31.3)

• Browser: all

• Language: TypeScript 2.6.2

Current behavior:

validationController.errors remains empty after calling validationController.validate(), even though the property being validated is invalid, unless the property being validated is used in a binding with & validateManually binding behavior.

Demo: https://gist.run/?id=bd62deb898eca7c93a1ed901068090db

• Click submit button.
• Notice how first name isn't validated.

Expected/desired behavior:

• What is the expected behavior?

It should be possible to validate properties that aren't bound to any element. I'm creating a reusable dropdown editor component. Its value is an array of strings. If I bind that to a hidden element, it becomes a comma-separated list of strings, which is pretty inadequate.

• What is the motivation / use case for changing the behavior?

I've been using an ugly workaround where I set aurelia-validation on an unused property bound to a hidden input element and check the desired property directly from within the validation handlers, but it would be much, much better if Aurelia just allowed me to manually validate any property, regardless of binding behavior.

I think the use cases abound. If this behavior is by design and we want to keep it, can we make it configurable at least?

[Alexander-Taran]

@jdanyow can you label it? bug or feature?

[m-gallesio]

In our application we often rely on elements being actually bound in order to determine whether their values should be validated. This allows simpler rule definitions because an if.bind="condition" on a component can eliminate the need of a corresponding .when(condition) in the configuration.

Thus if this is implemented I think it should be configurable and not enforced, unless our use case is considered bad practice.