isOutsideRange property ends up nullifying invalid dates entirely

[deeplyfriedchicken]

react-dates version
react-dates@21.8.0

Describe the bug
Using isOutsideRange prop will completely remove an invalid date when a date outside the range is manually typed in. This prevents us from handling invalid inputs with validation schemas like Yup and creating better error messaging experiences for our app.

Source code (including props configuration)
We recommend checking out this CodeSandbox to see the other libraries we use in conjunction with SDP.

https://codesandbox.io/s/single-date-picker-range-validation-reproducible-chrrlt?file=/src/Form.jsx:1707-2451

Steps to reproduce the behavior:

        <SingleDatePicker
            name={name}
            focused={isDatePickerOpen}
            onFocusChange={({ focused }) => setIsDatePickerOpen(focused)}
            date={value}
            onClose={() => trigger("date")}
            onDateChange={(date) => {
              onChange({ target: { name, value: date } });
            }}
            numberOfMonths={1}
            isOutsideRange={(day) =>
              isInclusivelyBeforeDay(
                moment(day).startOf("day"),
                moment().startOf("day").subtract(1, "days")
              ) ||
              isInclusivelyAfterDay(
                moment(day).startOf("day"),
                moment().startOf("day").add(31, "days")
              )
            }
          />

Screenshots/Gifs

Kapture.2023-09-07.at.12.28.50.mp4

Desktop (please complete the following information):

• OS: MacOS 12.6
• Browser Arc
• Version 1.6.0

Is the issue reproducible in Storybook?
Yes, but it's not apparent what happens under the scenes. The text remains, but the value is not stored.
https://react-dates.github.io/react-dates/?path=/story/sdp-day-props--allows-next-two-weeks-only

Additional context

We're aware this isn't necessarily a bug, but the pattern here feels incorrect. The library should allow developers to decide how they want to handle invalid inputs. Blanket removing all invalid inputs leads to some confusing and vague behaviors.

[ljharb]

What change would you suggest that wouldn't be semver-major?

[deeplyfriedchicken]

What change would you suggest that wouldn't be semver-major?

@ljharb potentially adding an additional optionally accessible parameter to the onDateChange and onClose function parameters. It'd allow developers to grab that value and store it if they choose without breaking current behavior.

<SDP
  {...props}
  onDateChange={(date, rawValue) => /* we could do something with rawValue if we wanted to */}
  onClose={(date, rawValue) => ...}
/>

// but should work normally without accessing that param i.e.
<SDP
  {...props}
  onDateChange={(date) => ...}
  onClose={(date) => ...}
/>

[ljharb]

onClose seems to already pass an object with a date property, so we could add a rawValue property to it. onDateChange would indeed need to take a second parameter.

Any chance #1941 would solve this, making this a duplicate of #1937?

[deeplyfriedchicken]

@ljharb oh yes! #1941 would work really nicely! Thank you for surfacing that issue, sorry I couldn't find it before posting.

would love to see your onClose suggestion as well. Happy to close or keep this issue open depending on how you see fit.

[ljharb]

Let's keep this open for the onClose change.