Issue 1405: Render event sources asynchronous, as they are fetched
Status:  ExportedToGithub
Owner: ----
Closed:  Aug 2015
Reported by ma...@zoqui.com, May 15, 2012
Currently, fetchEventSource method checks if all pending sources have their events normalized before calling reportEvents, which will then clean the complete view.

Since multiple sources can be defined, it makes sense to normalize and display their events asynchronously instead of waiting for all sources to be fully processed before continuing. I think that source should not delay all other.







Aug 15, 2013
Project Member #1 adamrs...@gmail.com
(No comment was entered for this change.)
Summary: Render event sources asynchronous, as they are fetched (was: Asynchronous event loading when calling fetchEventSource method)
Status: Accepted
Labels: Type-Behavior
Feb 18, 2014
#2 christia...@gmail.com
This would very good for us to have also, as we have two sets of sources, where one set being very slow and the other being very fast. It would be a much better experience for our users if the events from the fast sources where disabled as soon as they were fetched, and not have to wait for the slow events.
Jul 24, 2014
#4 michaelw...@outeredgeuk.com
I have added this simple feature into my fork.
https://github.com/minlare/fullcalendar

Checks inside fetchEventSource for source.renderOnComplete option on the Event Source Object.

if (!pendingSourceCnt || source.renderOnComplete) {
    reportEvents(cache);
}

Can I raise a pull request?
Sep 2, 2014
Project Member #5 adamrs...@gmail.com
(No comment was entered for this change.)
Labels: milestone-annotation
Nov 11, 2014
Project Member #6 adamrs...@gmail.com
(No comment was entered for this change.)
Labels: -milestone-annotation
Jan 22, 2015
#7 alanbell...@gmail.com
this also trips up badly if you are loading lots of sources from the same server, the browsers have a 6 parallel requests per server limit, so if you are loading more than that the requests will stall until they have all been served. Arguably the application design is wrong and the calendars should be served in a single request, but this does lead to a blank calendar for quite a while when it could be showing the user something as it proceeds. We came across this in the vtiger CRM application, but I would imagine it comes up elsewhere too.
Apr 19, 2015
Project Member #8 adamrs...@gmail.com
(No comment was entered for this change.)
Labels: -Type-Behavior Type-Feature
Aug 17, 2015
#9 michael....@gmail.com
@alanbell, in v2.2, I cannot find `renderOnComplete` attached to the source object anymore under that function, but I was able to comment out the `if(!pendingSourceCnt){` (line 9083 in v2.3.2, but only tested in v2.2.2 function and now my 2 calendars appear to fetching asynchronously.

@adamrs, is there any harm in doing this?  It appears that the `pendingSourceCnt--;` is already outside the `if(eventInputs)` clause and the for loop to build `events` array is inside that clause, so even if the server was really slow or something else happened so that the `eventInputs` returned a false argument, `pendingSourceCnt` would still be decremented.  It appears this check to make sure `pendingSourceCnt` equals 0 is irrelevant, unless you are doing it for rendering performance on slower computers.  Even the "overflow" events in month with `eventLimit` works when removing `!pendingSourceCnt`.
Aug 21, 2015
Project Member #10 adamrs...@gmail.com
Discussion for this issue has moved to the following URL:
https://github.com/fullcalendar/fullcalendar/issues/1672

This is because Google Code is shutting down. Apologies if you are being pestered with these notifications. This is a one-time event.

Happy coding,
Adam
Status: ExportedToGithub