-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Referential issue with default values for defaults.position.start and defaults.position.end #112
Labels
Comments
Could you submit PR which fixes this? |
Sure, I'll try and do so this week :-) |
Excellent! |
To highlight this problem see this sample script: http://jsfiddle.net/eUYDK/ |
A solution could be to remove this.options = $.extend(true, {position: {start: new Date(), end: new Date()}}, defaults, params); |
If it's ok I'd fix this bug |
Nice fix, thanks guys :-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There is a peculiar referential issue relating to the Date instances assigned to the defaults.position object that only becomes apparent when attempting to use multiple Calendars on a single page, as I am doing for a project which requires inter-linked Calendars rather than the drill-down type support by bootstrap-calendar.
See below for a simple example:
I dug into things using the Chrome debugger and noted that during the this._init_position() call during the construction of the weekCalendar object that the Date instance pointed to by this.position.start was the same as the Date instance pointed to by the defaults.position.start.
The result of this was that the .start and .end values for monthCalendar get over-written during the constructon of the weekCalendar and result in the monthCalendar having .start and .end values that do not match what it was configured with initially.
This in turn causes the navigation feature to behave erratically.
I was able to circumvent this issue as follows:
The underlying issue here is that jQuery.extend does not really support a true deep-copy it seems and is unable to clone instances of objects like Date when performing a deep-copy.
I would recommend that the values for defaults.position.start and defaults.position.end be set to null and then initialised to a new Date() instances following the call to jQuery.extend in the Calendar constructor function.
The text was updated successfully, but these errors were encountered: