You are correct: react-window/react-virtualized address the same problem. My goals with react-virtuoso however, are quite different;
Resizing / variable size content: react-window assumes that items have the same (or known) height. This is not always the case; you may be displaying user content, images with unknown size, etc. The list may resize on a mobile device. Measuring those elements is hard, sometimes not possible.
Rendering: react-window positions each item element absolutely. react-virtuoso keeps all items in a single container and "bounces" the container while updating its contents to simulate the scrolling movement.
Browser support: react-virtuoso uses position: sticky for the content container, which makes up for simpler implementation (not having to deal with pointer events). However, this means no IE11 support. I think that a fallback mechanism can be implemented at some point, but I haven't gotten to that.
Finally, I believe that all of the above boils down to project goals. The author of react-window says that he aims to have a small and fast package while skipping non-essential features. My goal with react-virtuoso is to have batteries-included, common cases working out of the box solution that does not force the user to jump through unnecessary hoops that are easy to address from the inside.
If I had known about this before, I'd have implemented my site with with react-virtuoso (as IE11 isn't of a concern).
The variable size content workaround in my implementation was not as performant as I tried to re-calculate the content size depending on the current viewport.
As those (batteries) are included, I will look in the future site to use react-virtuoso (unless I get time to go back to the current site to replace the react-window version with).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
You are correct: react-window/react-virtualized address the same problem. My goals with react-virtuoso however, are quite different;
Resizing / variable size content: react-window assumes that items have the same (or known) height. This is not always the case; you may be displaying user content, images with unknown size, etc. The list may resize on a mobile device. Measuring those elements is hard, sometimes not possible.
Rendering: react-window positions each item element absolutely. react-virtuoso keeps all items in a single container and "bounces" the container while updating its contents to simulate the scrolling movement.
Browser support: react-virtuoso uses
position: stickyfor the content container, which makes up for simpler implementation (not having to deal with pointer events). However, this means no IE11 support. I think that a fallback mechanism can be implemented at some point, but I haven't gotten to that.Finally, I believe that all of the above boils down to project goals. The author of react-window says that he aims to have a small and fast package while skipping non-essential features. My goal with react-virtuoso is to have batteries-included, common cases working out of the box solution that does not force the user to jump through unnecessary hoops that are easy to address from the inside.
Thank you so much, Petyo, for thorough reply.
If I had known about this before, I'd have implemented my site with with react-virtuoso (as IE11 isn't of a concern).
The variable size content workaround in my implementation was not as performant as I tried to re-calculate the content size depending on the current viewport.
And the jankiest part was the keyboard navigation (as you graciously pointed out the cause of the issue.)
As those (batteries) are included, I will look in the future site to use react-virtuoso (unless I get time to go back to the current site to replace the react-window version with).