Stop using image-avatars in huge rooms

[nickvergessen]

Steps

1. Create 1k users and add to a dummy group:

#!/bin/sh

php occ -vvv group:add "dummies" --display-name "1k dummies"

i=10
while [ $i -ne 1000 ]
do
        i=$(($i+1))
        echo "$i"
        
        
	USERID=$(uuidgen)
	OC_PASS="123456" php occ -vvv user:add --password-from-env --display-name "Dummy #$i" -g "dummies" $USERID
done

2. Create a new conversation and invite the group as attendee
3. See your browser die as it requests the 1k avatars for the participant list and the chat log.

Thoughts

At some point certain things make no sense anymore, so there are some thoughts:

• Requesting 1k images as avatars in a sidebar that is not usable
  => I think we could fall back to the 2 letter js solution?
• Starting with 1k system messages that an individual user was added
  => Skip the list when you are adding a group/circle at the moment and assume it is okay to only list the group name
• Stop automatically refreshing the participant list
  => instead have a manual button?
• Listing all participants
  => There is a search already, so maybe we just show moderators and a label "X participants" until a search term is used

[PVince81]

For the participant list and avatars, one idea was to switch to virtual scrolling, so that images are not being loaded yet at the same time.
There are other ideas there like using "observe-visibility" to not load the image, but that wouldn't be enough for a list of 1000 participants as the scrolling would slow down still.

Agreed for shortening / aggregating system messages when adding multiple users or big groups.

Are we using etag / not modified right now for the participant list when automatically refreshing ?

[nickvergessen]

Are we using etag / not modified right now for the participant list when automatically refreshing ?

No, but sounds like a good idea to do.

For the participant list and avatars, one idea was to switch to virtual scrolling, so that images are not being loaded yet at the same time.

So yeah, if that's easily doable let's do it. Limiting the shown list I can do easily with a filter on the store :P

[PVince81]

Limiting the shown list I can do easily with a filter on the store

Indeed, that's another possible approach: only render the first 20+ entries and then when scrolling down render the next batch.
The drawback is that if you scroll far enough you'll end up having all 1000 entries in the DOM so it will slow down the further you scroll. It would solve the "too many requests" issue though.

Needs further research about how difficult it will be to use virtual scroll. The good thing is that we have a fixed height which is an important prerequisite. I can imagine potential troubles with the popup/tooltip and with accessibility.

[marcoambrosini]

too many requests --> lazy loading
too many dom elements --> virtual scroller

These can and should be addressed separately imo. Virtual scroller should be relatively easy for fixed height elements

[nickvergessen]

too many requests --> lazy loading
too many dom elements --> virtual scroller

Yes, but I think it also makes sense to not give a virtual scroller with 1k items. Prefiltering the list to a useful subset is another step forward.

[PVince81]

it doesn't make much difference whether the list is paginated/filtered on the Vue store side or whether we give the list to the scroller and the scroller does it on its own, unless the virtual scroller operates on a copy... in the latter case it would indeed be overkill to duplicate / reformat the entries :-/

[nickvergessen]

cc @ShGKme @Antreesy is the infinite scrolling of the left sidebar reusable for the right sidebar?

[ShGKme]

cc @ShGKme @Antreesy is the infinite scrolling of the left sidebar reusable for the right sidebar?

Yes, we can easily use the same external component RecycleScroller.

There is no need in new <ConversationsListVirtual> wrapper, it only has properties and additional methods useful for left sidebar and conversations (aka scroll to conversation).