Add ability to know what rows are currently in view

[drglitch]

A feature suggestion: adding ability to know the current start and end row index of the table view.
Having this would enable all kinds of potential smart caching and data pre-loading scenarios.

Proposed implementation is to: expose two new properties for visibleRowIndexFirst and visibleRowIndexLast that would be computed as per below.

visibleRowIndexFirst = floor(top offset scroll / rowHeight)
visibleRowIndexLast = ceil((grid height - (header outerHeight + footer outerHeight)) / rowHeight) + visibleRowIndexFirst

An alternative is to make use of content length for visibleRowIndexLast.

Please let me know if this is something that can be done - or i could always bump a pull req your way 😄

[azirbel]

This is a cool idea, but I'm not convinced it should be part of the core/default ember-table. Do you think it's a use case that many people will have? Could you elaborate on what you would use this feature for?

An alternative would be to extend Ember Table and add this functionality (probably what you are doing already). We could share that code via the http://addepar.github.io/ember-table/#/ember-table/community-examples page.

[igorT]

I implemented this myself once when I needed to lazy load the data in the background I think.

[drglitch]

@azirbel adding it as add-on could work (I'll gladly contribute the PR) but it might be worth adding it to the core table for following potential use cases:

• allows you to determine if selected row is in view or scrolled away.
• if it's a settable property allows you to programmatically scroll the grid to particular row
• allows you to do intelligent update and pre-load. Specifically if you have a ticking dataset and the row invalidation is outside of the view, you can just drop the event without involving ember's Morph plumbing at all. (This is my usecase)
• can intelligently preload cache based on scroll speed and screen/table height (also my usecase)

Another option is to get this also can be rolled up into sort of meta/introspect addon module?

[azirbel]

Thanks for the explanation! I can definitely understand those use cases. At this point I think I'd rather not merge it into the main Ember Table library; in my mind this falls more into the category of "clever extensions/extra behaviors". Most users probably don't need to do this kind of async loading/preloading and checking what's in the view, and I'm hesitant to add more to the API.

If you're willing to put an example together, I would really like to add this to the community examples page. Then if anyone asks for the same behavior, we can point them to your working implementation. If enough people ask, we'll merge it into the main library.

You could share this either as an extension/fork of ember-table, or just as a commented gist that gives an example of how to implement the behavior.

Are you interested in that route?

[drglitch]

Creating this as an add-on should certainly work on my end - perhaps something as simple as doing .extend() on the core classes. Forking might be a bit overkill as I don't expect the code to be that complicated.

I'll be revisiting this in a couple of weeks and report back :)

[billy-addepar]

This version of Ember table is no longer supported. If you want to continue discussion, you can open the issue on Ember Table Legacy