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.
* 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>
* Route recommendation search to recsys 5% of the time + add `user_id`
## Ticket
334 send some recommended requests to recsys
## Approach
`doSearch`:
- If the search options include `related_to`, route that to the new `searchRecommendations` which performs the 5% check + appends `user_id` at the end. This way, we don't need to alter the function signature of `doSearch`.
- Else, run proceed as normal.
* Always go to alt provider
f
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
- Memo not required. `resolvingUris` is very dynamic and is a short array anyways.
- Changeg from using `indexOf` to `includes`, which is more concise.
## Issue
.../archives/C02FQBM00Q0/p1633044695010600
## Changes
When querying a search key, it has to be an exact match. This was broken by the insertion of `free_only` in the fetch.
Added a function to generate the options, so that all clients stay in sync.
## Issue
6414 <Don't use "exact match" setting outside of main search - cuases no results in related>
`doSearch` was used in Wunderbar and Recommended, but it was adding in Wunderbar options all the time.
## Changes
- Fix `doSearch` to not use hardcoded options (take from arguments).
- Refactors the searchOption-creation code so that we don't duplicate the logic in both .js and .jsx.
Closes 5000: AutoPlay in Floating Player only works one time
Factor out the code that queries the recommendation. It needs to be called in two places:
(1) `RecommendedContent` - need to cover the case of floating player + visit another video page.
(2) When video is floating and autoplayed the next video.
