Page MenuHomePhabricator

[Cashtab][Alias] Alias lookup facility
AbandonedPublic

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 Diffcashtab-tests
Build 50364: arc lint + arc unit

Event Timeline

emack requested review of this revision.Oct 22 2023, 11:23
Fabien requested changes to this revision.Oct 23 2023, 13:27

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

emack marked 2 inline comments as done.
  • Initialized aliasLookupName in formData
  • Using the newest pending prop in the /alias endpoint to distinguish between unregistered or pending confirmation aliases
  • Screenshots below:

image.png (543×637 px, 60 KB)

image.png (281×424 px, 15 KB)

image.png (539×638 px, 63 KB)

aliasinfo3.PNG (555×748 px, 66 KB)

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

This comment was removed by emack.
emack planned changes to this revision.Oct 27 2023, 11:29

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.

emack requested review of this revision.EditedOct 27 2023, 14:14

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.

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.
cashtab/src/components/Alias/Alias.js
351 ↗(On Diff #42831)

Reusing the input field would prevent this code duplication. Whatever the end solution it should not be duplicated anyway.

This revision now requires changes to proceed.Oct 31 2023, 10:16

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