## Ticket
1606
## Issue
The displayed order of the recs are often re-adjusted -- viewed content are pushed to the bottom to avoid auto-play-next from picking it up again. This was causing recsys to be confused, because the click order does not correspond the results.
## Change
Refactored the selector we can grab the raw results and use that as the index reference.
- Add ability to store `entries` into Redux.
- Sync to redux in the same interval as when playing position is saved (re-use timer).
- On startup, send any stashed entries and clear them.
Per 1318, we will only be sending data when user is done with a content, so this listener is no longer needed.
I think it was also not needed when we removed the beacon usage (it's mostly to prevent data loss when beacon is used), but we didn't remove it back then to avoid changing too many things and affecting the dataset.
* 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>
We skip fetching IDs that were just fetched a moment ago, so the array size will be reduced, but the reducer was still expecting all items to be fetched, hence the array size mismatch
We already have a pre-calculated map, but not used except for comments.
At the expense of pre-calculating it, the subsequent queries are instantaneous compared to the loop.
We are still not perfect in term of reducing re-renders, so this helps a lot.
## Why
- No memo required (no transformation).
- `makeSelect*` is an incorrect pattern.
## Changes
- Replaced makeSelectClientSetting with selectClientSetting.
- Remove unused selectShowRepostedContent.
## 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'.
* Publish button: use spinner instead of "Publishing..."
Looks better, plus the preview could take a while sometimes.
* Refactor `doPublish`. No functional change
This is to allow `doPublish` to accept a custom payload as an input (for resuming uploads), instead of always resolving it from the redux data.
* Add doPublishResume
* Support resume-able upload via tus
## Issue
38 Handle resumable file upload
## Notes
Since we can't serialize a File object, we'll need to the user to re-select the file to resume.
* Exclude "modified date" for Firefox/Android
## Issue
It appears that the modification date of the Android file changes when selected, so that file was deemed "different" when trying to resume upload.
## Change
Exclude modification date for now. Let's assume a smart user.
* Move 'currentUploads' to 'publish' reducer
`publish` is currently rehydrated, so we can ride on that and don't need to store the `currentUploads` in `localStorage` for persistence. This would allow us to store Markdown Post data too, as `localStorage` has a 5MB limit per app.
We could have also made `webReducer` rehydrate, but in this repo, there is no need to split it to another reducer. It also makes more sense to be part of publish anyway (at least to me).
This change is mostly moving items between files, with the exception of
1. An additional REHYDRATE in the publish reducer to clean up the tusUploader.
2. Not clearing `currentUploads` in CLEAR_PUBLISH.
* Restore v1 code for livestream replay, etc.
v2 (tus) does not handle `remote_url`, so the app still needs v1 for that. Since we'll still have v1 code, use v1 for previews as well.
1. The API supports batching -- updated the code to use that. Retained string as the parameter (instead of changing it to array) so that existing clients won't be affected.
2. Make `doFetchSubCount` a batched command by default through an idle timer. This way, none of the clients need to collect IDs -- it's all done behind the scenes.
3. Added minimum of 5 minutes between each sub-count fetch for a claim ID.
## Issue
- Each tile was checking against 4 blocklists (blacklisted, filtered, muted, commentron) on every render. Loading the front-page with Cheese alone caused 1400 calls.
- This is also part of the reason why pressing Back into the tile list takes forever.
## Fix
Since we still need to perform the checks at the app side for now, tried to memoize the operation through a selector.
## Issue
85 Add additional GA events
## Approach
Instead of placing analytic calls all over the GUI code (no separation of concerns), try to do it through a redux middleware instead.
## Changes
- Updated GA event and parameter naming after understanding how reporting works.
- Removed unused analytics.
- Add `/extras` to the precommit hooks (lint, prettier).
- Remove `preinstall` since these modules don't exist anymore.
- Fix missing brace if one single-line if-statement.
