## Issues from the initial attempt
- There are 2 versions of `Lbry` and `buildURI` -- the app and web-server version. There are subtle differences between them, and for the app case, importing the web-server version results in a query into an invalid URL.
- It changed the function from returning a string to returning a promise.
## Changes
- Since the new function (renamed to `fetchStreamUrl` for clarity) is currently only needed for web-server, I moved it into the `web` folder to avoid misuse in app.
- Await on the promise. Unfortunately, this also means the entire chain of function calls need to be adjusted to be `async`.
## Issue 1263
Previously, we tried to inform the user that when an SDK call such as `support_create` and `publish` fails (specifically, timed out), the operation could be successful -- please check the transactions later.
However, we only covered the case of `fetch` actually getting a response that indicated a timeout, e.g. "status = 524". For our SDK case, the timeout scenario is an error that goes into the `catch` block. In the `catch` block, we can't differentiate whether it is a timeout because it only returns a generic "failed to fetch" message.
## New Approach
Since `fetch` does not support a timeout value, the usual solution is to wrap it with a `setTimeout`. This already exists in our code as `fetchWithTimeout` (yay).
By setting a timeout that is lower than the browser's default and also lower than the SDK operation (90s for most commands, 5m for `publish`), we would now have a way to detect a timeout and inform the user.
Firefox's 90s seems to be the lowest common denominator ... so 60s was chosen as the default (added some buffer).
For the case of 'publish', it is actually called in the backend, so wrap the xhr call with a timeout as well.
## Issue
1075, spam prevention.
## Approach
- When making a reaction, fetch reactions for all my channels for the particular comment id, and reject the reaction is any was found.
- Report the channel name in the toast so that user can at least know which channel to select in order to undo the reaction.
## Ticket
31: "quality selector not available on safari browsers"
## Notes
The quality selector isn't populated in some Apple products -- a known issue with videojs as the platform doesn't relay the info.
But it seems like only iPhone is affected, so let's enable the override for all platforms except iPhone.
## Ticket
Part of 1368 ("if user overrides the category homepage language with a different language setting + use 'search this language' option, use that instead. It's not typical this will happen, but probably expected.")
## Change
- Refactored to move more logic into `resolveLangForClaimSearch`
- Replaced the ternary version to make it more readable (hopefully).
- Inverted the language filter precedence by honoring the user's setting first.
- Note: for both User and Category, URLSearchParams will always take precedence.
Re-used lots of Anthony's code + made fixes to a few areas including the publish page.
a
new videojs
video.js@7.18.1 + http-streaming@2.14.2
remove console log
Mainly only useful for Wild West, which doesn't use `channel_ids` (otherwise, the homepage maintainer could just exclude the id from `channel_ids` directly).
It was previously done in `GetLinkData`, but accidentally removed in d854a992.
It is DRY-er to do it here rather than at the client side.
Also needed to filter in the homepage-sort dialog, so move the definition to a constant array.
pinnedUrls = resolve
pinnedClaimIds = claim_search
Make `pinnedClaimIds` take precedence for now, since the homepage is defining both to support Android.
For some reason, I previously made `pinnedUrls` the priority, thinking this should be the "correct" one to use when the SDK is fixed.
Expanded homepage pins to support 2 types of input (if both are passed in, pinnedUrls take precedence):
(1) pinnedUrls --> uses doResolveUris (resolve)
(2) pinnedClaimIds --> uses doResolveClaimIds (claim_search)
Instead of injecting the pinned URLs directly, we inject from `resolvedPinUris`, which will be blank until the uris are resolved, thus preventing it from being resolved individually from the tiles.
There's additional complexity with the `claim_search` method, as the rest of the code deals with uris instead of IDs. Fortunately, it's all contained with `useResolvePins`, so removal would be easier when the batch `resolve` issue is fixed.
Ticket: 1228
## Code changes
- Pass through `getTimeAgoStr` so that the value gets localized.
- Pass the simpler `number` around instead of the `moment` object for better memoization.
## Notable differences
Due to how `getTimeAgoStr` is written, we now get to see the time actually counting down, vs "in a few seconds" currently in production. I think the counting-down behavior was the original intentional, since a 1s timer was used (otherwise, a 1-minute timer could be used) ... or maybe not since streams may not start on the dot.
- Remove the need for an object key. Just use an array. It gets hard to maintain as more messages come in, and so far there is no need to access the configs directly.
- Just focus on handling the message and not creating a toast object. Leave the latter to the client.
Continuation of 1009 (2eae20f0)
It can probably be handled inside the existing getThumbnailCdnUrl to reduce 1 function, but since the functionality is somewhat different (the proxy doesn't compress), it's probably clearer to separate it.
* Factor out lighthouse-result processing code for FYP re-use.
The FYP results will be in the same format as LH.
* Recsys: add ability to pass in specific uuid to use
For FYP, we want to pass the UUID as a param when searching for recommendations. The search comes before the recsys entry creation, so we need to generate the UUID first when searching, and then tell recsys to use that specific ID.
* Redux: fetch and store FYP
Note that the gid cannot be used as "hash" for the uri list -- it doesn't necessarily change when the list changes, so we can't use it to optimize redux. For now, just always update/render when re-fetched.
* UI for FYP
* Mark rendered FYPs
* Pass the FYP ID down the same way as Collection ID
Not ideal, but at least it's in the same pattern as existing code for now. The whole prop-drilling problem with the claim components will be fixed together later.
* Include 'gid' and 'uuid' in recommendation search
* Allow users to mark recommendations that they dislike
* Pass auth-token to all FYP requests + remove beacon use
beacons are unreliable and often blocked
* Only show FYP for members
* FYP readme page
* small fixes
* fyp
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
This is a follow-up for #1016
Still doesn't affect anything at the moment, but this reduce the amount of work needed when we yank out the homepages from our bundle later.
## 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`.
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.
* 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`
