TrackList exports a useVirtualTracks hook so that any parent can become a virtual list container for very long track lists.
We need to call react-virtual useVirtualizer in the parent for rendering order reasons. But really the entire logic is contained in TrackList and we're just passing props.
Because react-virtual causes many renders and TrackItem is a pretty heavy component, we memo it. Might need to look for better perf optimisations, but this seems to do the trick.
Because of useDragTrack, we need to override the range extractor. Currently we always render every track between the one being dragged and the ones in the viewport. We could probably do better for performance with some maths, but this has seemed fine so far.
Because I wanted to only partially go through the virtualizer (only tracks, not other siblings like the cover), I have to overscan the # of items displayed (react-virtual doesn't calculate the size of the list correctly). There might be a better way than this... (as in more accurate / future-proof / flexible, but it works fine in terms of performance)
TODO
[x] missing scroll-to-track when clicking on track name in player
TrackList exports a
useVirtualTrackshook so that any parent can become a virtual list container for very long track lists.We need to call react-virtual
useVirtualizerin the parent for rendering order reasons. But really the entire logic is contained in TrackList and we're just passing props.Because react-virtual causes many renders and
TrackItemis a pretty heavy component, wememoit. Might need to look for better perf optimisations, but this seems to do the trick.Because of
useDragTrack, we need to override the range extractor. Currently we always render every track between the one being dragged and the ones in the viewport. We could probably do better for performance with some maths, but this has seemed fine so far.Because I wanted to only partially go through the virtualizer (only tracks, not other siblings like the cover), I have to overscan the # of items displayed (react-virtual doesn't calculate the size of the list correctly). There might be a better way than this... (as in more accurate / future-proof / flexible, but it works fine in terms of performance)
TODO