## Why
Frequently used; top in perf profile
## Changes
Most of the time, you already have the claim object in the current context. `selectClaimIsMineForUri` will retrieve the claim again, which is wasteful, even if it is memoized (looking up the cache still takes time).
Break apart the logic and added the alternative `selectClaimIsMine` for faster lookup.
- memo not required.
- start to not use the confusing and wrongly-named 'selectCommentsByUri' (per comment from Sean); use the existing 'selectClaimIdForUri' instead. This works because currently we do fetch any comments without first visiting a claim/uri, so we'll always have fetched the required claim, and can be queried in 'selectClaimIdForUri'.
## Issue
`normalizeUri` | `parseURI` is expensive and has been causing sluggish operations when called repeatedly or within a loop.
## Change
Since I'm not confident enough to remove the call entirely from makeSelectClaimIsMine (although I've yet to find a scenario that the uri is not already normalized), we'll try caching the calls instead.
## Results
- in a simple test of toggling between 2 category pages, we saved 20ms from `parseURI` calls alone.
- in a test of opening all categories one time, the memory usage remained similar. This makes sense since we removed a `makeSelect*` (which creates a selector for each call + not memoizing), and replaced that with a cached selector that's actually memoizing.
`selectMyActiveClaims` includes pending claims, so it gets invalidated often.
For the case of comment-filtering, we don't care about pending or abandoned own claims.
## Issue
When comments are refreshed, each `Comment` gets rendered 4-5 times due to reference invalidation for `othersReacts` (the data didn't actually change).
## Change
For selectors without transformation, there is no need to memoize using `createSelector` -- just access it directly. Also, don't do things like `return a[id] || {}` in a reducer, because the reference to the empty object will be different on each call.
Always return directly from the state so that the same reference is returned.
This simple change avoided the wasted resources needed for `createSelector`, and reduced to render to just 2 (initial render, and when reactions are fetched).
## Issue
Now that we batch-resolve the comment authors before displaying the comments, the linked-comment scrolling logic didn't work well with nested replies.
## Change
Previously, I didn't want to put the logic at the lowest level (`Comment`) because it was hard for the child to know whether to scroll or not. For example, we don't want to scroll when user changes the comment filters or presses the Refresh Comments button.
Relented and moved the logic to `Comment`, and pass a flag via `window` (I know this is frowned upon by some) to indicate whether a scrolling is needed.
This is probably more efficient overall as we don't need to scan the DOM, and with minimal delay as we scroll immediately after the linked-comment is mounted.
## Known issues
In markdown posts with lots of images, a layout shift due to delayed inline-image fetching can cause the scrolling to be inaccurate. This should be fixed by reserving space for markdown post images.
This reverts commit caadd889ce, reversing
changes made to 8b2c7a2b21.
## Issue
- Infinite `resolve` loop when deleted channel is present in the comments.
- Since it was only displayed comments with resolved channels, it masked away those comments. While that may or may not be regarded as a defect, I think we should do it at Commentron instead of at the app if we want to filter deleted channels. I vote to show comments from deleted channels, since it might have good conversation thread.
* Add option to pass in url-search params.
Impetus: allow linked comment ID and setting the discussion tab when clicking on the `ClaimPreview`.
* comment.list: fix typos and renamed variables
- Switch from 'author' to 'creator' to disambiguate between comment author and content author. For comment author, we'll use 'commenter' from now on.
- Corrected 'commenterClaimId' to 'creatorClaimId' (just a typo, no functional change).
* doCommentReset: change param from uri to claimId
This reduces one lookup as clients will always have the claimID ready, but might not have the full URI.
It was using URI previously just to match the other APIs.
* Add doCommentListOwn -- command to fetch own comments
Since the redux slice is set up based on content or channel ID (for Channel Discussion page), re-use the channel ID for the case of "own comments". We always clear each ID when fetching page-0, so no worries of conflict when actually browsing the Channel Discussion page.
* Comment: add option to hide the actions section
* Implement own-comments page
* Use new param to remove sort-pins-first.
comment.List currently always pushes pins to the top to support pagination. This new param removes this behavior.
I think this the best solution so far, at the expense of a slight delay in scrolling if the network call stalls.
- Added "fetching by ID" state so that we don't need to use the ugly N-retries method.
- `scrollIntoView` doesn't work if the element is already in the viewport, and the `scrollBy` adjustment doesn't take into account the y-position restoration that we perform on certain type of pages. Use `window.scrollTo` instead and taking into account current scroll position.
* Add Channel Mention selection ability
* Fix mentioned user name being smaller than other text
* Improve logic for locating a mention
* Fix mentioning with enter on livestream
* Fix breaking for invalid URI query
* Handle punctuation after mention
* Fix name display and appeareance
* Use canonical url
* Fix missing search
## Ticket
6946: Linked-comment scroll position is inconsistent
## Issues
- If it is a deeply-nested reply, the positioning is incorrect.
- If there are pinned comments, the positioning is way off.
- If there is a delay in mounting, the positioning doesn't happen.
- When clicking on the comment's date to highlight it, the comment goes missing and the scroll position is weird.
## Changes
- Take into account that replies can be linked-comments.
- Perform a "one-time" search for the linked-comment after the initial fetch, if necessary. The expensive DOM search is only be executed minimally.
## Ticket
6879: Previously pinned livestream comments show as latest
## Issue
`comment.List` will always display the pinned comment first, hence the problem when the chat is refreshed.
## Approach
Completely split pinned comments from top-level comments in the Reducer, and the let the GUI (e.g. regular comments, livestream comments) decide how they want to display it.
For the case of livestream, there is no need to repeat the pinned comments in the regular chat area, since there is a dedicated area on top.
## Issue
6467 Add status indicators for messages from creator, delegated moderator, global moderator
## Changes
- Added the required icons.
- Added tooltip.
## Notes
- Left out "creator" since we are already highlighting the creator's name.
- Note that currently the status is only available via websocket deltas. `comment.List` does not provide the data.
- When `comment.List` includes the info, regular comments will automatically include these badges.
## General
- `setting.List`: returns full creator settings. Requires signature (i.e. you own the channel)
- `setting.Get`: returns a public subset of the creator settings. No signature required, and it is mainly used by the GUI to determine the constraints of a channel (e.g. comments enabled? min tip requirements? etc.). Does not include private settings like "blocked words list".
`doFetchCreatorSettings` will handle both of these. Clients that uses the stashed results (`settingsByChannelId`) just needs to be aware the result might not contain everything, depending on whether you own the channel or not.
## Misc Related Changes
- Finally fix the reducer for COMMENT_FETCH_SETTINGS_COMPLETED to not purge the data on each call.
- Change `doFetchCreatorSettings` to operate on a single channel instead of multiple. We ended up not using the multple mode anyway, so it was wasteful code trying to batch the promises.
- `commentsDisabledChannelIds` is no longer needed. Previously, this was created just to differentiate between Creator (full) and Channel (subset) settings. It's cleaner to just use one object, so eliminated this.
- Remove unused 'commentingEnabled'.
## Aside
- There are now 2 ways to know if a channel has disabled comments: (1) from `comment.list` and `setting.Get|List`. Both of them updates `settingsByChannelId`, so it'll still be a single place for the GUI to check against.
- use `selectActiveChannelClaim` as that takes the current channel list into account (i.e. correct state when all channels are deleted).
- `selectActiveChannelId` should probably be removed or not exposed through a selector, as it is not updated when channel list changes?
show visible card and add remove card button
show your transactions even if you dont have a card
fix presentational issues
show your transactions even if you dont have a card
fix presentational issues
add link to channel section
update yarn
show donation location
add remove card modal still needs completion and also changed how stripe is used on settings stripe card page
add confirm remove card modal to router
move bank account stuff to settings page
move account functionality to settings page
continuing to move account transactions to settings
list transactions for creator
updating copy
touchup tip error
do a better job autofocusing
bugfix
show an error on the card page if api returns 500
building out frontend for comment tip
display dollar sign if its a fiat tip
more frontend work
more frontend work
more frontend bug fixes
working with hardcoded payment intent id
working but with one bug
bugfixed
add toast if payment fails
add add card button
cant get claim id but otherwise done
more frontend work
call is working
show fiat for livestream comments
add is fiat on comments
round and show values properly
dont allow review if tiperror
copy displaying properly
disable buttons conditionally properly
remove card button working
remove card working with a workaround by refreshing page
bugfix
send toast when tip on comment
jeremy frontend changes
only show cart on lbc
Not sure if this will ever occur, but technically possible from the code point of view. Try adding this to see if it stops the spikes in `reaction.list` calls.
Seeing the spinner too much can be annoying.
- This approach works, but currently, when the list is very long, something is taking up resources and the handler couldn't be processed, so the effect is lost (still seeing the spinner). See 6473.
- Since we are now prefetching, bumped the debounceMs a bit.
## Issue
Closes 6159 "Support Comments Enabled/Disabled for comment.List API"
## New behavior
- `disable-comments` tag will block the comments component entirely.
- `settings.commentsEnabled`:
- When false, will pause comment fetching, posting and replying.
- Any already-fetched comments will stay on screen (unless user reloads/F5).
* own comments show first in controversial / best #5905
* workaround to place my recent comment at the top
* only most recent comment
* lint fix
Co-authored-by: Thomas Zarebczan <thomas.zarebczan@gmail.com>
