Page MenuHomePhabricator

[Cashtab] [Alias] pt 6.3 - Implement updateAliases
ClosedPublic

Authored by emack on Jan 24 2023, 13:31.

Details

Reviewers
bytesofman
Group Reviewers
Restricted Project
Commits
rABC4064c50f677c: [Cashtab] [Alias] pt 6.3 - Implement updateAliases
Summary

T2551

Depends on D13025

This diff implements the logic in Alias.js to detect when the cached totalPaymentTxCount is out of sync with the onchain count, and then proceeds to refresh the caching object in localForage via updateAliases.

Key considerations

  • updateAliases takes in a previously retrieved aliasPaymentTxHistory from the initial loading of Alias.js, hence does not need to make any further API calls.
  • Since aliasPaymentTxHistory is retrieved up front, the totalPaymentTxCount figure is simply calculated via aliasPaymentTxHistory.length with no further API calls.
  • In order to generate the final form of the alias cache object where aliases is an array of both alias and addresses, I will need to update getAliases() to extract both alias and addresses. Due to its complexity this is planned separately as part 6.4, coming up next.
  • Part 6.5 will optimize getAllTxHistory to only make API calls for uncached history pages as per feedback.

Updated diff stack
[Cashtab] [Alias] pt 1 - Create scaffold for new Identity component
[Cashtab] [Alias] pt 2 - Upgrade sendXec() to handle alias registration
[Cashtab] [Alias] pt 3 - Implement isAliasAvailable function
[Cashtab] [Alias] pt 4 - Implement isAddressRegistered function
[Cashtab] [Alias] pt 5 - Implement getAddressFromAlias function
[Cashtab] [Alias] pt 6.1 - Get latest alias tx count from payment address
[Cashtab] [Alias] pt 6.1.1 - Apply Promise.All approach for alias history retrieval
[Cashtab] [Alias] pt 6.2 - Implement getAliasesFromLocalForage
[Cashtab] [Alias] pt 6.3 - Implement updateAliases
[Cashtab] [Alias] pt 6.4 - Update getAliases() to extract both alias and address
[Cashtab] [Alias] pt 6.5 - Optimize getAllTxHistory to only make API calls for uncached tx history pages
[Cashtab] [Alias] pt 6.6 - Deprecate caching related mocks, @TODOs and reviewer logs
[Cashtab] [Alias] pt 7 - Mitigate edge cases for registration records
[Cashtab] [Alias] pt 8 - Enable alias lookup for Send XEC component
[Cashtab] [Alias] pt 9 - Enable alias lookup for Send Token component
[Cashtab] [Alias] pt 10 - Upgrade tx history to recognize alias registration txs
[Cashtab] [Alias] pt 11 - Set final registration fees and remove residual dev logs

Test Plan
  • npm test
  • npm start
  • navigate to the Alias page and observe console log indicating alias cache refresh required and cache update completion. Navigate away and then back to Alias and observe no update of the cache required.
  • register a new alias
  • navigate away and then back to the Alias page, observe console log indicating the onchain totalPaymentTxCount is 1 higher than the cached instance, along with alias cache refresh required
  • switch to another wallet and ensure matching totalPaymentTxCount's results in no update of the cache.
  • send a normal XEC tx to the payment address and then navgiate back to the Alias page, observe the app detects the need to refresh alias cache
  • test with a newly created wallet on a different browser and observe the app detecting the need to refresh the alias cache

Diff Detail

Event Timeline

emack requested review of this revision.Jan 24 2023, 13:31
bytesofman added inline comments.
web/cashtab/src/components/Alias/Alias.js
109 ↗(On Diff #37693)

i think overkill to use BigNumber here. reasonable to assume tx count will always be an integer less than 9,007,199,254,740,991

Alt, we could use BigInt, which is natively availabe in JS without needing a module.

Broader task to look at replacing BigNumber everywhere with BigInt, but BigNumber is useful for the decimal math involved with etokens.

This revision is now accepted and ready to land.Jan 24 2023, 19:05
emack marked an inline comment as done.

Updated BigNumber usage to BigInt to reflect practical tx counts