List-layout is not scrollable, and doesn't look good either. Force to tile-only until we can fix it. If we decide to always use tile-only, then remove the parameter for ScheduledStreams.
- `filteredSubscriptions` was running the filter code whether or not it actually required filtering, because the `!subscriptionFilter` logic is placed in the predicate. While it is a clean one-liner, it is slow when the subs list is huge.
- While at it, moved the code into `getSubscriptionSection` to isolate things.
- The sidebar was resolving the entire subs list, which is super slow for a list of 500+. Since we now have a "Manage Subscriptions" page, just batch-resolve the N visible subs.
- TODO: the code should probably be moved from 'app' to 'sideNavigate'.
The idea of using claim_search to indirectly batch-resolve didn't work out well. There's something wrong with the claim_search pagination where some results are duplicated in multiple pages, while some are missing. It's also returning less results that than the given number of claim ids, so sometimes the infinite scroll breaks.
The `useDualLayout` junk is super confusing to maintain and no longer extensible.
At the expense of making the "livestream + regular" list no longer seamlessly continuous when expanded (or when there just a handful of livestreams), use the new `subSection` feature to inject the livestream tiles. This is far easier to manage and tweak.
## Issues
1. We were manually adding `selectLanguage(state)` as a prop to components used in Settings Page to trigger a render. Flaws:
- Unclear that the unused prop is just to trigger a render.
- Manually adding on a case-by-case basis will break over time, especially when language can now be changed outside of the Settings Page.
2. The translation file fetching is delayed and also takes time, so the GUI will end up having mixed strings on F5, depending on when the fetch completed.
## Approach
Make the app wrapper have a key that's tied to the language and translation data, so the entire app renders when language changes. Seems like a common design in most apps.
## Ticket
921 language refresh / selection issues
## Ticket
968 Truncate views/subs in other areas
## Changes
- Corrected logic for `minThresholdToApply`, which was ignoring the case of "no threshold", causing it to not be truncated in Channel Page. We want to always truncate there due to the smaller cards.
- Missed out handling `ClaimPreviewSubtitle`.
The function argument order can be a bit ugly, but putting it at the back as optional param makes it easier to test without affecting existing clients.
## Ticket
948 wildwest: always show boosting message, move next to category name
## Changes
1. Make "Show less livestreams" share the same space as "Boosted by LBC", instead of only showing either 1.
- It's a bit troublesome to move it next to the filter without tweaking the generic `ClaimListDiscover`, so I think this would be a good compromise.
2. Fix "show less livestreams" being super tiny in mobile.
- I think it is caused by some component-specific changes are being applied at the global level (not sure).
* Bump react-draggable
Old version was giving out console errors for outdated react functions
* Refactor fileRenderFloating
* Merge fileRenderMobile into fileRenderFloating
* Fixes from review
* Attempt fix failed to view live
> _Max date it can do is back to : 2022-02-08 - so don't allow a days value that's higher than this. (hint before selection / submission if possible)_
My initial understanding was that it is ok to set beyond this date (e.g. "1 year"), just that any channels created before Feb 7 will still be able to comment even if they are less than a year old. That feels like ok behavior to me (easier for user to grasp), but turns out setting anything before that date will block all channels.
So, this commit changes the warning message and also blocks the user from finalizing.
This reverts commit b3c4ce05fa.
The suggested 2-list approach broke the search bar because the bar is part of the list, so it gets unmounted while the user is typing. Oops.
* Band-aid: warn about AdGuard blocking our CDN
Getting 50-100 errors per day. This will be a band-aid until the AdGuard fixes it.
* update message
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
* Move into getLocalStorageSummary + always log
- Move into getLocalStorageSummary to clean up the clutter.
- Always log the localStorage info to get a bigger picture of what's going on with the QuotaExceededError.
* Remove 'findPreviousUploads' - we use the url stored in Redux.
Something I forgot to remove in the past. It also reads from localStorage, so remove since we are trying to avoid touching localStorage.
* Ensure localStorage is not used when uploading
I don't think it's being written when `storeFingerprintForResuming` is disabled, but doing the suggestion nonetheless.
`https://github.com/tus/tus-js-client/issues/315#issuecomment-1046821112`
## 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`.
## Root-cause?
It doesn't happen on the commit before the Theme change. However, it's possible that the y-pos is reset since we are indeed unmounting the dual list and re-mounting the single list.
Maybe the css got more efficient and we ended up painting more frames than before.
## Fix
Fix by stashing and restoring the the y-position during the expansion.
