2

I am using the full calendar scheduler plugin and have 3000 events in a single 30 day viewing range.

I have discovered that methods such as "renderEvent", "renderEvents" and "removeEvents" when called cause all events to re-render. This can be observed by adding a console.log in the eventRender callback.

This is causing my scheduler to take ~5 seconds to render after every change

Is there a way to only render the added event(s) or remove the single event?

ADyson
  • 57,178
  • 14
  • 51
  • 63
Tom Gardner
  • 58
  • 6
  • No, because there's always a chance that changes to one event will require changes to another event...e.g. if they now overlap, the other event might need to be re-drawn to make space (or vice-versa). That effect could then potentially cascade to other events as well, as I'm sure you can imagine. Is this causing you an actual practical problem? – ADyson Nov 08 '19 at 14:29
  • In my use case there could never be two events overlapping.So no single event could affect the position of another. This restriction is causing my scheduler to take ~5 seconds to render after every change – Tom Gardner Nov 08 '19 at 14:32
  • That's your own business logic though, the calendar code does not (and logically cannot) know that you will never do such a thing. There may also be other reasons why this is necessary, that's just the obvious one. I didn't implement fullCalendar so there could easily be other things at play too...you'd have to ask the developers. – ADyson Nov 08 '19 at 14:35
  • Have you considered whether having 3000 events on display all at once is really necessary? I would question whether anyone is going to find such a UI usable. Not many human beings are going to be able to absorb that volume of information. And I'd guess they probably don't need it either, they are likely looking for something more specific, I would think? Have you thought about perhaps displaying a shorter period of time, and/or allowing the user to filter the display by resource, or some other categories into which your events might be groupable? – ADyson Nov 08 '19 at 14:38
  • 1
    It's a fair point that you are making but for this case it is currently a business requirement to be able to see all events as they form patterns across rows. I'm aware of the normal use of scheduler and the limitations at face value of the library. I'm hoping to find out if there's something less known internally about scheduler that could be used to bypass rendering all events when only one is changed. – Tom Gardner Nov 08 '19 at 14:54
  • I see. Maybe some other data analytics tool than the naked eye could be used to spot the patterns from the raw event data? Or even to render a visualisation of it? Just a thought. Anyhow I'm not qualified to comment on the internals of the rendering engine, I'm afraid, I've never studied it. You'd have to study it yourself, or ask the developers directly (you could maybe raise an issue via the fullCalendar GitHub page and see if you get some engagement) if they know a way to safely alter the rendering behaviour. – ADyson Nov 08 '19 at 15:00
  • P.S. One other thing you could consider trying is upgrading to v4...it's [near-enough a full re-write](https://fullcalendar.io/docs/upgrading-from-v3), including not using jQuery or momentJS anymore, a move which certainly has the potential to have improved the performance of the code. It probably wouldn't take you long to knock together a basic v4 demo using your large dataset, and see if it makes any difference. – ADyson Nov 08 '19 at 15:03
  • Thankyou for your advice. I have already experimented with V4 to discover it was around 20% faster with my dataset. I will be attempting to only render the currently visible events as only 5 or 6 days can be seen at a time and re-render on scroll – Tom Gardner Nov 08 '19 at 15:22
  • "re-render on scroll"...rather than that, why not set the duration of the view to only 6 days? Then if the user wants to see the next time period they click next and fullCalendar handles the rendering. I suspect if you try and render on scroll you could easily end up in a world of trouble of multiple concurrent renders. I'm not even sure how you'd actually cause it to only render the "visible" days anyway...I don't think you will be able to programatically determine, at the time of rendering, which days are in the viewport. I could be wrong, but, it sounds very tricky. – ADyson Nov 08 '19 at 15:27
  • (And if the user desperately needs a wider view than 6 days, you could provide a 10 or 12-day view, or even the current month view, as an alternative...with the caveat that it comes at the expense of performance. The exact number of days which will actually be rendered without a scroll bar is not under your control anyway generally, since the width of users' screens/viewports can vary dramatically. You could render the calendar inside a fixed-width div I guess, but that's not very fashionable in the days of responsive design. – ADyson Nov 08 '19 at 15:28

0 Answers0