Purpose of pre-rendered lists

[HironTez]

What's the point of virtualizing pre-rendered DOM nodes, like in all the examples? It's much worse than using the render prop. The only scenario where this design may pay off is if you're absolutely sure the user will scroll through the whole huge list at least twice. Even in this case, it's not efficient to pre-render the whole list before displaying it.

A better pattern for such cases is caching: once an element has been rendered, store it so it doesn’t need to be rendered again. This avoids unnecessary re-renders without pre-rendering items the user may never see.

In practice, most users don’t scroll through giant lists multiple times. And if the list isn’t giant, there’s little reason to use virtualization in the first place.

My suggestion is:

• Stop showcasing pre-rendered virtualization in every example. Use render props instead — because I bet that most people are just copy-pasting the snippets.
• Add caching for already-rendered elements.
• Let the render function return components, not just elements. That way we can actually build dynamic features, like infinite scrolling with skeleton placeholders that update when data arrives.

What do you think?

[inokawa]

I agree that we should recommend using render prop and introduce ReactElement caching(it doesn't pre-render DOM nodes, but pre-create React elements without mounting), but not sure what return components in render prop means.

The reason why I recommend pre-created elements is historical, there were no render prop, Virtualizer and startMargin in 0.0.1.

I think render prop with caching will fit for 99% cases, but I still have some concerns and I don't want to obsolete any existing usecases, but I don't have enough time to go into the details.
If you want to help, see #511

[HironTez]

You're right; handling returned components can be tricky. A better way to achieve the desired functionality would be to add a cache revalidation mechanism. For example, when the elements are first rendered, the data hasn't been loaded yet and the renderer returns a placeholder. However, when the data finally arrives, we would like to re-render the changed part of the cache. We could re-render the visible part of the updated data immediately and simply remove the parts of the cache that are out of scope, rendering them again lazily when they come back into scope.

I don't think it's a good idea to simply change the existing behaviour. It would be better to add a prop like "enableCaching".

I will create an issue for this.