10

I have a custom Lightning grid component (like and editable lightning:datatable) for which I need infinite scrolling to display thousands of rows without bringing the customers browser to a halt.

I thought infinite scrolling is easy and checked out most of the available Lightning-specific code out there. It did worked like I expected. It was more like a pagination that works on scroll instead of on click.

Then I read this article by Google on the Complexities of an Infinite Scroller and understood why it is hard to build and get it right.

I also immediately understood why Salesforce' own implementation in Aura (build on top of ScrollerJS by Salesforce own Diego Ferreiro Val) looks so complex.

I tried to make this code work inside Lightning but failed because Lightning seems to be only a subset of Aura.

So my question is:

  • How do you do it?
  • Do you know of any Salesforce roadmap to release their internal scroller component?
  • What else could be of help to build a "good enough" solution?
Improve this question

1 Answer 1

Reset to default
7

I tried to make this code work inside Lightning but failed because Lightning seems to be only a subset of Aura.

Lightning is running a full copy of Aura. However, it's not running the current version of Aura. There's some lag time between what we have in Lightning and what we have in Aura; most likely, the introduction of ui:scroller means that we'll see it in the next release or two (obvious warning: we might never see it, for a variety of reasons). This is also the reason why, for example, we don't currently have a lightning:progressRing element, even though it's in the Salesforce Lightning Design System. Lightning as we know it is always at least one release behind SLDS.

How do you do it?

Today, you write really convoluted code, like the code you've found. However, I would also argue such code is overkill for the majority of use cases. If you're displaying "thousands" of items, or more, you may need to consider performance. If you're likely never going to show more than a few hundred items in a list, it's probably not a priority to be perfectly optimized.

Ultimately, what you're going to need is some custom rendering or something, and a complicated scrolling library. Or just go the easy way like Lightning does today, and just detect when you're within a few pixels of the scroll bottom and add more items. Or use pagination/filtering/etc. Naive infinite scrolling is "slower", especially on mobile devices, but should perform acceptably. Pagination, on the other hand, handles tens of thousands of records with ease, as I've demonstrated in a gist (note: yes, I realize it doesn't use newer Lightning features, it needs to be updated).

Do you know of any Salesforce roadmap to release their internal scroller component?

Even if we knew, we couldn't tell you, unless salesforce.com announces it publicly in an official manner, or unless you were under a Salesforce NDA (and even then, you'd learn through an official NDA'd channel, not the general community). Future Looking Statements (previously Safe Harbor Statements) are always prefixed with a warning that you should buy the Salesforce of today, not the Salesforce of the future. Anyone in a position to know what the roadmap looks like probably couldn't tell you, either, since that might be a violation of NDA.

What else could be of help to build a "good enough" solution?

That depends. What's good enough for me may not be good enough for you. For now, I strongly recommend pagination, even though SLDS would have us believe that infinite scrolling is a thing of the now. If you do implement infinite scrolling, consider a simplistic approach that simply updates the entire DOM. It's trivial to write, and it's good enough for Salesforce, so it should be good enough for us (for now).

The difference between pagination and infinite scrolling is that the user has greater control of the page loads. This is a Good Thing in the general sense. Nothing destroys a good user experience than having things repeatedly happening unexpectedly or unexpected slowdowns while just "browsing". For now, I would just suggest using lightning:datatable if it suits your needs, and if not, consider pagination. Infinite scrolling should still be considered a last resort for the moment.

Improve this answer
5
  • Thanks for your detailed answer. "Stick with pagination" is courageous answer and an option, which I will put back on my solution list. Nonetheless it feels wrong and looks so 80s. But you're right. Fake infinite scroll is also lame. Nonetheless hope dies last. Hope for someone providing a simple integration. So I will leave this open.
    – Robert Sösemann
    Mar 23, 2018 at 21:31
  • 1
    @RobertSösemann I'm going to take a whack at it; it may actually be easier than I think, but I'm not willing to step up to that statement unless/until I see a proper implementation in Lightning.
    – sfdcfox
    Mar 23, 2018 at 22:22
  • I'm trying a new solution and I am stuck again ;-) Maybe you can help here: salesforce.stackexchange.com/questions/163137 I guess a very easy one for you.
    – Robert Sösemann
    Mar 25, 2018 at 0:13
  • @RobertSösemann The solution is in the comments (nobody ever bothered to add it as an answer). You need to export your methods to window. I strongly suggest you group them together in a module format, something like this window.MYMODULE = (function(my) { my.someMethod = function(...) { ... }; return my; })({}). From there, you can call the method in your controller/helper: MYMODULE.someMethod. This is basically how jQuery and others do it (with minor variations in details).
    – sfdcfox
    Mar 25, 2018 at 0:47
  • Then I don't get why it doesn't work for me?
    – Robert Sösemann
    Mar 25, 2018 at 12:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .