Input-date-picker displays incorrect value if out-of-range

[nwhittaker]

Check existing issues

• I have checked for existing issues to avoid duplicates

Actual Behavior

An input-date-picker pre-populated with an out-of-range value displays the closest in-range value instead of the actual value. The value prop contains the out-of-range value. The out-of-range state is never reflected in the input's validity and does not block form submissions.

Expected Behavior

The input displays the out-of-range value with a rangeOverflow or rangeUnderflow validity. Opening the picker should default the calendar selection to the closest in-range value. This should match how native date-pickers handle the same scenario.

Reproduction Sample

https://codepen.io/nwhittaker-esri/pen/oNRvGqm

Reproduction Steps

1. Visit the sample
2. See the displayed value matches the input's min instead of its value attribute
3. Click the submit button and see a success alert instead of a validation message

Reproduction Version

2.8.0

Relevant Info

No response

Regression?

No response

Priority impact

impact - p2 - want for an upcoming milestone

Impact

Field Maps allows users to edit meta data about form controls. As the meta data changes, the validity of a value can change. In those cases, we want the user to be able to identify the invalid data and correct it. For a date field that has become out-of-range, it can be confusing to see it marked as invalid but populated with an in-range value.

Calcite package

• @esri/calcite-components
• @esri/calcite-components-angular
• @esri/calcite-components-react
• @esri/calcite-design-tokens
• @esri/eslint-plugin-calcite-components

Esri team

ArcGIS Field Apps

[github-actions]

Installed and assigned for verification.

[benelan]

Copied from the PR body:

Ensure the initial value is within the min/max range. This is in line with the existing behavior, but it is not ideal.

The plan is to stop automatically changing the value to the min/max when it is out of range, and rely on form constraint validation instead. However, doing so would be a breaking change, so it's on hold until v3.

Verification notes

The behavior after this is installed will look the same as the repro sample. The key is to check the value of the component in the form submission callback:

form.onsubmit = (event) => {
  console.log(event.target.elements["date-picker"].value);
  ...
}

Here is an updated repro sample.

[DitwanP]

@benelan to be clear the repro from the issue body submits the value of the component but the behavior we want for now is to actually submit the min value right? That's what I'm getting in the updated repro just want to double check.

[benelan]

@benelan to be clear the repro from the issue body submits the value of the component but the behavior we want for now is to actually submit the min value right? That's what I'm getting in the updated repro just want to double check.

Yes, that's correct!

[DitwanP]

🍡 Verified locally on dev