Skip to content
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

transformMessage for Complex Rules are setting transformMessage on sub rules improperly #9

Open
ibrahim-mubarak opened this issue Oct 21, 2019 · 1 comment

Comments

@ibrahim-mubarak
Copy link
Contributor

Complex rules such as AnyRule overwrite the transformMessage of the Rules themselves.

Expected Behavior

The transformMessage of a Rule should have higher priority than anything above it.

Current Behavior

The transformMessage of AnyRule and other similar Rules have higher priority than their subrules.

Possible Solution

We should add a contract for Complex Rules such as this so it becomes difficult to make mistakes like this.

Steps to Reproduce (for bugs)

The following Test can reproduce it

  test(
    'Sub rules use their transformMessage instead of AnyRules transformMessage',
    () {
      Rule<String> rule = AnyRule<String>([
        RequiredRule()
          ..transformMessage = (
            String message,
            Map<String, String> valueMapping,
          ) {
            return "Required";
          }
      ]);
      rule.transformMessage = (
        String message,
        Map<String, String> valueMapping,
      ) =>
          'Any';
      String message = rule.validate("Test", '');
      expect(message, 'Required');
    },
  );

Output

 Expected: 'Required'
    Actual: 'Any'
     Which: is different.
            Expected: Required
              Actual: Any
                      ^
             Differ at offset 0

Your Environment

  • Version used: v0.3.0
  • Flutter/Dart version: Dart version 2.5.0
@shbmbhrdwj
Copy link
Member

Currently, in AnyRule we are completely ignoring enclosed Rule#transformMessage instead we should use null assignment operator so the enclosing Rule's transformMessage does not override the enclosed Rule's transformMessage. Plus this issues points out a fundamental flaw on the usage of transfomMessage in the current implementation. We'll need to rethink the implementation details of transformMessage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants