Open daveharris opened 3 months ago
I have tried working around this via:
.calendar('set mode', 'hour')
.calendar('refresh')
.calendar('destroy')
However, none of them have worked
Upon further investigation I found that this was also triggered from code like:
$('.calendar.start').calendar({
startMode: $('.calendar.start').calendar('get date') ? 'hour' : 'month'
})
I was doing this because if the calendar had a date selected, I wanted to zoom straight to 'hour' mode so they can move it forwards or backwards by an hour easily. This seems a common use case.
I assume that this broke because calling .calendar('get date')
internally initializes the Calendar with .calendar({})
and then re-initialises with startMode: 'hour'
and thus getting into the same situation as https://jsfiddle.net/978rct0k/7/.
In this case I have worked around this issue via:
$('.calendar.start').calendar({
startMode: $('.calendar.start').find('input').attr('value') ? 'hour' : 'month',
})
and
<input value="2024-04-09T17:00:00+12:00" type="text" name="event[starts_at]">
Where the value attribute is in ISO8601 format so it can be reliably converted to a JS Date via Date.new($('.calendar.start').find('input').attr('value'))
Well this looks like a difficult issue to look at... The more I step into this, the more I wonder how it can be fixed without breaking anything else.
The less code breaker workaround that I found is to do this at the 2nd init:
/* Setup for the start calendar*/
$('.calendar.start').calendar({ startMode: 'hour' }).calendar('set mode', 'hour');
@lubber-de a potential fix would be to add these lines in calendar.js
, line 118
:
if (settings.startMode !== module.get.mode()) {
module.set.mode(settings.startMode);
}
But i'm not sure about the isues it could raise.
Yeah the more I looked into it the weirder it got.
The one thing you could potentially change would be to return undefined
from $(...).calendar('get date')
if it hasn't been initialized yet. However this would likely be a breaking change and may not be consistent with the other modules.
It also wouldn't help the initial case where it's initialized twice - which seems to be the root cause of the issue
Fixed by #3033 See your adjusted jsfiddle here https://jsfiddle.net/lubber/b04zkxf6/
The previously stored settings were not removed on re-instantiation which was causing your described situation
Wow that's brilliant, thanks for such a fast fix @lubber-de
Out of interest, does it internally call destroy
upon (re-)initialisation as I notice that we don't need to explicitly call .calendar('destroy').calendar({...})
?
Yes, all FUI js modules call destroy upon re-instantiation automatically.
Bug Report
When a Calendar is initialized from
<input value="...">
withstartMode: "month"
and , and then initialised again withstartMode: "hour"
, the date of the calendar is the 1st of the month. When the calendar is dismissed and re-opened, the date is correctly set.The calendar is initialized twice because the first time is done across all calendars on the site (i.e.
$('.ui.calendar').calendar({})
), and then some specific setup of a particular calendar (i.e.$('.calendar.start').calendar({...})
) based on the use-case of the page.Steps to reproduce
<input>
HTML element with avalue
attribute (to set the initial date)startMode: "month"
startMode: "hour"
month
value
attribute)Expected result
The date is the same date as the
value
attribute, in this case "April 6"Actual result
The date is the 1st of the month, in this case "April 1"
Testcase
https://jsfiddle.net/978rct0k/7/
Screenshot
Version
2.9.3