equal_to_field

Checks that the value is equal to the value of another field, for example a password confirmation. Values are compared as strings: "10" and 10 are equal, while "10" and "1e1" are not. A missing field is not equal to any value.

Error codes: FIELDS_NOT_EQUAL, FORMAT_ERROR

Live example · edit rules or inputOpen in playground

rules

{
    password: 'required',
    password2: { equal_to_field: 'password' }
}

{ password: 'required', password2: { equal_to_field: 'password' } }

input

{
    password: 'secret123',
    password2: 'secret124'
}

{ password: 'secret123', password2: 'secret124' }

Invaliderrors

{
  "password2": "FIELDS_NOT_EQUAL"
}

In aliases, or and lists LIVR 2.5

In LIVR 2.0, rules that read other fields (equal_to_field and custom rules) saw a made-up object inside an alias, an or branch and an item of list_of: { value: x }, { field: x } and { field: item } in the JavaScript implementation. So a comparison with a sibling field never worked there, and { equal_to_field: 'field' } in list_of compared an item with itself.

LIVR 2.5 fixes it through the containing object: in an alias, an or branch and the rules of when the rule compares with a sibling of the field, in an item of list_of the other field is missing. A schema that relied on the made-up object gives a different result. To compare the fields of an item, use list_of_objects.

The argument stays a plain field name, not a reference: { equal_to_field: 'a/b' } compares with the field named a/b.