---Fixes:
#-2882: "Fix UX around publishing to already published URL".
---Changes:
1. Improved the error message (change color to red; emphasized the URL; tweaked the sentences a bit).
2. The `Publish` button will be grayed out in this scenario, until user explicitly decides to edit existing claim instead.
--- Issues:
(1) #-2669: Page does not restore to top when navigating new tags.
(2) "Encountered children with the same key" error (duplicate entries shown).
https://github.com/lbryio/lbry-desktop/issues/4367#issuecomment-645449206
--- Changes:
(1) Ignore the history if it's a new query (i.e. explicitly clicked). The BACK history will still behave as normal (doesn't reset to top).
(2) Previously, the `page` variable will continue to increment as you scroll and stay within the page (e.g. Trending vs New, or clicked another Tag). As you move between queries, we hit a scenario where `page` is significantly under or over the latest retrieved `claimSearchResult.length`. This messes up the rest of the code.
Fix by correcting the value of `page` according to the current `claimSearchResult.length` when necessary.
--- Issues:
(1) #-4394 add persistence to new support modal.
(2) Should collapse the custom field when presets are selected.
Even though the Send button repeats the amount for Tip, it's still confusing to see both the Preset being active and Custom numeric field visible.
(3) Missing localization tags.
Implementation:
- The code is placed in <VideoJs> instead of <VideoViewer> as we need to control the video itself. It's more self-contained here, rather than trying to pass refs around between parent and child.
- useState cannot be used as it will cause a re-render when the hint it clicked and dismissed. The DOM is used to hide the button.
--- The bad scenario:
A less popular tag like 'kanji' yields only 23 results today. The code continues to increase the page count. We'll either see some blank page glitches at the bottom, or repeated entries being shown.
--- The fix:
Assume that an unfilled page means "no more results" and stop incrementing the page. This seems true based on empirical evidence.
If you are at the bottom and you hit the UP_ARROW key one time, the logic still thinks we are at the bottom, despite the component has clearly moved. Similar to the issue noted in the previous commit, this causes the page to increment incorrectly.
My wild guess is that the previous logic depends on the css height, so it might got broken due to css changes. Hopefully the new calculation is more robust and works for all cases.
---The bad scenario:
If you're at the bottom and you go up using UP_ARROW or HOME key, the coordinate is still at the bottom if we service the callback immediately. This causes 'contentWrapperAtBottomOfPage' to be true and we ended up incrementing the page unnecessarily (even for searches that no longer yield any extra results).
---Fix:
Fix by adding a delay. The value can probably be fine-tuned further.
---The issue:
When switching between tags, the selector defaults back to Trending even though you had another option already selected.
---Changes:
- 'orderParamUser' will store the last user state persistently. The persistent state is also made unique for each page (i.e. Your Tags and All Content will be unique).
- If the parent component passes in a specific order, that will be respected and will also become the new persisted value. One example is "Your Following", where it always starts at 'New'.
- Handled navigation history correctly
The test case:
- Enter "Your Tags" (assume start at 'Trending')
- Click 'New'
- Click 'Top'
- Back
- Back (it should return to 'Trending')
As the top page history does not have any "?order=" value, we ended up with a no-op for the last Back. 'orderParamEntry' is added to handle this.
Two issues:
1. Values not marked with __()
2. Split sentence.
For #2, it seems like there are translations that don't make sense when combined, because the values are being translated independently from full sentence in Transifex. Decided to just make it full sentences.
