Run the membership reducer even for incognito.
The GUI needs to differentiate between 'unfetched' (`undefined`) and 'no membership' (`''`), so we must call the action/reducer for the incognito case as well.
Using that global variable was a bad idea. Stick to redux as the source of truth.
The flag is not listed for rehydration, so it will always start off as `undefined`, which is what we need anyways.
`undefined` indicates we haven't tested for ad-blockers, so we'll run the fetch and update the store with a true|false value.
This was tested to be removed during evaluation, but seems like there are cases where it comes back.
This solution should be more robust: hide for all, except when in our designated container.
It would be nice if the individual components can handle the remounting of the ad-script, but there is currently a need to synchronize the cleanup of the `window.OBR` object.
The quickest solution for now is to add a key at the parent side to synchronize the mount-unmounting. Not ideal -- revisit later.
- This increases the amount of ads, filling up the entire width. No more need to restrict with `max-width` ourself.
- Changed the ad-driver to top-right since the "Powered by Outbrain" text is now locked in bottom-right. Also made the container having a minimum height, as the method to "display the driver after ads are loaded" is not future proof -- it depends on the IDs being used by the ad. Reserving some space seems to be easiest, and it also reduces shifts as well.
Previously, we hide when authenticated.
We still need the `isAuthenticated` flag, because `hasPremiumPlus` stays at the unfetched (`undefined`) state for Incognito.
## Behavior in homepage
- Mobile: show after every other category
- Desktop: show after first category, then every 2 categories.
## Known issue:
- "FYP" is not part of the categories array at the moment, so it does mess up the behavior.
## Notes
I think this is also called "in-content" by adnim (not 100% sure of the terminology).
My bad, added an unnecessary check in the previous change that shorted the logic too early.
Accessing an object using 'null' or 'undefined' as the key won't cause trouble (and is expected in this case), so just suppress flow instead of fixing it using
`channelId && geoBlockLists.livestreams[channelId]`
https://github.com/OdyseeTeam/odysee-frontend/issues/1100#issuecomment-1138928520
... but leave Following as "no limit"
The primary reason for this case is due to News and Wild West having lots of livestreams. But instead of just applying the limit to these 2 and polluting the loop, just limit it for all Categories.
Requires a related commit from the homepages repo.
## Changes
- Add ability to reset the sort order.
- Make 'News' and 'Wild West' a "hideByDefault" category. It can be made visible in the homepage from the customization dialog.
## Ticket
1572
Always check for availability before use.
## Changes
- Consolidated the keys into one place for easier tracking.
- It'll also be easier to code using constant autocomplete.
- Cleaned up the wrapper to be as close as the original.
- Updated existing code to use the wrapper (even if they already handled the availability) to encourage future code to just use the wrapper.
## Issue
- Closes "1535 bunch of channels (from featured?) resolved on page load"
- It was due to the use of reposts in the Category. As we did not store the repost's original channel claim, `ChannelThumbnail` couldn't find the author and requested a separate `resolve`.
## Change
Store the repost's original channel claim as well.
## Issue
Contents aren't block if you own them, but need to tell creator that is it blocked for others.
## Change
- Show a banner on Content and Channel Page for this scenario.
- Hover tooltip is available for the full text. For mobile, tapping it reveals the message.
Note that this only applies to the locale from where the creator is viewing it from. We can ignore locale, but would then need to display _all_ geo-restrictions related to the content in a list.
- 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.
* Show-page: split out some effects
Break apart the large effect for easier tweaking, abiding by the 1-action-per-effect guideline.
This also fixes the dependency list. After checking with Haffa, the exclusion of `pathname` and `hash` from the list is probably to avoid hitting `doResolveUri`. This should no longer be an issue after the split, so no suppression needed.
* Show-page: fix "no content found" flicker
## Issue
1539: "Recently been seeing a flicker of "content not found" when direct loading content or channel links on mobile"
## Cause
`doResolveUri` can only be called after the initial mount (in the effect), so at first render, `isResolvingUri` won't be set yet, so we briefly ended up in the "no content found" path.
## Change
Factor out the logic that determines if we should send `doResolveUri`. This allows us to know that the upcoming effect will be sending `doResolveUri`, so we can hold off displaying "no content found".
* Show-page: don't delay the spinner when resolving
## Reason
The delay causes a blank page + footer, which looks bad.
* Remove claim from channel page when geoblock conditions hits
Ticket: 1100
* Handle geoblocked channel page
## Ticket
1100
## Issue
"If a channel is geoblocked, the entire channel page (even showing titles, etc. would be against the law)"
## Issues
- Not safe to call the parent callback from the render function. It must be called from an effect or
- `onHidden` is only called when blacklisted, but it can also be hidden from other circumstances.
- While those other circumstances doesn't apply for FYP (the first client that relies on `onHidden`, it's incorrect from a code perspective, unless it is renamed to `onBlacklisted`.
## Change
- Move the callback execution into an effect.
- Ensure `onHidden` is for all situations that it is hidden.
Effects cannot be defined after the render function returns early, so it was not possible to add new effects when the derived variables that it depends on are way down below.
1. Hardcoding breaks any image changes done on dev instances or locally.
2. The relative path is bad, and there are few more instances of it. But continue as is for now, will file a ticket to fix this.
3. Fix caching.
- Don't want to show it in Incognito.
- Only show it in when entered from homepage, or in the Help page.
- Record the hash of the viewed announcement and update the wallet with it.
This stores the hash for the last viewed announcement.
The intention is so that the announcement won't re-appear when logging into another device.
However, this does mean that announcements would need to wait until the first sync to decide whether to appear or not, which can be quite a delay.
This requires an accompanying commit in the homepages repo (see "Add announcement support").
Using `raw-loader` to import markdown files as a string works for the app-side, but didn't work well in web-side. Falling back to copying the announcement files to `dist` and reading them via `readFileSync`. Don't really like this -- will return with an alternative.
Moving away from the function version to the object version. Trying to track down why the effect that closes the modal ran when the pathname did not change. My only guess is the unstable hideModal reference due to the function mapping. There is no customization needed, so the object version is preferred anyways.
`doOpenModal` isn't used, so I just removed that.
* PublishFile: fix render function violation
Per doc:
> A React component should not cause side effects in other components during rendering.
Even in own render function (allowed to call), it should be avoided as it could cause infinite loops.
* PublishFile: fix useEffect infinite loop due to bad dependency
## Issue
One of the effects was adding an internal wrapper function as a dependency. As this is a functional component, the wrapper is re-created on every render and would spark the effect. That effect also updates redux (depending on the code path), so we end up in a loop.
## Change 1
Two options to fix the dependency:
1. Just remove the wrappers from the list, since we "know" it is essentially the same function (i.e. it's not function-variable that could point to something else at runtime).
2. Peek into the wrapper and determine what are the actual dependencies (usually props or data derived from props).
Solution 2 is the norm.
Aside: wrappers are usually the root-cause of incorrect dependencies, because they mask away the actual code. Need to always peek into it.
## Change 2
Next, change the dispatch-to-props map from function version to object version so that we have stable references to the actions. The object version is also preferred when we don't need to make any customizations to the actions.
This reverts commit f6f15531d4.
The root-cause was known (8dd0982f), and I don't think it worked because:
1. The issue happened at the web side which didn't have logging.
2. The `[object Promise]` came after the `get`, not before.
`tileUris` is being used as an effect dependency, but it gets re-created on every render (same content, different reference), so the `setUriBuffer` effect ended up in a loop.
* Allow drawer to be resized
- Basically re-writes the drag behavior into the Drawer component instead of using SwipeableDrawer, getting more flexibility of where to stop and what to do
- More improvements like the backdrop effect, animations and window resize behavior
* Fix console errors
* Close drawer on unmount so other pages dont load open
* Allow livestream chat to be resized horizontally
* Fix mobile browser size
- address bar etc could be on the way
* Handle popout chat
* Fix pause with floating player
working example
use my forked package
touchups to presentation
Make progress bar thumbnail sprite pixel perfect
add vtt path
fix progress bar a bit
add a black background
use odysee team package
fix two issues for merge
more analytics + refactor
- passes player with time to start (until we move this api to watchman)
- supports livestream metrics for buffering
- fixes bug with buffering over 10 second period
- less head calls by moving to videojs-events
* review fixes
## Issue
I couldn't find where the i18n went because the "events" refactor is just as confusing as the original -- unrelated things are still lumped together in a file.
Also, factoring based on events isn't useful -- it is features that drive what events are needed, not the other way around. This forces features to register events here, and do other things elsewhere? It will be more intuitive to have a one-file-per-feature structure.
## Change
Use existing frameworks to encapsulate things to manageable units/features:
(1) the React useEffect files (can be used isolate out React features like 'tap-to-mute' handling).
(2) the videojs plugins framework.
It's also possible to move the use of `useClaimListInfiniteScroll` into `claimList` itself, but opted to keep them separate for now so that `claimList` doesn't end up a bloated file like `claimListDiscover`.
- and some changes to activeLivestream redux since it would return undefined if fetching and no claim, so now it returns null when no activeLivestream is found
* Redesign threadline and fetching state
- threadline goes right below channel avatar, mimicking reddits implementation, has a increase effect on hover and is slimmer, creating more space for comments on screen
- fetching state now replaces show/hide button, also mimicking reddit, and now says that it is loading, instead of a blank spinner, and also improves space a bit
* Redesign comment threads
- Allow for infinite comment chains
- Can go back and forth between the pages
- Can go back to all comments or to the first comment in the chain
- Some other improvements, which include:
- add title on non-drawer comment sections (couldn't see amount of comments)
- fix Expandable component (would begin expanded and collapse after the effect runs, which looked bad and shifted the layout, now each comments greater than the set length begins collapsed)
- used constants for consistency
* Fix replying to last thread comment
* Fix buttons condition (only on fetched comment to avoid deleted case)
* Fix auto-scroll
* Bring back instant feedback for Show More replies
* Improve thread back links
- Now going back to all comments links the top-level comment for easier navigation
- Going back to ~ previous ~ now goes back into the chain instead of topmost level
* Clear timeouts due to unrelated issue
* Fix deep thread linked comment case and more scroll improvements
* More minor changes
* Flow
* Fix commentList tile style
* Fix long channel names overflowing on small screens
* More scroll changes
* Fix threadline
* Revert "Fix long channel names overflowing on small screens"
This reverts commit e4d2dc7da5861ed8136a60f3352e41a690cd4d33.
* Fix replies fetch
* Revert "Fix replies fetch"
This reverts commit ec70054675a604a7a5f3764ba07c36bf7b0f49c8.
* Cleanup and make smooth
* Always use linked comment on threads
* Cleanup
* Higlight thread comment
* Fix comment body styles
## 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`.
In the first attempt (PR 1497, 4d44d81f), the `generateStreamUrl` was tweaked to fetch a `Lbry.get`, which returns a promise. On top of a few async issues on its own, we also can't just simply `await` here since render functions need to be pure.
Fortunately, there is already redux structure for `get`, and Sean happened to already be passing all the required stuff here (sight beyond sight!), so it's just a matter of calling it.
Again, render functions need to be pure, so the fetch has be in an effect, so the component might take several renders to get the image painted. But oddly this seems to avoid the occurrence of showing the fallback spaceman image (just an observation, no proof of correlation).
## Issue
Ticket: 1484
The commit `7622e7a: Fix release time on category pages` passes in the `releaseTime` prop, which usually means we want that value to be override.
## Change
Only pass the prop when there 'freshness' filter is not active.
... because preference might be "Hide wallet = true". This eliminates the gap during login or boot up that temporarily shows the wallet balance.
Ticket: 1365
1446
- Requires an accompanying commit in `odysee-frontend`.
- The change assumes that the `odysee-frontend` is the only project that uses these files directly, i.e. other clients will use the API instead.
- consolidate cases that need to auto set an active channel (like edit page) into channelSelector component
- also for consistency since some components would do it with button click and others on page mount
- prevent clear function on those pages (kind of a manual process to insert each page into the router condition)
- reverts active channel functionality back to how it was previously, making the default channel simply a sync fallback and removing all complexity and confusion
From the previous commit, we are now showing toasts in the reverse order (latest to oldest).
Next, extend the "hide snack" timer to handle multiple snacks. It will dismiss them one by one, restarting itself until no more toasts.
Show a stacked GUI when there are multiple toasts.
Users can still manually dismiss the toasts.
Several issues with the clamping behavior:
- Problems trying to sync with the activeChannel setting.
- Corner-cases like unable to un-react because the comment and react channel was different; global mods not be able to change channels to do certain actions.
Just let the user know what are the channel(s) that they used to comment previously in the Toast.
If we can't confirm that user has not used another channel to comment, then don't allow commenting at all. Otherwise, there's no point doing the check.
## Why
Lost in a rebase. The GUI clamping was just meant to complement this (so that user knows what's going on), but ended up being the only thing that was pushed.
## Changes
- If the fetch failed or still in progress, we ask the user to wait or simply refresh the page.
- If already commented from another channel, bail and inform via Toast.
