I'm stuck on a problem that I'm trying to solve with the window virtualization but challenge is not just a list but a table. How to match a table header with a virtual list. Any idea?
This generates an extra scroll in the page, one for the main page and another one for this window virtualized :( Is there any way that we can avoid that?
I think this actually calculates what to render based on scroll position, and fills in the top and bottom with a single empty div with variable height. 1 million intersection observers would cause performance issues during rapid scrolling
Yeah. All approaches for mobile list views during early days of mobile phones almost always relies on some type of virtual scroll/recycler view and that's because the early mobile phones had very little RAM. So there was no way to fit entire contacts for example on ram for rendering as list. Recycler view allowed reading from disk every time list is scrolled and only saving a constant amount of visible rows on screen in the ram. I would say as well all list views with unbounded length should be made from this manner as sooner or later that list is gonna grow more than the ram or exceed reasonable rendering time.
That browser limitation of max scollHeight
I think you can create multiple columns and see how many components fit that way.
Wow. I thought for sure you couldn't hit 1M. Nice stuff!
Great Stuff. Thanks 🤩
Wow, didn't know that before, thanks dude
nice explanation, i'm just wondering how it's work and your explanation really nail my brain
I'm stuck on a problem that I'm trying to solve with the window virtualization but challenge is not just a list but a table. How to match a table header with a virtual list. Any idea?
This generates an extra scroll in the page, one for the main page and another one for this window virtualized :( Is there any way that we can avoid that?
Can we put like a "waiting/loading screen" instead of the blank flickering in the library or would we have to implement it ourselves?
Great and informative video, thanks! Really appreciate it
So it's basically like intersection observer under the hood, yes?
I guess so.
I think this actually calculates what to render based on scroll position, and fills in the top and bottom with a single empty div with variable height. 1 million intersection observers would cause performance issues during rapid scrolling
May I ask which vscode theme you are currently using?
This doesn't affect server rendered components right?
1:53 Why localhost should render pretty fast?
Because u dont do any request over the internet
@@apostol1966 Thank you!
oh man, slow news day
It reminds me recycler view of anroid.
Yeah. All approaches for mobile list views during early days of mobile phones almost always relies on some type of virtual scroll/recycler view and that's because the early mobile phones had very little RAM. So there was no way to fit entire contacts for example on ram for rendering as list. Recycler view allowed reading from disk every time list is scrolled and only saving a constant amount of visible rows on screen in the ram. I would say as well all list views with unbounded length should be made from this manner as sooner or later that list is gonna grow more than the ram or exceed reasonable rendering time.
@@bangonkali Thanks man
Please make a video on how to convert react web app to android apk easiest way💯😏