T3003
Pretty big refactor but they couldn't be split out into smaller diffs as they're all interconnected.
Refactored logic:
- Upon Cashtab loading, if the alias setting is enabled in Ticker.js, then handleUpdateWallet in useWallet.js will execute synchronizeAliasCache.
- synchronizeAliasCache calls getAliasServerHistory to hit the alias-server to retrieve the latest valid aliases and if the alias count does not match between aliasCache.aliases and the alias-server, then localforage is updated via updateAliases
- When updateAliases is commiting the alias-server response to the cashtabCache.aliasCache object, it now looks like:
aliasCache: {
aliases: [], cachedAliasCount: 0,},
The integration with alias-server made all processes relating to parsing paymentTxHistory, extracting valid aliases, parsing onchain count...etc redundant, hence a much simplified aliasCache object going forward.
- When the user is registering a new alias, isAliasAvailable and isAliasRegistered are called to check whether it has been taken.
- If alias is available, the remaining registration logic remains unchanged, other than now calling registerAliasNotification for successful notification that explains the need for 1 conf for alias to be active.
- Upon registration, processChronikWsMsg in useWallet.js (from the abandoned D13301) will wait for a new block to be found and then refresh the aliasCache so the newly registered alias will show up in registered aliases list in Alias.js and resolve to the appropriate address in send and sendToken screens.
- Also fixed an existing bug in Alias.js where synchronizeAliasCache was returning an outdated aliasCache IF it determined a cache refresh was required i.e. it was originally returning the aliasCache that was retrieved at the start of the function before the refresh action. Now Alias.js' useEffect calls await synchronizeAliasCache() first then directly retrieves latest from getAliasesFromLocalForage()` afterwards
- Various unit tests and mocks updated to reflect the above refactors and the new aliasCache object
Refactor Change log
updated
- updateAliases: now takes in the alias server response and commits it to localforage
- synchronizeAliasCache: compares onchain vs cached alias count and updates the latest alias-server response into local storage when required
- isAliasAvailable: retrieves alias list from storage rather than hitting chronik
- send.js now passes cached aliases into isAliasAvailable rather than chronik instance, as well as updated error message "eCash Alias does not exist or yet to receive 1 confirmation"
- sendToken.js: updated error message "eCash Alias does not exist or yet to receive 1 confirmation"
- isValidCashtabCache: updated to reflect the new aliasCache structure
- getAliasesFromLocalForage: returning the updated aliasCache object but kept the alphanumeric validation in there to migrate pre-alias-server wallet caches
- processChronikWsMsg: monitors for a new block and then triggers an alias cache update
Removed
- getAllTxHistory: no need to hit chronik anymore
- getAliasAndAddresses: redundant now the alias-server does the heavy lifting to parse payment tx history
- calculateAliasTxCount: redundant now that we're using alias count
- sortAliasTxsByTxidAndBlockheight: redundant now the alias-server is doing this
- filterDuplicateAliasTxs: redundant now the alias-server is doing this
Unchanged
- isAliasRegistered: local caching logic only
- isAddressRegistered: local caching logic only
- isAlphanumeric: kept for getAliasesFromLocalForage
- getAddressFromAlias: local caching logic only
- isAddressRegistered: local caching logic only
- getAliasRegistrationFee: local parsing only
- registerNewAlias: still broadcasting via chronik
New
- getAliasServerHistory: fetches the alias server response
- registerAliasNotification: as advertised