[Feature discussion] Allow keeping some elements mounted offscreen

[khovansky-al]

I’m working on integrating virtuoso into our chat history. We have a feature where text selection is synced across all participants in the room. Whenever a currently selected element is unmounted, the selection state is lost. FF fires a selectionchange event. Chrome and Safari don’t fire an event but the selection object becomes mangled.

The only reliable way to make this work with virtualization is by leaving the highlighted elements mounted when they go offscreen. If the key and the order of the persisted elements remains stable, React will not touch them, preserving selection.

I came up with a workaround that gives Virtuoso custom List and Item components and modifies children directly.
It looks something like this.

// Excerpt from `children` wrapper. This is a component that goes inside `List` (parts omitted for brevity)

// `children` is the original children array passed down by Virtuoso
// child index is taken from data-item-index
const firstRenderedChildIndex = getChildIndex(children[0]);
const lastRenderedChildIndex = getChildIndex(children[children.length - 1]);

// "parked" is how we call children that are invisibly rendered offscreen
const itemsParkedAboveViewport = parkedItemsIndexes
 .filter((index) => index < firstRenderedChildIndex)
 .map((index) => {
   return getParkedItem(index, context);
 });

const itemsParkedBelowViewport = <...same idea...>

return (<>
 {[
   ...itemsParkedAboveViewport,
   ...children,
   ...itemsParkedBelowViewport,
 ]}
</>)

const getParkedItem = (
   index: number,
   context: IVirtualRowContext,
 ) => {
   // get item from the context here

   // ChatVirtualListItem is the same component as we pass to Virtuoso to serve as Item
   // parked prop adds special styling that visually hides the element, moves it out of the way and makes it ignore pointer events
   return (
     <ChatVirtualListItem
       parked
       key={getVirtualRowKey(index, item, context)}
       data-index={index}
       data-item-index={index}
       data-known-size={1}
     >
       {renderChatVirtualItemContent(index, item, context)}
     </ChatVirtualListItem>
   );
 }

By keeping the component and the key same, React doesn’t move or touch the components that go offscreen in any way, preserving selection.
This is obviously pretty hacky. For example, Virtuoso complained about 0-sized elements so I made them 1px, and force data- props on them.
I don’t know if there is more child introspection happening internally which could be subtly broken by injecting children like this.
Would really appreciate if you could tell whether there is anything else to watch out.

Considering the case described above, would you be interested in having this officially supported by the library?
I am happy to make a PR but figured something like this would require discussing the API, scope and specifics of integration.
I prototyped this locally, adding a parkedItems prop to Virtuoso List mode and got children rendering in a similar fashion, but it was of course a quick demo and fully fleshed out implementation would need more thought on how to wire it with all the systems of emitters.

It’s a bit different from top items feature or footer items request seen in a different issue. In my proposal the items have to stay precisely within the “main” item collection to ensure React never moves the corresponding DOM nodes around.
Moving the DOM, even if it’s not explicitly removed but just reparented still causes loss of selection.

Let me know if you need more examples or an interactive demo to better understand what I’m trying to achieve here.

Thank you.

[petyosi]

Hey,

I'm not sure that I understand the feature in your chat (text selection being synced), but I am not your PM nor your users, so there's not much of a point to drill further.

To start with your question, I don't think that there's a realistic path towards making such a feature part of the library, especially in the shape you've outlined. People will use it for the wrong reasons. Let's see why:

First, you're probably aware of this yourself; using the DOM as a stateful source of truth for the state in React (especially with virtualization, but not only that) is a path of pain and bugs. I would focus on finding a way to "fix" that, perhaps by emulating a selection that can be kept in React state.

Next, as you have already guessed, what you're doing is not good for the Virtuoso internals, causes a huge performance hit, and, unless I am missing something, pointless. You're disabling the virtualization - why do you use virtualized components at all? The internet is full of tutorials for infinite, non-virtualized React lists. Maybe I don't see the full picture here, though.

Finally, here's an idea on how to hack the component more gracefully - use the increaseViewportBy property with some very high numbers. You can even manage those dynamically, extending the "rendered" zone based on some logic.

Hope this helps. My day job is also doing chats. It's one of those surprisingly complex domains - good luck with it.

[petyosi]

I see what you mean and I do understand that for your use case selection preservation can be an important requirement.

Preserving certain elements is, indeed, doable, but not trivial. I'm hesitant to mislead you towards promising that I can accept such a PR in the library, as this would need to touch some of the core aspects of the list state and the item measurements (the most obvious approach would be to put those preserved items offscreen and skip measuring them). At this point, I am quite conservative about introducing potentially breaking behaviors there.

But I don't want to discourage you from trying, as long as you don't expect me to eventually accept a PR :). Why don't you fork and try an implementation? You might come up with something simpler and more robust than I am imagining. I will take a look.

[hipstersmoothie]

Would love this feature too!

my use case: a virtualized drag and droppable list

[petyosi]

@hipstersmoothie Great! Are you planning on contributing it? I did not hear back from the original author.

[khovansky-al]

For the record, I ended up implementing this feature in userland. It's slightly complicated, but a little over 1.5 years later it's still going strong.
Didn't have time to attempt something that has a 95% chance of being rejected, seeing how our initial conversation went.

[Darren120]

@khovansky-al whats userland? can i get the github repo?