The stalling behavior has changed a bit, probably with the removal of CF.
The stall difference between 10MB and 50MB is not too noticable, so picking 25MB as a start.
## Issue
312 Save notification on back navigation, enable filter on mobile
## Changes
- Don't clear then filter when mounted and there are unread notifications.
- We previously clear the filter because the user could be clicking the notification bell (which is showing some number) and we ended up with a blank page because of the filter.
- Allow the filter in mobile.
- Previously, it was intentionally removed for mobile (see bd42418f). I believe it was just because we don't have the style set up for mobile. Here's my quick attempt.
## 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'.
## Issue
One of the bottlenecks of livestream page.
The component probably needs a re-design:
- Don't perpetually mount -- only mount when activated by the user through "@". This would avoid the heavy processing entirely.
- Better way of resolving uris (too many arrays, too many loops).
- Tom also mentioned that we should not be resolving every commenter as we see encounter them in a livestream. This is currently the case because the component is always mounted.
## Changes
Until the re-design occurs, attempt to cache the heavy processing. Also, trimmed down the amount of loops.
For the case of livestreams, the comments are added incrementally via websocket. The selector returns everything, which grows as a user watches the livestream.
We could even make it a bit more efficient by passing in `maxCount` to `filterComments`, and do a `for` loop there, but decided to keep things readable by not changing the `filter` usage.
As long as the input parameters are the same, the selector will return the cached value so that we don't construct the list twice, which involves blocklist filtering.
`<div>` cannot be a descendend of `<p>`, and `{subtitle}`s sometimes need to have `<div>`s.
Just switch from `<p>` to `<div>`, and let the client decide when the actual text paragraphs are.
## Issue
Lots of time is spent mapping the state to props for this component (since there are lots of tiles).
## Changes
Using this component as a starting point, go through the selectors and make the usual cleanup/fixes:
- Move away from the `makeSelect*` model, which creates a new selector on every call instead of actually re-using the cached version.
- Do proper caching for multi-param selectors using `re-reselect`.
- Don't cache simple functions or direct access to states.
- Memo not required. `resolvingUris` is very dynamic and is a short array anyways.
- Changeg from using `indexOf` to `includes`, which is more concise.
## Issues
- 251 Dragging the floating player is super laggy
Recent changes and/or refactoring combined the effects or added dependancies into the effects, causing them to re-run excessively.
## Changes
- Restored effects to their original behavior.
- Don't perform the position check when dragging -- only do it when released.
- Do proper debouncing for the 'resize' listener -- the previous method was incorrect as a new function is created on each render.
## Changes
- doHandleSyncComplete: only call doGetAndPopulatePreferences when there is new data.
- But for that to work, we'll need to populate preferences at least once. We'll do that in doSignIn.
- We can also remove the "sync/prefs ready" mechanism that was mainly meant for Desktop.
Then came another problem: while trying to spark changes between 2 tabs, `sync/get` was saying "no change" despite the local and server hash being different. I think it is because the both `sync_hash + sync/get` combo is operating on server data, so the hash is the same. I'm guessing this is why we ended up just running doGetAndPopulatePreferences every time before PR, since this flag wasn't correct in this scenario.
- Updated `data.changed` to consider both API results and comparison with local hash.
## Issue
When the muted list was being cleared from another app, the web version ended up restoring the previous muted list.
## Change
- As long as `blocked` is defined, return that since an empty array is a valid result.
- If undefined, something went wrong when calling the reducer, so retain the muted list. I believe this was the original intention of that line.
* Exclude default homepage data at compile time
The youtuber IDs alone is pretty huge, and is unused in the `CUSTOM_HOMEPAGE=true` configuration.
* Remove Desktop items and other cleanup
- Moved constants out of the component.
- Remove SIMPLE_SITE check.
- Remove Desktop-only items
* Sidebar: limit subscription and tag section
## Issue
Too slow for huge lists
## Change
Limit to 10 initially, and load everything on "Show more"
* Fix makeSelectThumbnailForUri
- Fix memo
- Expose function to extract directly from claim if client already have it.
* pull out ads into its own file
* final touchup
* pull out lbry volume class
* using curried function
* coming along well
* almost done keyboard shortcuts
* pulling the guts out
* finishing keyboard shortcuts
* coming along well
* running but needs some testing
* almost done but could still use some testing
* all code working with some flow fixes needed
* fixing flow errors
* finishing flow errors
## Issues with `makeSelectIsSubscribed`
- It will not return true if the uri provided is canonical, because the compared subscription uri is in permanent form. This was causing certain elements like the Heart to not appear in claim tiles.
- It is super slow for large subscriptions not just because of the array size + being a hot selector, but also because it is looking up the claim twice (not memo'd) and also calling `parseURI` to determine if it's a channel, which is unnecessary if you already have the claim.
## Changes
- Optimize the selector to only look up the claim once, and make operations using already-obtained info.
## Issue
The status = 0 is due to unresponsive backend right after the tus-upload. No root-cause found yet.
## Change
It may or may not help, but adding a delay to account for the unresponsive stage for now.
