React-calendar-timeline: Performance Improvements V2

[mcMickJuice]

Let's discuss additional performance improvements that we can make to this library. Here are a couple of my goals and also some that others have mentioned:

• lazy rendering - only render items that are in or near viewport. This can be achieved by having an observer on each group row. If that group row is in or near viewport, then we render items in that group. If not, then we don't. This has some drawbacks as you don't have ctrl + F functionality but we can probably get around that
• cut down on unnecessary renders - don't rerender on canvas mouse over when showCursor is true
• Utilize PureComponent

[jabidof]

Have a look at https://github.com/NoamELB/shouldComponentUpdate-Children/blob/master/README.md
Not the canonical approach I would like to see implemented (from an academical viewpoint) but I could get a performance boost of a factor of 6-8!
For just a one-liner I adopted it 👏

[Ilaiwi]

an improvement would be to memorize the results from the dimensionItems, groupHeights, groupTops this will of course cut down extra renders as well...

[jabidof]

Any chance react waypoint would improve performances?
http://brigade.github.io/react-waypoint/

[mcMickJuice]

For sure @jabidof . I was looking at that or using a polyfill for IntersectionObserver. Either way, I think my strategy for this would be:

• use two waypoints as a top and bottom "sentinel". These sentinels will be tied to a GroupRow so we will know what groups are within visible range (+ / - some padding)
• For those groups that are within visible range, only render Items tied to those groups (vertical culling)
• as you scroll, these waypoints will be hit and reset, which will update the range of visible groups

This is theoretical but that should cut down on rendering of items that are out of view. The same approach can be applied horizontally.

[mcMickJuice]

This is a big one too: https://github.com/namespace-ee/react-calendar-timeline/issues/357

[acemac]

Would https://github.com/bvaughn/react-virtualized be possible for this?

Or any hints? I'm going to end up with thousands of groups and will need to cut down on re-render times for them.

[Ilaiwi]

Yes, it would. actually, I might experiment with it in the following two days

[Shvarts]

@Ilaiwi Did you have any success on experimenting with https://github.com/bvaughn/react-virtualized?

[Ilaiwi]

@Shvarts no yet. However, I just merged #392 which has a substantial performance boost with no
API changes. I will release it by the end of the week.
I will get to virtual lists sometime soon but I can't say when exactly since I am very busy with work.

[vasdee]

@Shvarts @Ilaiwi shameless plug, but the timeline component mentioned under https://github.com/bvaughn/react-virtualized#friends was heavily inspired by this timeline and got some great performance gains out of react-virtualised. Full disclaimer, I'm a co-author

[hellooperatorpatchmethrough]

Any status updates ?

[Ilaiwi]

@hellooperatorpatchmethrough I am currently working on an RFC for rowRenderer which should change how the items are being redered and will improve the performance of the library a lot!