Our powerful JS Calendar component
When using the MonthView widget to display overnight events, the widget is rendering the event over two calendar days. Our Product team would like for us to display an overnight event as an event that spans one day, and the overnight event should display the right arrow.
In playing with the css for overnight events, it looks like I can modify the style of the event to display to our specifications. However, if I modify the css to reduce the width of the overnight event, the events on the next day appear with blank spaces between the event.
Is there a way to achieve this behavior with the existing framework? If not, would it be possible to expose the isOverflow property so that it is configurable during the event rendering process?
- 1.13.22_overnight_event_current_rendering.png (96.45 KiB) Viewed 373 times
- 1.13.22_overnight_event_proposed_rendering.png (96.13 KiB) Viewed 373 times
I think this is what you could use: https://www.bryntum.com/docs/calendar/api/Calendar/widget/MonthView#function-calculatePropagateEndDate
It's internal, but highly unlikely to change. I think it's internal only because we didn't think anybody would ever need to change this!
Not quite. For an event that starts on day 1 and ends on day 2, but the time span between these events is less than 24 hours, we want to display this event only on day 1. Currently, events that meet this use case are displayed on day 1 and day 2. For an example, if I have an event that starts on Thursday January 13, 2022 at 5 pm Eastern time, and ends on Friday January 14, 2022 at 5 am Eastern time, I want the event to render only on the January 13th cell of the MonthView widget.
This Should be solvable using https://www.bryntum.com/docs/calendar/api/Calendar/widget/MonthView#function-calculatePropagateEndDate but it's not quite flexible enough. It only gets passed the ending date, not the full info about the event and where it is in the flow.
If you can use just that to infer an ending date to the propagation of the event bar for a while, then I can get a more flexible version out in the next release.
I think that needs to be passed the full context to make the decision. Here is a ticket: https://github.com/bryntum/support/issues/4024
Just to let you know that although I have augmented that method as described, I have left it as an @internal method.
I have exposed this operation as an event so that it is easier for app developers to get sight of the data, and just calculate a new value to inject back into the event. The docs look like this now: