1. Added size-specific error message.
2. Route whatever Vanwa's error instead of showing "unexpected json token". It's ugly, but at least it contains the reason string.
## Issue
Closes 385
## Approach
As mentioned in the ticket, the current places where that info is needed is in the Invites Page and Social Share Component.
1. Invites Page: it is already doing the fetch on mount, so no issue there.
2. Social Share: show spinner until the data is fetched.
## Issue
Closes "87 Repost - Top result should show followers properly"
The winning url for "bret" search is "lbry://bret", which is a repost.
## Change
We need to use the canon url to retrieved the fetched view count.
* Rewrite __ to be usable on server side
* Add changelog entry
* Clean invisible characters from primaryModValue
* Revert "Rewrite __ to be usable on server side"
This reverts commit 53f63c01f3b56c5530955323612826c0ac5dc5d3.
* Make pass-through placeholder for __ fn until it can be adapted for node.
* Switch messagages to inline interpolation until i18n done
Co-authored-by: Thomas Zarebczan <tzarebczan@users.noreply.github.com>
## Issue
A huge list like http://localhost:9090/$/list/d91815c1bc8c80a1f354284a8c8e92d84d5f07a6 (193 items) often produces fewer results in the final rendered list.
## Cause
The same list of IDs was passed into `claim_search`, and we just increment the `page`. However, it seems like `claim_search` does not honor the order between each call, and some results from the previous page took the place of the results in the next page. The total is the same, but there are now duplicates.
## Fix
When batching, slice the ID list ourselves to bypass the problem for now.
* Adjust meta data to allow search pages to reflect search term
* Update changelog
* Address empty query string case and pass query string to append to og:url
Co-authored-by: Thomas Zarebczan <tzarebczan@users.noreply.github.com>
In 36fe7366, the approach to fix the "missing chunk" error and user using old code was to disable caching on the html so that user always grabs the one that's pointing to the latest ui.js.
But https://cristian.sulea.net/blog/disable-browser-caching-with-meta-html-tags/ says 3 sets of `meta` is needed to, and we missed out one. That probably explains why refreshing sometimes does not work, although I've also read that some browsers simply ignores these meta.
Commentron json params are usually underscored instead of camel-cased.
Double-checked commentron code:
```
// MentionedChannel channels mentioned in comment
type MentionedChannel struct {
ChannelName string `json:"channel_name"`
ChannelID string `json:"channel_id"`
}
```
The parameter should probably also be skipped instead of sending empty array, but leaving as-is for now since that is minor.
## Ticket
644 investigate following vs subscription preference data
## Issue
- iOS app uses colon for following/subscriptions.
- Front-end code handled the "colon vs. hash" for CHANNEL_SUBSCRIBE, but not for CHANNEL_UNSUBSCRIBE
- Put back the "--end--" entry to cover the "no trailing comma" part. This would reduce mistakes and also reduce diffs on the comma part.
- Updated with new strings; deleted some unused ones.
With the throughput tweaks at the backend, it seems like the number of "file is locked" errors have reduced.
The next thing to try is to reduce the chunk size, hoping that file writes would be faster, reducing the lock duration from causing a timeout.
