Multiple virtuoso tabs preserving scroll (Slack-like application) - Best practice

[luap2703]

First of all thank you for the amazing library!

We are about to use react-virtuoso for a slack like application with multiple tabs, each having a chat message list (Prepending items + infinite scroll, making use of initialTopMostItem, firstItemIndex...)

So far so good, we were able to set up the list, infinite scroll + prepending items works almost perfectly BUT

we are completely stuck in preserving the chat scroll position when the user navigates to another chat (using nextjs router and changing the dynamic url path to the new chat_id).

Our approaches:

1. Storing the scroll positions in the context and reapplying it to initialTopmostItem the next time navigating back to the specific chat
   (2. Preserve the whole virtuoso list/page in a "keep-alive" -ish state and don't even unmount it when the user changes the page.)

We couldn't get either of the approaches to work and would be really curious about How you guys would achieve this?

Our current Virtuoso component looks as follows (if important), using chat.chat_id as the key to differentiate each list:

          ```

<Virtuoso
key={chat.chat_id} // chat.chat_id is basically the chat_id-key of the nextjs router.asPath
ref={virtuoso}
initialTopMostItemIndex={calculateInitialTopMostItemIndex(
messages,
highlightedMessageId
)}
firstItemIndex={firstItemIndex}
itemContent={item}
atBottomStateChange={(isAtBottom) => setIsAtBottom(isAtBottom)}
context={{ endReached }}
data={messages}
startReached={prependItemsHandler}
atBottomThreshold={100}
followOutput={followOutput}
components={{
Header: () => <Header context={{ endReached }} />,
}}
overscan={800}
increaseViewportBy={800}
style={{
height: "100%",
flex: "1 1 auto",
overscrollBehavior: "contain",
}}
/>

[petyosi]

Hey,

In case nobody from the audience here helps with your questions, I am happy to help you with your implementation should you choose to sponsor the project. There are several options I am happy with, including a one-time sponsorship.

Cheers,

[luap2703]

Hey Petyo,

Thank you for your reply and for sure we can do a one time sponsorship!!

I also added you to the repo - this is the file we are currently struggling with using the approach of caching the offset and index of the first (most top) rendered message (which is always a lot higher than the topmost visible message, due to overscan/increaseViewportBy to insure better scroll performance for some devices).

The saved state gets returned successfully and also scrolled correctly, but the offset is wrong, meaning that if some item heights are different (I guess measured by one exemplary item?) the offset is not correct and always slightly too much. Also we are not sure whether this is the best approach, looking at how we use the "key" value on the virtuoso instance and also the overscan/increaseViewportBy properties.

[petyosi]

@Paulo2703 after examining your setup, I can see that there's no reasonable way to implement location persistence with the APIs present in v4.2. The problem is not due to your implementation, or the overscan/increaseViewportBy, but due to the data set changes causing loss of previous measurement data. Your usage of the key attribute is correct, as technically, you're rendering a new list.

To address that, I just released v4.3 which has a new API that lets you to get / restore the component internal state - this includes the measured item heights and the scroll position. You can check how it works in this example. Check the getState ref method and the restoreStateFrom attribute.

Let me know if this works for you. Once I get some confirmation, I want to bring this example to the online documentation. You can also contact me over the email in my github profile.

[luap2703]

@petyosi wow, this is amazing!

We now got the state restoration to work completely flawlessly!

Thank you so much for your help and the great library.
We will surely test the solution even more in the next couple of days but so far this is just amazing, especially also considering other use cases, e.g., routing to a details page and coming back and others...

Without having tested this yet, are both functions also available for the grouped list?

[petyosi]

Great news, keep me posted if something goes wrong.

Re: grouped list. I just pushed a one-liner as I forgot to add the method to the TS typings for the grouped list, so it should be available shortly. The same technique should work there as well, but I haven't tested it yet.

[luap2703]

@petyosi
After running the example for a couple of days we encountered following issue (chances are high that this comes through our implementation and not by virtuoso itself ^^):

Right now we are combining the infinite scroll setup with the discussed restoreStateFrom functionality . The issue here seems that the restoreStateFrom fires again when the list prepends new items and therefore re-sets the state to the saved one. Taking your approach of only saving the state when the actual list completely destroys (I.e. when the channel changes) results in rejumping back to that state when the list prepends. This state is then of course not anymore up to date. We tried to continuously update the cached state by shooting the new state into the cache using the onScroll method (also see previous link) but this also has some issues, as it still causes some jiggle when prepending the list.
In case this makes sense and is indeed happening under the hood, I would suggest to only call the restoreStateFrom when the key changes but not when the list gets prepended.

Does this make sense and/or do you have another idea how to overcome this?

[petyosi]

@Paulo2703 While this sounds like a kind of bug I am prone to, I failed to re-create it in the example. I will need your further input to resolve the problem for you. Please bear with me.

Here's an updated version of the sandbox from above. It includes pre-pending items with the startReached callback.

How I test - I scroll a channel until older messages are prepended. Then I switch to another channel. Then I switch to the previous channel, scroll up until more are prepended, then toggle once more. It seems to be working for me.

Is there something that I am missing in the way I test? Or, perhaps, your setup is a bit different than the example? Can you fork the sandbox and change it so that the problem is reproducible there? We should be able to figure it out from here.

To address the details you've shared - the whole setup should not be so complicated. State should be cached once (upon component destruction) and restored once (when the component is mounted).

[luap2703]

@petyosi
This is an updated sandbox where I was able to reproduce the issue.

What I changed:
I wrapped your prependItems function in a 1sec timeout to simulate a network request.
(I also turned off increaseViewport to better demonstrate the difference when the user scrolls to the edge, but I receive the same results when it is on)

Reproducing the unwanted behaviour:

• Open any channel and scroll to the top to prepend once
• Now open another channel and do the same
• Now go back to the first one and paginate once more - Now the scroll behaviour doesn't seem to be correct as the position jumps

[luap2703]

[petyosi]

Yep, got it. just published v4.3.3 which fixes the issue, check a sandbox with v4.3.3.

[luap2703]

Amazing!! This works now just perfectly!