[Cashtab][Alias] Alias lookup facility
AbandonedPublic
Actions

Authored by emack on Oct 22 2023, 11:23.

Details

Reviewers

bytesofman
Fabien

Group Reviewers

Restricted Project

Summary

A user wanting to check the details of an alias shouldn't have to go halfway through the registration process, hence adding this lookup function in Alias.js.

Implementation-wise, I thought about overloading the existing handleAliasNameInput and passing in a lookup flag because it shares similar logic to the new handleAliasLookupInput. However I recall from previous diffs this is frowned upon so I've kept handleAliasLookupInput as a standalone function.

Test Plan

npm test
set aliasEnabled flag to true in config/alias.js
npm start
navigate to Alias.js, input a registered alias into the Alias Lookup field and click Search Alias. Ensure the alias' address and blockheight are displayed in the UI.
Look up an unregistered alias and ensure the ...is unregistered or yet to receive 1 confirmation is displayed
Attempt to look up a non-alphanumeric alias and ensure the Please enter an alias (lowercase a-z, 0-9) between 1 and 21 bytes validation error is displayed with the Search Alias button greyed out
Delete the non-alphanumeric characters from above and ensure the Search Alias button is active again and the validation error removed
Repeat the above with an alias input longer than 21 bytes

Diff Detail

Repository

rABC Bitcoin ABC

Branch

aliasInfo

Lint

Lint Passed

Unit

No Test Coverage

Build Status

Buildable 25392
Build 50365: Build Diff	cashtab-tests
Build 50364: arc lint + arc unit

Event Timeline

emack created this revision.Oct 22 2023, 11:23

Herald added a reviewer: Restricted Project. · View Herald TranscriptOct 22 2023, 11:23

emack requested review of this revision.Oct 22 2023, 11:23

Harbormaster completed remote builds in B25392: Diff 42727.Oct 22 2023, 11:28

@bot preview-cashtab

teamcity awarded a token.Oct 23 2023, 13:21

Build Bitcoin ABC Diffs / Diff Testing (preview-cashtab) passed.
Preview is available at http://54.39.104.128:41877 for the next 60 minutes.

Can we get a screenshot of what's going on?
Also since we have server side pending alias you should know whether it's unregistered or pending confirmation

This revision now requires changes to proceed.Oct 23 2023, 13:27

bytesofman requested changes to this revision.Oct 23 2023, 18:42

bytesofman added inline comments.

cashtab/src/components/Alias/Alias.js
88	we have a new formData key now, no? Should be initialized as such
665	Since this is the `name`, this will be the new key added in `formData` Worth noting the main reason to follow the convention of `{name, value}` when setting formData is so you can have a generalized input handling function. However, since we have specific validation requirements, we do not want a generalized input handling function. So -- we could just hardcode the name in the function that is only handling input for this state var in this field. imo having the name is not bad, but we do need to understand how it's being used, where it's going -- this is now a key in the `formData` object.

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

Harbormaster completed remote builds in B25457: Diff 42831.Oct 26 2023, 23:30

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

emack added a comment.Oct 27 2023, 09:58

This comment was removed by emack.

emack planned changes to this revision.Oct 27 2023, 11:29

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#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.

As per discussion in D14611, now that we've decided the "check all pending instances of this alias" API call is made after the registration button is pressed and that check per keystroke is to be removed, then I think this search has a place here otherwise the only way the user can check the status of an alias is to almost go through to the end of a registration process. When millions of XEC in registration fees are involved, this can be scary for the user if they are just after info with no intention of registering yet.

Having said that, users CAN technically input an alias into the address field on the send XEC screen to see if it renders an address or not but it kinda feels hacky from a UX pov and involves navigating back and forth with the Alias screen if you're checking multiple aliases. I'm ok either way so if leaving lookups it to the Send screen is feasible then I can abandon this diff.

In D14666#330225, @emack wrote:

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.

As per discussion in D14611, now that we've decided the "check all pending instances of this alias" API call is made after the registration button is pressed and that check per keystroke is to be removed, then I think this search has a place here otherwise the only way the user can check the status of an alias is to almost go through to the end of a registration process. When millions of XEC in registration fees are involved, this can be scary for the user if they are just after info with no intention of registering yet.

Having said that, users CAN technically input an alias into the address field on the send XEC screen to see if it renders an address or not but it kinda feels hacky from a UX pov and involves navigating back and forth with the Alias screen if you're checking multiple aliases. I'm ok either way so if leaving lookups it to the Send screen is feasible then I can abandon this diff.

I'm not sure about that. You could reuse the in put field from the registration tab and add a lookup or "Check" button next to the input field, so users can check then register with no tab change.

Fabien requested changes to this revision.Oct 31 2023, 10:16

Fabien added inline comments.