This repository was archived by the owner on Sep 8, 2020. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 8, 2020. It is now read-only.
Deleting an event then adding an event on the same date does not persist in the UI after you switch months #85
Description
This can be demonstrated on the demo at http://angular-ui.github.io/ui-calendar/
To recreate the issue
- delete the last event in the list on the left hand side
- click the add event button
- click the arrow to move to a different month
- finally click the arrow to move back to the month you were just on
You'll notice the event no longer appears in the calendar. I tested this in Chrome and Opera.
Activity
joshkurz commentedon Mar 5, 2014
Thanks for this bug report. It turns out we were not using the stick parameter when adding an event to the calendar. http://arshaw.com/fullcalendar/docs/event_rendering/renderEvent/
Updated to core and updated the Demo.
Thanks
joshkurz commentedon Mar 5, 2014
Now the opposite issue is happening though. :(
The "stick" parameter is a terrible hack in fullcalendar.js. Im seeing more and more that the Arshaw Fullcalendar has major flaws and is in need of a serious rewrite.
I don't have time right now to hack on fullcalendar.js, so maybe someone else can come up with a work around.
The issue is that if we add an event to a date slot that already has a date in it, we do not need to use the "stick" parameter. If there is no date in the the new events date slot, then we do.
I don't want to traverse all of the eventSources to find this information out before we add the event. Seems like a huge potential bottleneck.
Maybe we could just start calling addSource removeSource instead of adding and removing singleEvents. That should fix the issue. Im not sure exactly atm.
Or we could fork Arshaw Fullcalendar and start an active branch because the master is in need of some love.
@ProLoser what do you think?
jlmagee commentedon Mar 16, 2014
What is the real life use case that is causing an issue? You've got to persist new events somewhere other than the fullcalendar internal cache in most application use cases I've encountered and thus it ends up in an event source and there is no issue.
Also, there is a V2 beta of fullcalendar which I've been using with ui-calendar and moment.js. All seems to work quite well in the application I'm developing
t0pth4t commentedon Mar 16, 2014
It is a pretty simple use case. If you wanted to allow the user to remove an event and add a new event on the same date. Even if the event is persisted in an external data store are you really re-initializing the entire calendar every time there is an update to the event list?
jlmagee commentedon Mar 16, 2014
@joshkurz the stick parameter set to true is not what you want. It will behave exactly as it does on the demo page. I've removed it from my application development environment and everything behaves as expected. There must be some issue with the version of fullcalendar or perhaps jquery on the demo page. I'm using latest fullcalendar v2 beta and jquery-1.11 as well as pretty recent versions of everything else.
I used my development environment with all source and event refreshes commented out and once the new event is pushed to the source array, it is displayed across all paging operations, month, day, and week.
There are some significant changes in V2 for event "normalization." They are mostly for moment time handling but perhaps some setting affects the handling of items in cache.
joshkurz commentedon Mar 17, 2014
@jlmagee yes I think that the stick option should be taken out and we should integrate with version 2. This has been brought up in #86 as well, so I think its time we move forward. I think a v2 branch would be sufficient for now, until fullcalendar2.0 becomes stable.
joshkurz commentedon Mar 29, 2014
@jlmagee I just reverted this back as the stick option was pretty terrible. I created a v2 branch, but it does not fix this issue.