Adam Shaw

I understand why someone might want an accurate `view.type` in this hook. A workaround is to use a setTimeout: ```js resources: function(arg, successCallback) { var calendar = this setTimeout(function() {...

very similar to https://github.com/fullcalendar/fullcalendar/issues/4660

anytime one single event needs to be rerendered, there needs to be some sort of rerendering for _all_ of the events, because the positioning of the new event may affect...

The best approach would be to break down each view into more self-sufficient subcomponents. For example, have each month's week render events independently. I started to down this route, and...

If you're curious to know, this will be included in v5 (currently in-development) **blog post:** https://fullcalendar.io/blog/2020/02/changes-in-the-upcoming-v5

I haven't profiled it yet, but v5 betas contain these optimizations. [please see the latest blog post](https://fullcalendar.io/blog/2020/04/new-ui-features-beta)

@ryanjkelly, thank you so much for benchmarking this! This is great news! I still plan to continue optimizing event rendering. Rather than minimizing DOM operations, I'll be attempting to minimize...

I have an update. I just released the [v7 release candidate](https://github.com/fullcalendar/fullcalendar-workspace/releases/tag/v7.0.0-rc.0) and the amount of times content-injection hooks are called has been greatly reduced. This addresses the original concern of...

workaround: after you know the animation is finished, call [updateSize](https://fullcalendar.io/docs/updateSize)

This has been addressed in [v7.0.0-beta.0](https://github.com/fullcalendar/fullcalendar-workspace/releases/tag/v7.0.0-beta.0) Updated repro: https://codepen.io/arshaw/pen/wvVMPjE