Aurelia: Support virtualization in vNext to handle large list of items

[Sayan751]

💬 RFC

Though at this point, I have not yet tried Aurelia vNext, it seemed from the community discussions, that ui-virtualization is still to be implemented in vNext.

In simple terms, we need a way to deal with very large list of items. The traditional practice was to use pagination for such large lists, with reasonable page size. Considering that pagination removes the old pages from DOM, it should be a reasonable strategy. However, in the absence of pagination (example: infinite scrolling), or with a bigger page size, displaying such list would be very taxing due to large DOM size. Therefore, there is a need to optimize the resource usage/size of DOM, to provide more performant, and seamless experience.

In the current version of Aurelia, this is handled by the virtual-repeat, and infinite-scroll-next attributes from aurelia-ui-virtualization plugin. However, the result of using that is not quite as expected.

🔦 Context

At my workplace, we are in need of showing millions of records in a web app. Of course the sanest solution is to get the data in chunks and on-demand.

For showing the data, our original plan was to have infinite scrolling, instead of paging. Therefore, we tried aurelia-ui-virtualization plugin, but without success, as pointed the issue linked above.

The major deal breaker are jerky scrolling, and breaking of CSS styles. The jerky scrolling nullifies the whole point of keeping the DOM size in check and thereby having a seamless scrolling experience. Keeping the styles consistent is also equally important for user experience.

At the end, we reverted to pagination.

💻 Examples

I think supporting the current syntax in vNext would be much helpful to start with. But feel free to add new use cases, better syntax, and to make this proposal better.

[EisenbergEffect]

Definitely agree that we should have this for vNext and also that the current syntax is good 😄 I'm sorry you've encountered an issue with the current version in your scenarios. It's definitely a tricky thing to get right for all the ways that people would use it. We'd love to have you work with us on the implementation. The way the core repeater works in vNext internally has changed a bit so we probably can't port directly. However, @bigopon is working on some fixes to vCurrent's virtual repeater now. He may be able to help address your current issues there in the short term. Then, because he also has deep knowledge of vNext internals, maybe he can help work on the vNext virtual repeater. @bigopon What do you think? Are you up for it? It's a challenge but man would it be awesome.

[bigopon]

I think @fkleuver already mentioned he wants to tackle this part, so I think we're good, I'll be improving our vCurrent implementation as an inspiration

[fkleuver]

@bigopon By all means feel free to give it a go in vNext if you want. I've got more than plenty to do before I get to virtual repeater anyway.