I must have missed something here

Rebase to master

Updated processChronikWsMsg() to refresh pricing every 90 blocks rather than every block

Updated UI as follows

In D14713#330950, @bytesofman wrote:

You should do an API call on each block and store the value locally, obviously a lookup for each keystroke is the wrong design.

this is a good idea but imo should be it's own diff. not necessarily related to just this UI change, easy enough to add into this UI -- but does require some new logic.

Updated checkbox logic to toggle between showing and hiding the seed phrase in addition to the updated static warning message.

Updated UI per feedback.

Setting the IFP address as the settlement address.

Added isValidSideshiftObj() along with unit tests to validation.js to check that the instantiated sideshift object contains the expected APIs. If not valid, an error is displayed in place of the button in Swap.js. This can be verified by malforming the sidieshift library url in /public/index.html header.

Rejigged UI for reference:

Re-arranged UI per feedback, updated label for active wallet registration checkbox.

Improved pending array filter and variable names.

Will re-use the existing registration field with a check button as a separate diff.

Added pendingAliasCounter to tally count of certain aliases within the pending array for the current address.

Added conditional substring to the pending alias warning which indicates number of pending registrations for this wallet address.

Updated test snapshot for Home

Updated the Swap component to be a central portal for all Swap widgets rather than SideShift specific. It now houses both ChangeNow and SideShift.

On a separate note, I've also carried out localized usage of this diff in /apps/examples and it tested fine.
i.e.

1. Refreshed the dist folder within /modules/chronik-client repo via npm run build
2. Go into /apps/examples and removed current client npm uninstall chronik-client
3. Installed this diff via npm i ../../modules/chronik-client
4. Go into /apps/examples/getDetailsFromTxid.js, import the client via the relative path above and instantiated ChronikClient constructor with an array of 1 mispelt url (simulated outage) and 1 correctly spelt url
5. Executed the example via npm run getDetailsFromTxid <txid> and it should cycle past the 1st url and connects successfully on the 2nd url to return the transaction details.

Responding to feedback

Full onchain pending alias check is now implemented in the post-registration-button-click logic (preparePreviewModal), which renders an additional sentence in the registration confirmation modal, depending on whether pending.length is > 0. The local pending check per keystroke is now removed due to low value.

In D14666#330192, @emack wrote:

In D14666#330165, @Fabien wrote:

Why do you have a search button if you're having the lookup at every key stroke ?

Pending the pending discussion in D14611 before evaluating whether this search is redundant.

In D14666#330165, @Fabien wrote:

Why do you have a search button if you're having the lookup at every key stroke ?

• Initialized aliasLookupName in formData
• Using the newest pending prop in the /alias endpoint to distinguish between unregistered or pending confirmation aliases
• Screenshots below:

Responding to feedback. Note: the XPI url was unstable recently and started breaking the test suite. Replaced all instances of this with the working XEC version in test.ts.

Pending D14683

quick note - if you end up going through with this you'll need to remove this button from SendToken.js as well

Worth noting this would be implemented at the point of pressing the register button and not when the user is inputting the alias name with each keystroke being parsed for validity. I can add it as a conditional text render in the registration confirmation modal (preparePreviewModal).

The alias registration input field now detects whether an input (without needing to click Register Alias) already has a pending tx for this wallet and renders a non-blocking warning.

Rebased to master after state var cleanup

Rebased to master after state var cleanup

Pls note the state var cleanup is via D14624.

Does a page refresh trigger an alias server call ?

Yes it does. The useEffect() within Alias.js that has a dependency on [wallet.name] triggers it upon refresh of the page. So this serves as another, more common mitigation path.

Updated interval default value and initialization logic.

Rebase to master

In D14638#328769, @Fabien wrote:

There was no test for this ?

@bot build-cashtab

Also worth considering whether to use D14269 as a baseline since that refactors ~60% of chronik-client

Updated snapshot @generated tag

Added aliasLength as a local var

Using getAliasByteSize in place of formData.aliasName.length.