Adding Item to Watch Later List Causes Frontend to Freeze

[Loweville]

Bug
When adding item to Watch Later list, the entire frontend freezes as it processes the action

To Reproduce
Steps to reproduce the behavior:

1. Go to any video preview element
2. Click on 'Watch Later'
3. Observe time to process task

Expected behavior
The site is still fully responsive and allows you to interact with anything like normal

Screenshots
N/A, not screen-shotable

System Configuration

Website (Odysee.com)

• LBRY Daemon version: N/A
• LBRY App version: N/A
• LBRY Installation ID: N/A
• Operating system: Linux

Additional context
I see that the Watch Later function utilizes react-redux's connect function, and the doPlaylistAddAndAllowPlaying function issues a dispatch request, I was wondering if there could be an opportunity to utilise Javascript Promises to allow it to run asynchronously, therefore it wouldn't freeze the frontend as the action was being performed.

[tzarebczan]

@keikari can you reproduce and take a look to see if there's any quick improvements possible?

[tzarebczan]

@Loweville Thank you for this report! Are you a dev and would potentially want to take a shot at it also?

[keikari]

I can see some freezing, from slight hiccup to seconds of freeze, depending of how many preview tiles have been loaded.

I'm not 100% sure, but I think the doPlaylistAddAndAllowPlaying is already ran asynchronously and not the real culprit here.

And I think the actual issue is with redux store being updated multiple times while that is running, and when there are lot of preview tiles checking for new values from the store, it gets really heavy.

Freezes get noticeably worse when scrolling down in some category. (Page 1 = ~60ms/render, Page 5 = 180ms/render)

Adding an item to Watch later 3 times on the page 1:

Adding an item to Watch later 3 times on the page 5:

If I'm correct about the cause:
ChatGPT says that react-window could be used so that only the items that are actually showing on the page get rendered. That sounds like something that can help to prevent worst cases of this.
Will see if I can figure out the usage of that, and if it makes anything happen.

[keikari]

On initial testing using react-window does help with the performance, but not sure how to make it work properly.

[Loweville]

Hello, It's been a while. @tzarebczan, While I am a developer, I'm afraid I haven't got the time, nor am familiar enough with react to contribute to this issue.

I was also just wondering how this is progressing, I know these things tend to take time, no rush 😆

[keikari]

Hello, and thanks!

If I recall right, I think I left it doing the doFetchItemsInCollection on every edit as it didn't seemed slow, but pretty sure it didn't actually need it. So that one should be simple.

This should work just the same, and only does it once per list: #3185
(But I don't think I see that much of a difference in performance.)

I'm still blaming the tiles, since on first page I basically get no lag(maybe a very minor hiccup) when adding an item to a list of a 100 items.
But if I scroll down the lag with adding an item gets more noticeable.

This is kind of a lag I'm seeing (from local instance)

Video

playlist-lag.mp4

[infinite-persistence]

Any chance that the 2 dispatches with long names don't need that specific call sequence, i.e. can either be batchActions-ed with COLLECTION_EDIT, or even just let COLLECTION_EDIT do it through an additional param[]?

That's at least a band-aid to reduce the lag from increasing threefold for each extra tile (seeing ~4s down to ~0.5s, as an example)

[keikari]

Moved them in COLLECTION_EDIT(same PR). Does seem noticeably better now!