0.8.1 breaks this in eventClick

[bessb]

According to the FullCalendar documentation for eventClick:

Within the callback function, this is set to the event's <div> element.

This is also true in the 0.8.0 version of ui-calendar, but 0.8.1 broke the way this works in eventClick.

The example callback from the FullCalendar documentation uses jQuery to set the border color of the event to red. This works fine in ui-calendar 0.8.0, but not in 0.8.1.

$scope.calendarConfig = {
  eventClick: function(calEvent, jsEvent, view) {
    angular.element(this).css('border-color', 'red');
  }
};

Here is a plunker where you can switch between both versions to see the issue:
http://plnkr.co/edit/DKDD7vAlV2ZrQ3fCD8uS?p=preview

[joshkurz]

good find. This is caused by the directive wrapping all of the calendarConfig functions with a $timeout function, which creates a new execution context that breaks this use case. So the question is could this be an unnecessary regression? Do we really need the calendar to wrap all functions with apply, or could we have the developer do this on their own?

If so then then the fix could be do just call either a timeout execution after the fullcalendar function call. http://plnkr.co/edit/FXLmrXMoZRbbFkjkoKQW?p=preview

I changed the code to look like this.

                      functionToWrap.apply(this, args);
                      $timeout(angular.noop);

Simple change. Their is probably a better way. Maybe someone else knows it and would like to share.

[tinybigideas]

It also breaks the use of (this) on event drops to the calendar.

Further issue, seemingly to do with the added $timeouts is that I also use eventRender function to dynamically change colour of events as they render. Now with the added $timeouts, these events flash on render which is not great.

Surely must be a better way, but it's out of my skill range unfortunately! I've reverted to 0.8.0 for the time being.

[joshkurz]

Hmm I guess forcing the timeouts was not the best idea.
On May 9, 2014 6:56 AM, "Craig Thomas" [email protected] wrote:

It also breaks the use of (this) on event drops to the calendar.

Further issue, seemingly to do with the added $timeouts is that I also use
eventRender function to dynamically change colour of events as they render.
Now with the added $timeouts, these events flash on render which is not
great.

Surely must be a better way, but it's out of my skill range unfortunately!
I've reverted to 0.8.0 for the time being.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/105#issuecomment-42654440
.

[ronantreacy]

I think this issue is also stopping 'return false' from preventing the redirect if the event has a url attribute.

[dalyc]

@joshkurz I am seeing the same problem with "return false" not preventing the redirect if the event has a url attribute (with fixed code). Does anyone have a workaround to prevent the redirect to the event url?

[mattcasey]

@dalyc I have been simply removing url with eventDataTransform(). If you still want to trigger the event, save it as a different field name and open it in eventClick()

[dalyc]

@mattcasey Thanks Matt. That works.
Don't 'spose anyone has a suggestion for not rendering events in month view only.
Returning false from eventRender (when in month view) doesn't work.
I can unload / reload events when swapping view I guess but just wondering if there's a more elegant solution.