## Issue
??
## Behavioral Changes
- Use `claim_search` instead of `claim_list` to retrieve all all own claims with the same name (case-insensitive).
- Caveat: annonymous posts will be excluded.
- When a clash occurs, there is a possibility that we have multiple existing entries (e.g. "xxX", "xXx"). Since we don't know which one is best to fall back, I removed the "edit" button for this and replaced with a simpler text
## Code Note
- If not mistaken, the rest of the code still needs `selectMyClaimForUri` to be case-sensitive, so augment the selector to support both through an optional parameter.
The code currently supports both the baked-in homepages, as well as fetching from `/$/api/content/v1/get`.
As the latter is currently a circular round-trip, just use the baked-in version until the service is moved elsewhere. Loading performance will be better.
Potentially closes 1319
## Note
- `persistor.purge` returns a promise, we should wait for the resolved results before reloading, instead of just adding an arbitrary `setTimeout`.
- Perhaps the `setTimeout` method is to ignore a super-long or hanged purge (not sure), but it wouldn't be right since it would end up in a limbo state.
- Log errors to get clues for future.
- Reduced code by moving the reload to `finally`.
## Change
Due to "Own Comments" being implemented the same way as "Discussion Page", the comment lookup did not work for the abandoning case.
Just skip the local cleanup of `byId` -- it doesn't matter, as the GUI uses `selectCommentsForUri` to grab the per-channel comments, so it would still disappear in the GUI immediately.
## Issue
Ticket: 108
## Interesting
Uploads Page uses `claim_list`
Channel Page uses `claim_search
A second `claim_list` would instantly show updated results, but `claim_search` takes a long while to reflect the deletion.
## Change
This PR only handles the `claim_list` (Uploads Page).
The `claim_search` version would be troublesome to handle. If a refresh would bring back the results (due to the `claim_search` slow update behavior), we would need to store the deleted claim persistently. Then ...
- Store where? rehydrate?
- When to clear?
- How to make each `ClaimList` filter this out without polluting the code? etc.
...will be messy. Feels easier to "fix" at the `claim_search` level to make it update faster (maybe a command to clear cache at server or something).
Ticket: 1256
For `notify`, "file is currently locked" and "no such file or directory" is indication that the previous "failed" SDK call actually worked. Tell the user to check the transactions.
This is the band aid until odysee-api/401 is addressed.
## Issue
Accumulation of so many strings for a "successful tip" that it is getting annoying to re-translate them for minor changes.
## Change
- Consolidate and re-use strings.
- Make the tip string currency-agnostic so we don't have to touch it again. The amount and currency is moved to the `subMessage`.
- Fix spacing being incorrectly enforced through i18n (it should be done via code/css).
Ticket: 1189
## Issue
There is a bug in a batched `resolve` that returns jumbled data. Temporarily switch to `claim_search` until that is fixed.
## Notable differences:
- `resolve` will tell us directly that a claim has been removed or filtered, so redux will mark the ID as such. `claim_search` simply returns nothing, so we will still end up with an extra `resolve` for these items when the component tries to display it.
- The new function currently does not handle Collections (i.e. resolving individual items in the Collection) and Reposts. Given that this is temporarily, I'd like to leave `doClaimSearch` as is, instead of trying to replicate what's in `doResolveUris`.
## Notes:
Since we don't care if the resolve fails (and we weren't doing anything in the `catch` anyways), use `finally` instead.
- Remove the need for an object key. Just use an array. It gets hard to maintain as more messages come in, and so far there is no need to access the configs directly.
- Just focus on handling the message and not creating a toast object. Leave the latter to the client.
- Remove the odd resolve call that's lingering in `App`. Feels out of place, plus we don't need it now since the "active subs" claim search would contain resolved results.
- Don't search for active subs if Following count is zero.
## Issue
- Errors like "unexpected token at..." and "failed to fetch" are being logged, rather than the actual call error.
- Publish SDK timeout is sometimes successful, but the user doesn't know, so they re-created the same claim
## Change
- Attempt to make the logs more helpful, and the error message more meaningful to the user.
- Starting off with 'publish' and tip SDK call as an experiment. Can add others if this method works.
