Commit graph

15 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
infinite-persistence
ec2bf26817
Fix flow for User/UserState 2022-03-17 13:12:18 +08:00
mayeaux
fb3a73d8a7
Membership subscriptions (#812)
Enter: Odysee Premium.
2022-03-09 13:05:37 -05:00
infinite-persistence
bfd4c3bcfd Fix sub-count reducer incorrectly rejecting data
We skip fetching IDs that were just fetched a moment ago, so the array size will be reduced, but the reducer was still expecting all items to be fetched, hence the array size mismatch
2022-03-01 10:50:07 -05:00
infinite-persistence
787ebd9588
Blacklist: use existing map instead of looping (#400)
We already have a pre-calculated map, but not used except for comments.

At the expense of pre-calculating it, the subsequent queries are instantaneous compared to the loop.

We are still not perfect in term of reducing re-renders, so this helps a lot.
2021-12-01 10:24:27 -05:00
infinite-persistence
0941667150
Cost Info selector fixes
- no memo required since they are just directly accessing the store.
2021-11-19 16:01:25 +08:00
infinite-persistence
b351617d2f
Add flow 2021-11-19 16:00:06 +08:00
infinite-persistence
e288833085
Fix blacklisted claims appearing in tiles
## Mistake
Tried to simplify the logic between checking Channel vs Content claim, and ended up always checking against Channel. This is correct for commentron blocklists, but not blacklists where the txid is per claim.

## Changes
- Restored original logic.
- While at it, restore the usage of `selectClaimForUri` (i.e. no need to split into 4 selectors anymore), since we've updated the reducer to prevent invalidation from things like 'confirmation' and 'is_my_output'.
2021-11-18 10:21:21 +08:00
infinite-persistence
dae0e3ccae
Use a lighter selector that doesn't re-create an array of claims.
Although selectClaimsByUri is memoized, it is often invalidated. Why create the array when all we need is the claim?
2021-11-16 10:47:59 +08:00
infinite-persistence
652ec4b69b
Fix memo: makeSelectViewCountForUri, makeSelectSubCountForUri
- switch to a lighter selectClaimIdForUri
- also, these 2 don't need to memo because they are just simple accessors.
2021-11-16 08:15:24 +08:00
infinite-persistence
cb6a044584
Support resume-able upload via tus (#186)
* Publish button: use spinner instead of "Publishing..."

Looks better, plus the preview could take a while sometimes.

* Refactor `doPublish`. No functional change

This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.

* Add doPublishResume

* Support resume-able upload via tus

## Issue
38 Handle resumable file upload

## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.

* Exclude "modified date" for Firefox/Android

## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.

## Change
Exclude modification date for now. Let's assume a smart user.

* Move 'currentUploads' to 'publish' reducer

`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.

We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).

This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.

* Restore v1 code for livestream replay, etc.

v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
2021-11-10 13:16:16 -05:00
infinite-persistence
5dd5826b33
doFetchSubCount: batch support; fetch interval gap;
1. The API supports batching -- updated the code to use that. Retained string as the parameter (instead of changing it to array) so that existing clients won't be affected.

2. Make `doFetchSubCount` a batched command by default through an idle timer. This way, none of the clients need to collect IDs -- it's all done behind the scenes.

3. Added minimum of 5 minutes between each sub-count fetch for a claim ID.
2021-10-28 13:16:06 +08:00
infinite-persistence
a90c516c71
Reduce impact of scanning blocklists (#121)
## Issue
- Each tile was checking against 4 blocklists (blacklisted, filtered, muted, commentron) on every render. Loading the front-page with Cheese alone caused 1400 calls.
- This is also part of the reason why pressing Back into the tile list takes forever.

## Fix
Since we still need to perform the checks at the app side for now, tried to memoize the operation through a selector.
2021-10-25 10:56:31 -04:00
infinite-persistence
27f346d8f1
Don't memoize selectors without transformation
It was not meant to be used for these cases -- wasting resources creating and going through the cache for each simple direct access.
2021-10-24 13:05:06 +08:00
Merge
30023422b8
Desktop cherry-pick: "7240 Integrate lbry redux and lbryinc" 2021-10-19 20:40:07 +08:00