The code currently supports both the baked-in homepages, as well as fetching from `/$/api/content/v1/get`.
As the latter is currently a circular round-trip, just use the baked-in version until the service is moved elsewhere. Loading performance will be better.
Potentially closes 1319
## Note
- `persistor.purge` returns a promise, we should wait for the resolved results before reloading, instead of just adding an arbitrary `setTimeout`.
- Perhaps the `setTimeout` method is to ignore a super-long or hanged purge (not sure), but it wouldn't be right since it would end up in a limbo state.
- Log errors to get clues for future.
- Reduced code by moving the reload to `finally`.
## Change
Due to "Own Comments" being implemented the same way as "Discussion Page", the comment lookup did not work for the abandoning case.
Just skip the local cleanup of `byId` -- it doesn't matter, as the GUI uses `selectCommentsForUri` to grab the per-channel comments, so it would still disappear in the GUI immediately.
## Issue
Ticket: 108
## Interesting
Uploads Page uses `claim_list`
Channel Page uses `claim_search
A second `claim_list` would instantly show updated results, but `claim_search` takes a long while to reflect the deletion.
## Change
This PR only handles the `claim_list` (Uploads Page).
The `claim_search` version would be troublesome to handle. If a refresh would bring back the results (due to the `claim_search` slow update behavior), we would need to store the deleted claim persistently. Then ...
- Store where? rehydrate?
- When to clear?
- How to make each `ClaimList` filter this out without polluting the code? etc.
...will be messy. Feels easier to "fix" at the `claim_search` level to make it update faster (maybe a command to clear cache at server or something).
Ticket: 1256
For `notify`, "file is currently locked" and "no such file or directory" is indication that the previous "failed" SDK call actually worked. Tell the user to check the transactions.
This is the band aid until odysee-api/401 is addressed.
## Issue
Accumulation of so many strings for a "successful tip" that it is getting annoying to re-translate them for minor changes.
## Change
- Consolidate and re-use strings.
- Make the tip string currency-agnostic so we don't have to touch it again. The amount and currency is moved to the `subMessage`.
- Fix spacing being incorrectly enforced through i18n (it should be done via code/css).
Ticket: 1189
## Issue
There is a bug in a batched `resolve` that returns jumbled data. Temporarily switch to `claim_search` until that is fixed.
## Notable differences:
- `resolve` will tell us directly that a claim has been removed or filtered, so redux will mark the ID as such. `claim_search` simply returns nothing, so we will still end up with an extra `resolve` for these items when the component tries to display it.
- The new function currently does not handle Collections (i.e. resolving individual items in the Collection) and Reposts. Given that this is temporarily, I'd like to leave `doClaimSearch` as is, instead of trying to replicate what's in `doResolveUris`.
## Notes:
Since we don't care if the resolve fails (and we weren't doing anything in the `catch` anyways), use `finally` instead.
- 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.
- Remove the odd resolve call that's lingering in `App`. Feels out of place, plus we don't need it now since the "active subs" claim search would contain resolved results.
- Don't search for active subs if Following count is zero.
## Issue
- Errors like "unexpected token at..." and "failed to fetch" are being logged, rather than the actual call error.
- Publish SDK timeout is sometimes successful, but the user doesn't know, so they re-created the same claim
## Change
- Attempt to make the logs more helpful, and the error message more meaningful to the user.
- Starting off with 'publish' and tip SDK call as an experiment. Can add others if this method works.
Was trying to save 1 state by assuming the homepage will be in a busy state and the ad-detection code will finish first. But this is not true for those with a small Following count.
* 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>
Ticket: 1079 Support geoblocking channels/videos
## Changes
- Replaced the .env version with iapi version.
- Includes 'videos' blocking and custom messages.
* Add last used collection to right click menu.
* Small fix for last used collection when it's a published collection.
* Update last used collection when a collection is pending or published.
* Small refactor to get the last used collection.
We need to store the resolved claims first before marking COLLECTION_ITEMS_RESOLVE_COMPLETED, otherwise the GUI still sees undefined claims.
798 just accidentally flipped the order due to refactoring, I believe. It's now back to original.
## Cause
When 'selectRecommendedContentForUri' is filtering results against the blocklist, it relies on claim data which could be unresolved yet. It filters to empty results for this scenario, hence the flashing message.
## Change
Just return raw results when claims are not resolved yet, so that the GUI knows it needs to show the placeholders while resolving. After resolving, it'll go through the blocklist filtering again.
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.
Currently, homepages are still build as part of the app, so this change doesn't bring much benefit other than to support the wrapper app.
When the service is moved away from the app, we won't have to rebuild the app when homepages change, and also the ui.js bundle would be smaller without the need to code-split.
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.
* 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
* 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>
## 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`.
## Issue
534 prevent new channel creation over x channels
## Notes
Also handled from the API call (`doCreateChannel`) in case there are other UI components that create channels.
- The previous 2MB was a CDN limit (more of a mistake). That has been increased to a far greater number, so we're setting a more reasonable 5MB limit.
- The previous code checks/shows the "size exceeded" message after the file has been uploaded ... in the `catch` block. This will not work since the CDN now allows a 5MB file.
- Fixed by checking the size before actually uploading.
- CommentsList needs to return a title with comment amounts
- mobile player dimensions needed to fill in the cover
- hid livestream header for now until figuring out a better presentation
- ~colum-reverse~ was causing problems with MUI's drawer scrolling, so reversed the chat order and made it ~column~ by default
- Hid bottom expand navigation if component not yet opened
- some other style changes in the middle
- Only pass necessary props
- Created new initialize play redux action
- Removed deprecated ~file app download~ keyboard functionality, moved preventDefault to videojs keyboard events to prevent ~space~ moving down the page
- moved doPrepareEdit incognito and channel calls to separate action
- same with download
- Tooltips
- No major differences between mobile or default returned components so removed condition since mobile style will be changed later on this branch
* Patch to restore position upon returning to video until more fully fleshed out fix can be introduced
* Add code to notify other open tabs of position saving
* Fix typo
* Wrap localStorage access in try/catch in event browser settings make it unavailable
* Remove formatting changes
* Move constant from 'pages' to 'player'
* Move dispatch out of try/catch
* Fixed typo
* fix RESOLVE_URIS_COMPLETED, to have one large action instead of hundreds of small ones
* Addressed comments.
* Addressed comments.
* Addressed comments.
Co-authored-by: Asad Umar <au@visuary.fr>
## Issue
Closes 385
## Approach
As mentioned in the ticket, the current places where that info is needed is in the Invites Page and Social Share Component.
1. Invites Page: it is already doing the fetch on mount, so no issue there.
2. Social Share: show spinner until the data is fetched.
## Issue
A huge list like http://localhost:9090/$/list/d91815c1bc8c80a1f354284a8c8e92d84d5f07a6 (193 items) often produces fewer results in the final rendered list.
## Cause
The same list of IDs was passed into `claim_search`, and we just increment the `page`. However, it seems like `claim_search` does not honor the order between each call, and some results from the previous page took the place of the results in the next page. The total is the same, but there are now duplicates.
## Fix
When batching, slice the ID list ourselves to bypass the problem for now.
