* Playlists v2
* Style pass
* Change playlist items arrange icon
* Playlist card body open by default
* Refactor collectionEdit components
* Paginate & Refactor bid field
* Collection page changes
* Add Thumbnail optional
* Replace extra info for description on collection page
* Playlist card right below video on medium screen
* Allow editing private collections
* Add edit option to menus
* Allow deleting a public playlist but keeping a private version
* Add queue to Save menu, remove edit option from Builtin pages, show queue on playlists page
* Fix scroll to recent persisting on medium screen
* Fix adding to queue from menu
* Fixes for delete
* PublishList: delay mounting Items tab to prevent lock-up (#1783)
For a large list, the playlist publish form is unusable (super-slow typing) due to the entire list being mounted despite the tab is not active.
The full solution is still to paginate it, but for now, don't mount the tab until it is selected. Add a spinner to indicate something is loading. It's not prefect, but it's throwaway code anyway. At least we can fill in the fields properly now.
* Batch-resolve private collections (#1782)
* makeSelectClaimForClaimId --> selectClaimForClaimId
Move away from the problematic `makeSelect*`, especially in large loops.
* Batch-resolve private collections
1758
This alleviates the lock-up that is caused by large number of invidual resolves. There will still be some minor stutter due to the large DOM that React needs to handle -- that is logged in 1758 and will be handled separately.
At least the stutter is short (1-2s) and the app is still usable.
Private list items are being resolve individually, super slow if the list is large (>100). Published lists doesn't have this issue.
doFetchItemsInCollections contains most of the useful logic, but it isn't called for private/built-in lists because it's not an actual claim.
Tweaked doFetchItemsInCollections to handle private (UUID-based) collections.
* Use persisted state for floating player playlist card body
- I find it annoying being open everytime
* Fix removing edits from published playlist
* Fix scroll on mobile
* Allow going editing items from toast
* Fix ClaimShareButton
* Prevent edit/publish of builtin
* Fix async inside forEach
* Fix sync on queue edit
* Fix autoplayCountdown replay
* Fix deleting an item scrolling the playlist
* CreatedAt fixes
* Remove repost for now
* Anon publish fixes
* Fix mature case on floating
Co-authored-by: infinite-persistence <64950861+infinite-persistence@users.noreply.github.com>
## Issue
- Closes "1535 bunch of channels (from featured?) resolved on page load"
- It was due to the use of reposts in the Category. As we did not store the repost's original channel claim, `ChannelThumbnail` couldn't find the author and requested a separate `resolve`.
## Change
Store the repost's original channel claim as well.
- and some changes to activeLivestream redux since it would return undefined if fetching and no claim, so now it returns null when no activeLivestream is found
## Issue
Ticket: 108
## Interesting
Uploads Page uses `claim_list`
Channel Page uses `claim_search
A second `claim_list` would instantly show updated results, but `claim_search` takes a long while to reflect the deletion.
## Change
This PR only handles the `claim_list` (Uploads Page).
The `claim_search` version would be troublesome to handle. If a refresh would bring back the results (due to the `claim_search` slow update behavior), we would need to store the deleted claim persistently. Then ...
- Store where? rehydrate?
- When to clear?
- How to make each `ClaimList` filter this out without polluting the code? etc.
...will be messy. Feels easier to "fix" at the `claim_search` level to make it update faster (maybe a command to clear cache at server or something).
## Ticket
lbry-desktop 6841
## Issue
If you are already at the homepage and you click the "Home" or "Odysee" logo again, the entire page reloads, causing the whole startup sequence to re-run (lots of fetches).
This can be annoying when not intended (e.g. clicked too many times), as startup is slow for some and we also lose non-persistent Redux data (for debugging).
I believe the requirement was just to reload the homepage tiles, as they might be showing stale ones after a while. A full reload was the quick-and-easy fix.
## Approach
Best not to touch the complicated `ClaimTilesDiscover`, so just clear the search cache key in this scenario. `ClaimTilesDiscover` will then pick this up and perform a new `claim_search`.
## Issue
- selectMyActiveClaims memo problem -- being recalculated on every click -- high workload for wallet with large uploads.
- Mistake in handling abandoning IDs (it was trying to extract keys from an array)
## Changes
- selectAbandoningIds: never use `state` as an input selector. Breaks memo.
- Don't use selectMyClaimsRaw and then reduce it back to IDs. Use selectMyClaimIdsRaw instead.
- selectAbandoningIds is already in array form, so don't run Object.keys.
- Fix abandoningById never clearing when succeeded.
* Don't update 'pendingById' if no changes.
'pendingById' isn't frequently updated, but using it as a proof-of-concept to fix how reducers should be written to avoid unnecessary updates.
ImmutableJS apparently does all of this for us, but there are cons to using it as well, so using own wrappers for now.
* Don't update 'byId' if no changes + add 'selectClaimWithId'
## Ticket
116 Claim store optimization ideas (reducing unnecessary renders)
## Changes
- Ignore things like `confirmations` so that already-fetched claims aren't invalidated and causes re-rendering. The `stringify` might look expensive, but the amount of avoided re-renders outweighs it. There might be faster ways to compare, though.
- With `byId[claimId]` references more stable now, memoized selectors can now use 'selectClaimWithId' to pick a specific claim to depend on, instead of 'byId' which changes on every update.
* Fix memo: selectMyChannelClaims, selectActiveChannelClaim
## Issue
These should never recalculate after `channel_list` has been fetched, but they do because of poor selector dependency.
## Change
With the `byId` changes from the previous commit, we are now able to memoize these selectors correctly.
