## 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.
- 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.
* 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.
`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.
- 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
... because preference might be "Hide wallet = true". This eliminates the gap during login or boot up that temporarily shows the wallet balance.
Ticket: 1365
- 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.
- this way, you can choose an active channel for something like commenting but when that component is unmounted, you always go back to the default channel (like leaving page)
- Moved from reach/ui to material/ui menu components, because reach ui wouldn't work with 2 menus
- This channel selector stores the default on settings
- setActiveChannelIfNotSet was deprecated, if the account has channels, it will always return a channel even if there is no active channel or stored channel
- Make the chapters button appear consistently.
- Previously, it was only appearing for Original.
- We still hide it for mobile, as per previous explanation.
- Changed the Chapters button position and popup aesthetics.
- Deemed not useful in mobile, unless you have an S-pen that can hover.
- The chapters button (that invokes the chapters popup) would make more sense in Mobile, but we need to deal with the limited controlbar space first (e.g. overflow menu system)
- Corrected flow definitions.
- Properly differentiate between "not yet fetched" and "no membership" as "undefined" and "<empty string>", respectively. There are GUI elements that need to know the unfetched case.
## New behavior:
- If you have commented on a claim before, the channel selector will be clamped to that channel.
- There might be more than 1 channel if commented in the past.
- This includes blocked comments, i.e. if the creator blocked you, you will not see your comment, yet your channel-selector is clamped to the used channel.
- EXCEPTION: you can use other channels if it's your own claim (for now).
## Approach
- Run `comment.List` over all your channels on the specific content. This covers nested replies and pagination (sweet).
- So, if the total is non-zero, mark that channel(s) as having commented on the claim.
- Only fetch this once per content claim.
- In the comment channel-selector, clamp the list to this value.
Completely remove any need to update things on our side when a Category is added or changed.
Will need to inform homepage owners to directly translate the 'label' field, so we don't need to use our translation system.
## Issue
1378
> "Content Type: Any" uses `claim_type: [streams, reposts, channels]`, with `stream_types: ["video", "audio"]`, so channels aren't returned, and not any types of streams either. Probably shouldn't have `stream_type` filter there.
(This also happens in categories, but maybe wanted in there?)
## Root
Due to this line in `ClaimListDiscover`:
`defaultStreamType = SIMPLE_SITE ? [CS.FILE_VIDEO, CS.FILE_AUDIO] : undefined, // add param for DEFAULT_STREAM_TYPE`
Wanted to check if this fallback was meant for Categories only or any list, but the git history is not preserved because Odysee was a squashed single-commit back in the `SIMPLE_SITE` days.
## Change
Will assume it was meant for Category Page only and moved that line from the component and into the client-side.
This also means that clients of `ClaimListDiscover` without `streamTypes` and `defaultStreamTypes` defined will no longer have `stream_types: ['video', 'audio']` as the automatic fallback (they must define `defaultStreamTypes` themselves). I think this modal is clearer -- it doesn't make sense to have filters like "content=any" but overridden quietly to `video|audio`.