Render fixed number of items (for SSR / SEO) about virtual-scroller

[valdrinkoshi]

We do have a overhang property in Layout but we don't expose it. Yeah let's discuss about this in a separate issue

[CaptainCodeman]

Ah, I guess use the base repeater and set the num (items to render) would be the thing to do, no scrolling would be required then to have everything in the page rendered.

[domenic]

I think there is an interesting discussion to be had here generally on how to ensure virtual scroller content, which is backed by in-memory objects instead of DOM data structures, indexable by search engines/accessibility technology/find-in-page.

This issue jumped straight to a solution, and I think we need more exploration of the problem and solution space, but we should definitely discuss. Probably we should open a separate issue. Thanks for getting the conversation started!

[CaptainCodeman]

Thanks, I'll back up and explain more what my thinking was ...

This is for a PWA where I want to have infinite scrolling for normal users and use puppeteer to handle the SSR for SEO. I have it setup so the SSR'd request adds an extra ?headless option that the page can use when rendering with puppeteer to make sure that the full page of data is rendered for the search bot (it can also avoid loading unnecessary packages such as firebase auth).

I just have a switch in the code to use the plain repeater with fixed number of items instead of the scroller if it's in headless rendering / SSR mode.

I guess it would be slightly more convenient to have some option on the scroller that could force it to render a set number of items, even if they weren't absolutely required for the viewport. e.g.

scroller.forceRenderNum = headless ? pageSize || 0

The data loading itself is a separate concern handled with redux-saga so for headless mode the number of items loaded will always be the page size. It's just that the items can be large enough that only a few may render based on the scrolling viewport size.

Hope that makes sense.

[valdrinkoshi]

Another effective way to render all the items is to "force" the height of the <virtual-scroller> to be big enough to render all the items, something like scroller.height = scroller.scrollHeight invoked after the first render, or always set virtual-scroller { height: 10000vh; } style

[CaptainCodeman]

Thanks, I hadn't thought of that - I'll give it a try.

The other thing I was thinking about having the ability to force more items to be rendered is if there was some additional loading that happens per item. For instance, after rendering the HTML of an item I might convert links to YouTube videos into embedded players or do other content replacements (emoticon codes, markdown etc...).

Being able to have some 'margin' to how far out the rendering goes helps make sure they are loaded before they come into view. A bit like the margin in IntersectionObserver so you can chose when things start rendering before they come into the viewport.

That's probably a separate issue / use case though.

[rakina]

With the new approach (detailed in the updated README), this problem is pretty much solved, since all the items are in the DOM already, so closing this issue.