Subscriptions overhaul #1872
Labels
No labels
accessibility
app-parity
area: creator
area: daemon
area: design
area: devops
area: discovery
area: docs
area: installer
area: internal
area: livestream
area: performance
area: proposal
area: reposts
area: rewards
area: search
area: security
area: subscriptions
area: sync
area: ux
area: viewer
area: wallet
BEAMER
channel
comments
community PR
consider soon
core team
css
dependencies
electron
Epic
feature request
first-timers-only
good first issue
hacktoberfest
help wanted
hub-dependent
icebox
Invalid
level: 0
level: 1
level: 2
level: 3
level: 4
merge when green
needs: exploration
needs: grooming
needs: priority
needs: repro
needs: tech design
notifications
odysee
on hold
playlists
priority: blocker
priority: high
priority: low
priority: medium
protocol dependent
recsys
redesign
regression
resilience
sdk dependent
Tom's Wishlist
trending
type: bug
type: discussion
type: improvement
type: new feature
type: refactor
type: task
type: testing
unplanned
windows
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: LBRYCommunity/lbry-desktop#1872
Loading…
Reference in a new issue
No description provided.
Delete branch "subscriptions-overhaul"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Epic #1861
SUBSCRIPTION_DOWNLOAD_LIMIT
from 1 to 3 and apply limit to total downloads rather than per-channel*redux-persist
's<PersistGate>
component/feature so actions are dispatched once redux has been rehydrated. This requires upgradingredux-persist
from version4.x
to5.x
. There is a migration guide.*As it was, the app would download the limit (1) for each channel which could be too much if a user is subscribed to many channels. One issue with this approach is that it will dispatch downloads in the order it iterates through subscriptions. To fix that would require calling all the endpoints, flattening the data, and choosing which ones to download. I found this to be a reasonable compromise for when a user opens the app and may have lots of new content available. Any new content that is prevented from downloading this way still creates a
NOTIFY_ONLY
notification, adding to the badge count next to Subscriptions. We may want to allow a user to determine the value ofSUBSCRIPTION_DOWNLOAD_LIMIT
.One weird thing about this @seanyesmunt
I'm using the existing reducer
FETCH_CHANNEL_CLAIMS_COMPLETED
to update the claim info so it will show on the subscriptions page; the lack of doing so was causing the main quirk in all this #1734 . I am not usingFETCH_CHANNEL_CLAIMS_STARTED
because that prevented the subscriptions page from even loading. The code I started with dispatchedCHECK_SUBSCRIPTION_STARTED
andCHECK_SUBSCRIPTION_COMPLETED
which had no reducers and thus did nothing.A few minor comments but looks good. Will need to do some testing before merging.
This should reference that it is for subscriptions.
Automatically download new content from your subscriptions
? That might be a little long@ -138,7 +139,7 @@ export function doUpdateLoadStatus(uri, outpoint) {
0
I think the idea behind snackbars is that they are reserved for user actions, which wouldn't make sense for this use case. Maybe we should create our own notification component that mimics desktop notifications but has some additional style.
Not needed for this PR but I think we should stick with the OS notifications for now.
I think this should default to
true
. Users can turn it off if they want.Found one issue (still testing).
Possibly we should look at the date you subscribed to a channel, and if it is newer than that, then show the notification/download? Not sure.
The badge 9/10 thing is because of how that number is calculated. It's the count of all notifications that are not
DOWNLOADING
, so justNOTIFY_ONLY
andDOWNLOADED
. I think counting downloading files as notifications seems like a good fix.I think that number is ok, but it should only show the badge if it's actually new content, not just the first page of content on an old channel that I subscribed to.
In this case:
@seanyesmunt and I also discussed exposing the autodownload setting on the sub page too.
Is autodownload on startup supposed to work with the hack? When I go into a claim I'm subbed to (and not downloaded), I see it starting to download automatically - is this intentional?
We should incorporate the download limit as a setting if we are going to impose it. I think it would also work better as a per channel instead of across all subs setting.
Encountered this error running this branch: