We are working with a complex customized event renderer. Please see screenshot to have an idea. Basically there are 2 main features:
1.we display the flight itself and we also display the turnaround time (the time needed to unload then reload the aircraft making possible to take off again)
- the display depends on the available width in a kind of responsive way. The more width is available, the more detail are displayed.
We are experiencing some performance issue with the custom renderer. So far our approach is to work with custom div and play with renderData.width for choosing detail level.
I attached to this ticket the source code for our event renderer so it gives you an idea.
We are wondering if you can advise a more performant way of covering our needs (maybe the usage of the "event progress" feature or nested event feature for instance). Before going to a significant refactoring, we would like to have your advice. Thanks!
- our-custom-renderer.png (35.06 KiB) Viewed 167 times
- (2.96 KiB) Downloaded 22 times
Best first step would be to do a performance audit, in the Chrome Dev Tools. Instructions can be found here: https://www.debugbear.com/blog/devtools-performance
Once that's done, you'll be able to see where the bulk of the time is spent (feel free to attach the report here too).
From the code, we see you are making lots of date manipulations which looks like that time consuming bit. Try avoiding moment (it's legacy anyway, unsupported?) and just use raw JS methods or our DateHelper class: https://bryntum.com/docs/scheduler/api/Core/helper/DateHelper
Better you calculate values in your EventModel instead of on the fly in the event renderer too.
If you like, you can also purchase 1 or 2 hours of Professional Services and we'll join you online to do a deeper performance review. Please contact our sales if interested.
Thanks for the feedback. Will try with chrome dev tools but I'm not comfortable with it. When you say moment is legacy can you precise please? I understand that you advise to get rid of moment in our project. I'm a bit surprised because I though that it was still the best way to handle date in js. Let me implement your suggestions first. Then depending on the outcome, I will come back to you for Professional Services (especially if we can learn from them about the profiling part^^).