Hello @ToBinio,

Thank you very much for your contribution!

Could you try adding this property to both DateRangeField and DateRangePicker?

Hi @epr3

I don't think this is necessary for either, since their behavior of the model already matches the behavior of rawModelValue

Hi @ToBinio,

Oh, right, then, to achieve consistency, could you update the logic for the modelValue instead of adding the new property?

It would bring the date range components in line in terms of modelValue expectations.

Thank you!

Oh, right, then, to achieve consistency, could you update the logic for the modelValue instead of adding the new property?

One problem with this, I just realized, is that the calendar has the option to cancel the selection with ESC while only a start date is selected.
How should this be handled?

• Have modelValue represent the WIP select of the user and keep an internal "lastValidModel" for reverting?
• Have a setting for the Calendar to switch between a strict (current) mode and a soft mode where the model represents the current selection and no undo existing? - this would also keep the change non-breaking

or something else

note: thoughts on having the WIP selection auto undo if the calendar loses focus?

I'm thinking the first option with the lastValidModel would make the most sense, also being tied in the escape key functionality.

I have now made the v-model have the rawModel behavior - I also added an emit for if there is a new valid dateRange to make migration easier

just to note: the behavior of dateRangePicker also slightly changed since now, also during selection the model changes

Open in StackBlitz

npm i https://pkg.pr.new/reka-ui@2032

commit: 7d2417b