petyosi / react-virtuoso

The most powerful virtual list component for React
https://virtuoso.dev
MIT License
5.25k stars 301 forks source link

Grouped Mode: There is no way to reset endReached/startReached #291

Open muyiwaoyeniyi opened 3 years ago

muyiwaoyeniyi commented 3 years ago

It appears when using regular mode, you can now reset endReached by change the object reference for the data prop (see https://github.com/petyosi/react-virtuoso/issues/182) but since the data prop isn't used in grouped mode, there is no way to reset endReached/startReached. I was hoping changing the reference for the groupCounts would do this.

I'm currently on v1.5.5.

petyosi commented 3 years ago

I need some more context to understand the necessity to reset the events state in grouped mdoe. So far, I am aware of the following:

A top-to-bottom endless scrolling list, where endReached is used to fetch more items. This should work as expected in both flat and grouped mode.

A large list with a textbox which can be used to filtering the results. In this case, the correct approach would be to re-mount the component by passing a new key - the old size cache is not useful anyway.

A reverse-scrolling list (chat, feed, etc). This works in flat mode, but fairly complex (although not impossible) to implement in the grouped mode because prepending grouped items is hard (see #279). I am not sure if this is what you mean, though, since it is unlikely for you to need endReached in that stage.

muyiwaoyeniyi commented 3 years ago

@petyosi Thanks again for this package. We use it in an upcoming product and it saved us a ton of time.

Here's the use case I have. It's similar to Slack where the app loads more data remotely when you scroll to the top or when you scroll down. I could use atTopStateChange or atBottomStateChange but I find that they fire more events that is necessary for determining when to fetch data. It would be very useful to have a way to reset endReached and startReached when necessary so more data can be fetched. In a way, you can say this use case is a mix of the top-to-bottom scrolling and reverse scrolling.

At the moment, I use atTopStateChange and atBottomStateChange to achieve this.

petyosi commented 3 years ago

@muyiwaoyeniyi What you describe still does not explain why you need to reset the state of endReached or startReached. Loading more data will change the totalCount and will reset them for you.

muyiwaoyeniyi commented 3 years ago

@petyosi I get that but like it was raised on another issue, if the request fails or you lose data or something else happens that doesn't fetch more data, then I can't use endReached or startReached anymore. You added resetting endReached by changing the data object reference but this doesnt work for startReached in grouped or ungrouped mode. And resetting endReached doesn't work in grouped mode.

nonoroazoro commented 3 years ago

@petyosi I get that but like it was raised on another issue, if the request fails or you lose data or something else happens that doesn't fetch more data, then I can't use endReached or startReached anymore. You added resetting endReached by changing the data object reference but this doesnt work for startReached in grouped or ungrouped mode. And resetting endReached doesn't work in grouped mode.

Use atTopStateChange and atBottomStateChange to retry fetching more data.

atBottomStateChange = { isReached => {
  if (isReached) {
    // Fetch more data.
    // Don't forget to debounce your request (fetch). 
  }
}}

This is like reseting (or recalling) the endReached and startReached.

muyiwaoyeniyi commented 3 years ago

@nonoroazoro That's what I'm using at the moment, but they fire a lot more than endReached and startReached.