Change Details

T3003 Pretty big refactor but they couldn't be split out into smaller diffs as they're all interconnected. Refactored logic: 1. Upon Cashtab loading, if the alias setting is enabled in Ticker.js, then `handleUpdateWallet` in useWallet.js will execute `synchronizeAliasCache`. 2. `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` 3. 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. 4. When the user is registering a new alias, `isAliasAvailable` and `isAliasRegistered` are called to check whether it has been taken. 5. 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. 6. 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. 7. 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 8. 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

T3003 Pretty big refactor but they couldn't be split out into smaller diffs as they're all interconnected. Refactored logic: 1. Upon Cashtab loading, if the alias setting is enabled in Ticker.js, then `handleUpdateWallet` in useWallet.js will execute `synchronizeAliasCache`. 2. `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` 3. 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. 4. When the user is registering a new alias, `isAliasAvailable` and `isAliasRegistered` are called to check whether it has been taken. 5. 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. 6. 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. 7. 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 8. 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

T3003 Pretty big refactor but they couldn't be split out into smaller diffs as they're all interconnected. Refactored logic: 1. Upon Cashtab loading, if the alias setting is enabled in Ticker.js, then `handleUpdateWallet` in useWallet.js will execute `synchronizeAliasCache`. 2. `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` 3. 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. 4. When the user is registering a new alias, `isAliasAvailable` and `isAliasRegistered` are called to check whether it has been taken. 5. 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. 6. 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. 7. 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 8. 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