search

WICG / virtual-scroller

Other
2k stars 83 forks source link

Expose `item` on ItemSource #114

Closed bennypowers closed 5 years ago

bennypowers commented 6 years ago

The default itemSource should provide a way to get an item at a certain index. Tangentially, it should also provide a way to get the element currently occupied by an item at index.

domenic commented 6 years ago

I think if we were to do this, we'd make it via indexed properties, so itemSource[0] instead of itemSource.item(0).

But, the reason we've held off on doing this so far is that we don't know the use case. Could you explain an example of the code you're trying to write where it's important to have an indexable item source, instead of just using it as an opaque handle? That'd be really helpful for us to see.

domenic commented 6 years ago

Tangentially, it should also provide a way to get the element currently occupied by an item at index.

This part doesn't make sense for an item source; the item source doesn't know anything about DOM elements.

Again, a use case would be helpful, so we can see what problem you're trying to solve and how it's best solved with virtual scroller.

bennypowers commented 6 years ago

Hey thanks for the replies!

Currently I'm using IntersectionObserver to determine which elements are in the middle of the viewport and add attributes to them. If I has access to the list in the rangechange, I wouldn't need to construct a new IntersectionObserver, I could just get the median index, then access the element for the model at that index.

domenic commented 6 years ago

Very interesting!

Can you explain more about why you don't have access to the list? You must have had access at some point, in order to set itemSource, right?

Stepping back, I'm curious about whether there's a missing capability here in general for accomplishing your use case. Perhaps rangechange should contain a list of all the currently-visible elements, for example? When you say "in the middle of the viewport", do you mean everything visible, or literally in the middle?

bennypowers commented 6 years ago

Can you explain more about why you don't have access to the list? You must have had access at some point, in order to set itemSource , right?

Yes, but if I wanted to handle that list purely in the scope of the event, I'd have to pass it in with a closure. Not a huge hassle but IMO it subtly communicates to the user that they shouldn't be doing this.

Perhaps rangechange should contain a list of all the currently-visible elements, for example

Having a list of visible elements in rangechange would be superb. That would cover my use case even better than a handle on the list, since my goal is to perform side effects on visible elements. It happens to be I need the element in the middle of the screen, but grid uses could have other requirements.

Now that you mention it that brings up another tangential request...

Could rangechange also fire when the user scrolls back to the top? With that and your idea to provide a list of visible elements I could cover the following workflow without intersection observer:

  1. On initial load, set the active property on the first element
  2. As the user scrolls down, on rangechange, unset active on all visible elements, then set the active property on the middle-of-the-screen element, so that the only active element is the one displayed in the middle of the screen.
  3. Should the user ever scroll back up to the beginning of the list, rangechange (or some other event) fires, and the same effect as the previous step occurs, except the top element is activated, instead of the middle element.
domenic commented 6 years ago

Yes, but if I wanted to handle that list purely in the scope of the event, I'd have to pass it in with a closure. Not a huge hassle but IMO it subtly communicates to the user that they shouldn't be doing this.

Hmm, I don't think that's really the case. I close over a lot of things in my web apps' event handlers, generally. They wouldn't be very useful, otherwise.

Could rangechange also fire when the user scrolls back to the top?

Doesn't it already? Scrolling back to the top should change the range of visible elements...

rakina commented 5 years ago

Closing this as this is related to the old virtual-scroller concept that uses ItemSource. The new approach outlined in the explainer no longer uses this concept.