Resize overflow event cause Invalid Date

[BlackRockSoul]

Resizing startDate of multi-day events or events that overlaps max of the calendar, make the startDate 'Invalid Date'

dates.min of [Date, undfined] returns Invalid Date.
Add fallback date from closestSlotFromPoint if no closestSlotFromDate found.

This should fix #1598, #1199, and partially the #2011

It could be reproduced on the 'draggable and resizable with showMultiDayTimes' page of the storybook, but for custom min and max calendar props I added 'draggable and resizable with event overflows the custom time period'

[BlackRockSoul]

The event still shrinks to the end of the day when resizing, I can also add my workaround if necessary.

[dhruvgoel92]

Hi @BlackRockSoul
Can you take a look at this PR : #2138 this fixes both the issues you mentioned?

Let me know which solution is the right way forward.

[BlackRockSoul]

Hi!
slotMetrics.closestSlotFromDate(end, -1) may probably return undefined, I think? If you're pointing to a different day?
In my hotfix I made this:

    let { start, end } = eventTimes(event, accessors)
    if (direction === 'UP') {
      start = dates.min(
        newTime,
        slotMetrics.closestSlotFromDate(end, -1) || newTime
      )
    } else if (direction === 'DOWN') {
      end = dates.max(
        newTime,
        slotMetrics.closestSlotFromDate(start) || newTime
      )
    }

    // Override values from getRange method with the actual date range
    this.update(event, {
      ...slotMetrics.getRange(start, end),
      startDate: start,
      endDate: end,
    })

I didn't test it really hard, but it's kinda working for all my needs. Resize or moving doesn't break anything

Not sure if it's related to this topic, but I also removed this:

const isZeroDuration =
    dates.eq(start, end, 'minutes') && start.getMinutes() === 0
  // make zero duration midnight events at least one day long
  if (isZeroDuration) end = dates.add(end, 1, 'day')

UPD. Oh, of course, it can't

if (localizer.gt(date, end, 'minutes')) return slots[slots.length - 1]

So maybe || newTime is not required anymore.

[cutterbl]

@BlackRockSoul This may be part of why you're running into file conflicts, as the localizers now handle all date math. So dates.min() becomes localizer.min and dates.eq() becomes localizer.eq(), etc. You seem to be working with an older version of Big Calendar, as these changes went into effect back in September...

[BlackRockSoul]

@cutterbl Huh yes, I switched to my own fork and made some changes a while ago. And still using this old version. I'll switch to the original repo after you merge #2138 fix 😃
So yeah, your variant should fix both issues probably so I'm gonna try!

[dhruvgoel92]

@BlackRockSoul @cutterbl so do you folks think #2138 is the right way forward? We have already done extensive testing on it and we are up to date with the latest version. Would love to get it merged and fixed for everyone!

[BlackRockSoul]

@dhruvgoel92 I'm pretty sure it should work since it's 80% similar to my old hotfix and it working fine for a while already (not production yet, but anyway). So yeah, 100% I will switch from my fork to the original repo after this fix will be merged.

[cutterbl]

Closing, as @dhruvgoel92 's change is now in 0.39.2