instantiate custom rules with DI

[fracz]

Apparently, there is no way to inject something from DI container when creating a custom rule. For example, I want to inject preconfigured HttpClient that exists in the container in order to call the backend for checking e-mail uniqueness.

Currently, you need to wrap the custom rule definition in an artificial class which you need to inject only in order to register the cutom rule (see an example of such).

I wish I could define a custom rule as a class, that would be instantiated with DI, resolving all of its dependencies.

Dream:

Definition:

class EmailUniquenessCustomValidationRule implements ValidationRule {
  validate (value, obj) { /* ... */ }
}

Registration (not sure if it is mandatory if we use class name directly):

ValidationRules.customRule(ValidateEmailUniqueness);

Usage:

ValidationRules
  .ensure('email').satisfiesRule(ValidateEmailUniqueness);

[jdanyow]

Is this a shortcut for doing something like:

ValidationRules.customRule(
  'email-unique',
  container.get(ValidateEmailUniqueness).validate
);

Another thing you could do today is:

main.js

export function configure(aurelia: Aurelia) {
  aurelia.use....
    ...
    .feature('./custom-rules')
    ...

custom-rules.js

configure(config: FrameworkConfiguration) {
  const service = config.container.get(EmailService);

  ValidationRules.customRule(
    'email-unique', 
    value => service.checkUnique(value)
  );

  ValidationRules.customRule(
    ...
    ...
  );

}

what do you think?

[dkent600]

I have proposed a solution for this. One would be able to use DI to instantiate SatisfiesConditionArguments (ie, any of SatisfiesConditionParameters | SatisfiesRuleParameters | SatisfiesTaggedRuleParameters) and pass it into a new method satisfiesCondition.

Note that part of this is also to support tagged rules, using SatisfiesTaggedRuleParameters.

This API has the advantage going forward of making it quite easy to extend the way satisfies works without breaking existing functionality.

It is forked from another branch of mine, hence the "FluentRulesGenerator", but could easily be made to work with the current master, if FluentRulesGenerator is not also accepted as a change.

export type SatisfiesConditionArguments =
  SatisfiesConditionParameters | SatisfiesRuleParameters | SatisfiesTaggedRuleParameters;

/**
   * Applies a named or ad hoc rule to an ensured property or object.
   * @param SatisfiesConditionArguments Configuration for the rule. Can be either a SatisfiesConditionParameters, 
   * for ad hoc rules, or SatisfiesRuleParameters, for named rules, SatisfiesTaggedRuleParameters for tagged rules.
   */
  public satisfiesCondition(params: SatisfiesConditionArguments): FluentRulesGenerator<TObject>;