Hmm, this is unfortunate - now, in templates, you can't rely on instanceof MinValidationError giving you type-safe access to the min property. How about splitting to MinNumberValidationError and MinDateValidationError?

Each with a unique kind?

export class MinNumberValidationError extends BaseNgValidationError {
  override readonly kind = 'minNumber';

  constructor(readonly min: number, options?: ValidationErrorOptions) {
    super(options);
  }
}

export class MinNumberValidationError extends BaseNgValidationError {
  override readonly kind = 'minDate';

  constructor(readonly min: Date, options?: ValidationErrorOptions) {
    super(options);
  }
}

That way switching on kind works too:

if (e instanceof NgValidationError) {
  switch(e.kind) {
    case 'minNumber':
      console.log('This is a number: ', e.min);
      break;
    case 'minDate':
      console.log('This is a date: ', e.min);
      break;
    ...
  }
}

Also thoughts are keeping "min" to represent number, as opposed to "minNumber"?

Shouldn't this test also check that the max attribute is set on the input element ?

Validation and property bindings are distinct behaviors that are tested separately. For context, binding to the input max property doesn't have affect signal forms validation–it would however affect native validation.

See the previous test : should bind to native control.

Then perharps should we add a test case that illustrate that we are setting the min/max attribute for date inputs ?

Yes, good catch. This actually raises an interesting issue.

We made the decision that max and min only worked on Date values for dates. Attempting to use Date objects to set the value implicitly converts them to strings.

For example:

input.max = new Date('2026-04-02'); // Wed Apr 02 2026 [detailed time zone information]

However, date inputs only accept very specific formats for min and max: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Attributes/max#syntax.

For example:

// type="date" expects yyyy-mm-dd
input.max = '2026-04-02';

Several ideas come to mind:

• Add specific logic for binding min and max based on the input type, converting dates to their corresponding strings.
• Change min and max to use string instead of Date for date inputs, since that's what they expect. We'd then need to add specific logic to the validation rules to handle comparing Date objects with strings. Furthermore we'd need to change the metadata reducers to handle comparing dates as strings.

I think at one point we might have considered a separate validator minDate/maxDate. Would that still be on the table ?

Yes, I think especially so in light of this issue.