Compare commits

..

No commits in common. "13dd3fde596fc04ba4e1fd7b8f0a492cb263a1d7" and "fa7436a499a7e3c8e2f4dd619686ac5d701f0edb" have entirely different histories.

View file

@ -122,13 +122,7 @@ function isDateDisabled(d: DateValue): boolean {
}
if (y === start) return false
if (y > start) {
// Do NOT disable the days inside the minimum-stay window here: reka-ui
// refuses to complete a range that *spans* a disabled day, so disabling
// start+1 (for a 2-night minimum, etc.) makes every forward check-out
// unreachable — the guest can only click an earlier day, which reka
// swaps in. The minimum stay is enforced in onModel instead (a too-short
// range keeps the check-in and clears the check-out). Occupied nights
// past the next booking still cap the range.
if (y < addDays(start, props.minNights)) return true
if (boundary.value && y > boundary.value) return true
return false
}
@ -149,12 +143,8 @@ function onModel(v: RekaDateRange | null) {
const ok =
stayIsFree(props.nightSet, ci, co) && nightsBetween(ci, co) >= props.minNights
if (!ok) {
// A range too short for the minimum stay (or spanning an occupied
// night). Keep the check-in and redo the end. checkOut is already ''
// here, so the props watch won't fire — reset reka's controlled model
// directly, otherwise its highlighted end lingers on the rejected day.
// Defensive: reka let a bad range through — keep the check-in, redo the end.
pendingStart.value = ci
model.value = { start: fromYmd(ci), end: undefined }
emit('update:checkIn', ci)
emit('update:checkOut', '')
return