Commit graph

10 commits

Author SHA1 Message Date
Rafael Saes
83dbe8ec7c
Playlists v2: Refactors, touch ups + Queue Mode (#1604)
* 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>
2022-07-13 10:59:59 -03:00
Rafael
65b9906086 Add dynamic player aspect ratio resizing 2022-04-07 11:44:25 -04:00
Rafael
b096aad70e Improve livestream claimLink embeds
- Remove embedPlayButton for fileRenderInitiator
- getThumbnailFromClaim from utils function instead of redux
- Improve playingUri
2022-03-16 16:36:50 -04:00
Rafael
c1b84368a9 Fixes
Rename FileReactions index import

Fix fileAction undefined logic

Fix live comment menu

Fix superchats
2022-02-08 12:35:40 -05:00
Rafael
ce11a4b9c1 Use modal for tip selection 2022-02-08 12:35:40 -05:00
Rafael
bc68207f40 Refactor fileTitleSection
- selectInsufficientCreditsForUri unused
- used util function instead of redux selector for title
- only pass needed claim props
2022-02-08 12:35:40 -05:00
infinite-persistence
dcd93af6eb
Fix inability to unblock an abandoned claim
The recent change to parse the channel from a Repost using a `claim` ended up breaking the case for abandoned claims, which `claim` will be `null`.

Fix by looking at `claim` first (faster), and falling back to the `parseURI` method if it remains inconclusive.
2021-12-01 21:21:09 +08:00
Merge
30023422b8
Desktop cherry-pick: "7240 Integrate lbry redux and lbryinc" 2021-10-19 20:40:07 +08:00
infinite-persistence
23f273356a
Explain that "Block" leads to modal with more options. (#7039)
## Issue
7035 Make it clearer that delegated mods can block via Block menu
2021-09-08 12:31:45 -04:00
infinite-persistence
e9a2f44899
Commentron: incorporate 'setting.Get' into 'doFetchCreatorSettings'
## General
- `setting.List`: returns full creator settings. Requires signature (i.e. you own the channel)
- `setting.Get`: returns a public subset of the creator settings. No signature required, and it is mainly used by the GUI to determine the constraints of a channel (e.g. comments enabled? min tip requirements? etc.). Does not include private settings like "blocked words list".

`doFetchCreatorSettings` will handle both of these. Clients that uses the stashed results (`settingsByChannelId`) just needs to be aware the result might not contain everything, depending on whether you own the channel or not.

## Misc Related Changes
- Finally fix the reducer for COMMENT_FETCH_SETTINGS_COMPLETED to not purge the data on each call.
- Change `doFetchCreatorSettings` to operate on a single channel instead of multiple. We ended up not using the multple mode anyway, so it was wasteful code trying to batch the promises.
- `commentsDisabledChannelIds` is no longer needed. Previously, this was created just to differentiate between Creator (full) and Channel (subset) settings. It's cleaner to just use one object, so eliminated this.
- Remove unused 'commentingEnabled'.

## Aside
- There are now 2 ways to know if a channel has disabled comments: (1) from `comment.list` and `setting.Get|List`. Both of them updates `settingsByChannelId`, so it'll still be a single place for the GUI to check against.
2021-08-12 14:51:41 +08:00