If a pending alias was registered by another user it will remain pending forever.

Updated README

Rebase to changes in part 1

Rebase to changes in part 1

Rebase

Responding to feedback

Superseded by updates to pending logic in D14356

On hold until we're in a position to fork our own version

Alias.js:

• Retained the existing check for alias confirmation upon startup and expanded it to include use of pendingAliasCheck which compares the pending aliases list to the latest registered alias list from API
• Added periodic 30 second calls to pendingAliasCheck to refresh pending list

Updated WIF retrieval

rebase

Rebase

Rebase

• Updated to expand the Registered Aliases dropdown by default
• Updated unit test UI snapshots

Responding to feedback

Responding to feedback

Improved unit tests, ready for review.

Further integration testing planned before opening for review

Updated formatting

npm test

I think the test plan would go beyond just the unit test suite, as there could be unintended effects only felt via manual testing. Given the size of this diff the frontend regression test plan would be huge, so I would feel more comfortable doing this in batches.

Updated comments

• Installed the new ecash-coinselect module to encapsulate the coin selection logic and significantly simplify this example
• Added mocha-suppress-logs to reduce output noise
• Updated comments capitalization throughout example

• Created <AliasLabel> styled component to change cursor to pointer upon hover over the alias tag
• Updated corresponding unit test snapshots

Updated generalNotification to take in a duration param set to notificationDurationShort by default, but can be overriden to 0 to indicate permanent notification until closed by the user.

Published as https://www.npmjs.com/package/ecash-coinselect

Update contextual comments

Responding to inline feedback

Responding to feedback

Applying !! boolean operator to enforce boolean evaluation

• Aliases now sorted in ascending order, tested by registering a new alias and it slotted in correctly in alphabetical order.
• I thought about adding a toggle to switch between ascending and descending but there's not enough whitespace without it feeling super cramped.
• Also re-linted Alias.js to revert that weird newline.

@tobias_ruck here's where I'm at in terms of the WsEndpoint redesign to handle url arrays.

Updated to return changeAmount as 0 if it's below dust

Updated mockResponses

• rebased to D14330 chronik mock
• updated to use the latest ecashaddrjs in txConfListener
• added ws/script mock in chronikMock.js
• updated unit tests to align with the address input
• local storage-based pending alias tracking will be implemented in a separate diff

Updated for all feedback except the boolean return statement

• Installed mocha-suppress-logs and added .mocharc.js
• Replaced outputValues with changeAmount in the return object
• Added additional calcByteCount unit tests
• Updated README

Created new isValidRecipient which encapsulates the ecash/alias parsing logic

then maybe contacts.js ?

makes sense, will move it (T3254) in a separate diff as a new component accessed via the hamburger

• How is that in Configure.js ?

Configure should probably be renamed to Settings to align with the frontend. (I can throw a diff up for this)
The contact list resides there because:

• Logical grouping of saved wallets alongside saved contacts
• Contacts will eventually be applicable to both Send XEC and Send eToken screens, so it wouldn't work putting it exclusively in either of those send components
• Doesn't belong in the Home (Tx History) nor Receive (QR Code) screens

Still WIP, need to redesign how websocket endpoints cycle through urls and exception handling

Updated per all feedback except the websocket cycling of urls. That will require further thinking and a chunky refactor.

Removed broadcastTx methods from mock chronik as the jest approach is more realistic

Limiting chronik mock to broadcastTx and websocket logic

In D14325#320858, @Fabien wrote:

In D14325#320857, @emack wrote:

I'm talking about the MockChronikClient class

Without the MockChronikClient class you won't be able to trigger a mock Confirmed ws event, which leads to the infinite async loop of txConfListener() reconnecting yearning for a confirmation after npm test has concluded.

Sure, so just do it prior to this diff