Support for zero height rows about react-virtuoso HOT 13 CLOSED

Although, I suspect that if you return anything that technically doesn't render it behaves as though you have less items in the list than you originally declared so it fails. You can't return a null object, a hidden div or a div of zero height.
Perhaps it's a little bit like #6 where have to change the totalCount before triggering each item.
If that's the case, then it's a little painful because the child is the only thing that knows if it needs to be rendered and I don't want the component creating the <Virtuoso> component to have to calculate how many to draw.

from react-virtuoso.

Hey @fonty422 ,

That's not something that I have considered so far, and I am probably using the zero as a special value here and there. Can you help me out with a test case that I can observe? Perhaps there is an easy way to support the behavior.

Thank you!

from react-virtuoso.

I've made a quick sandbox. Try make the ones we don't want to display be zero height, or better still return a null.
https://codesandbox.io/embed/stoic-beaver-m3ez2

from react-virtuoso.

If understand your example correctly the problem is due to probing logic of the Virtuoso component. In particular the first item should be visible.

A workaround for that will be to set initialItemCount to some value which will guarantee that visible item will be initially rendered.

Updated example: https://codesandbox.io/s/pedantic-river-u9qiv?fontsize=14

from react-virtuoso.

So close! It works nicely with small lists, like the one initially provided, but if I modify your example to start with a large list of even 1k items, it renders the first few, then pauses for a while, then renders the rest. Then the list can be scrolled/interacted with. BUT, if you return a proper div with some text, it renders immediately with no hang and full interactivity.
Thoughts?

https://codesandbox.io/embed/sparkling-sunset-34rgw

While not a perfect example of my case, it somewhat shows the issues - a lag in filling up the container at initialisation and some jitter when scrolling. On my production version it shows the first 3 items. pauses, then shows the remainder and it's not the best UX.

from react-virtuoso.

Thank you for the example - I can see that the measurements of the list are incorrect in this case. Will fiddle with it over the weekend and see if this can be supported.

from react-virtuoso.

Thanks! Very much appreciated.

from react-virtuoso.

I've continued working on my project in the mean time and have come across a scenario that might be important to consider.

My real data is ~3600 list items at the moment. There are 4 states each item can be in (0-3). The user may wish to show all 3600, or determine which states they want to view via checkbox selection. One of these states, however, only contains 20 list items! In this case, all animated features of the list become intensive/slow/jittery. I imagine it's all related in that it's calculating calculating the position of the 3580 odd items so it's lagging a bit. I imagine this will be cleared up with the fix - no worries.
When in proper operation it's likely that there will only be a small handful that are in a state that needs displaying, so this might prove to be annoying.
But it also raises another one - what if the user removes all options, or there are literally no items in a state requiring displaying and displays an empty list? Is it possible to have a 'zero list items' option?

I'm sorry because I feel like I'm asking a lot, but i also think this is a much more usable (esp for noobs) example of virtualising a list, so it may end up being widely used.

from react-virtuoso.

An updated example that's a much more like how I'm intending to use it.

The main issue has now been addressed with this super ugly code.

The issue with the list size continues, although is not as big an issue as the other one where items wouldn't hide, and then when we figured out how to hide them they wouldn't come back.

The ugly solution to that was to hold 2 lists in the state - one which is the full list, which then is reduced to the smaller list. The small list is that one that gets rendered and edited and if you need to remove items it removes them from the smaller list, if you undo removed items, then it grabs the full list, renders everything, but then needs to go and recalculate what should be shown again... not elegant, but it works. Just not sure how that will go with reasonably complex/intensive list items.

I believe this might be what was requested in #33 - a way to know what has changed when you remove/add/shuffle list items.

from react-virtuoso.

I investigated the issue over the weekend. The internal data structures which store the items' offsets get confused with zero-height items because I am using the item offset as an index. In a nutshell, there are more than one items occupying the same offset. I think this leads to the erratic behavior visible in your earlier example. Changing this implementation is far from trivial, and I don't have any real idea on how to do it without rewriting the internals.

At this point, I believe that keeping the original list and applying filters to it is the way to go. To help you further, I re-created the example you have posted above using hooks which I think resulted in a simpler looking code.

Apart from the issues with zero-height support, I think that keeping the filtering in the data/logic layer (hooks, redux, etc) instead of performing it in the visual components is a cleaner solution - of course, this just an opinion of mine.

Hope this helps,

from react-virtuoso.

Yeah, I figured it was likely to be a large issue, so thanks a million for looking into it.
In the meantime I noticed that my class-based version wasn't so good after all as it required the list item to edit the rendered list... which meant throwing a "Don't change state while rendering" error. The system worked, but not without problems.
I'm not so used to hooks and functional components, but can I safely assume this bypasses that issue?

from react-virtuoso.

I believe so, yes. Hooks are not that bad once you get the grip of them, the example I posted has a funny looking bit*, but everything else seems quite simple to me, at least. You should be safe with such approach IMO.

• the bit is related to useState accepting a function:

const randomShuffle = () => () => data => shuffle(data)

from react-virtuoso.

The issue is not solvable with the current size tracking data model - and I don't have a better one. Closing.

from react-virtuoso.