-
Notifications
You must be signed in to change notification settings - Fork 374
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Wallet] Add display names of scanned QRs to cache #5154
Conversation
packages/mobile/src/send/utils.ts
Outdated
@@ -171,21 +180,44 @@ export function showLimitReachedError( | |||
return showError(ErrorMessages.PAYMENT_LIMIT_REACHED, ALERT_BANNER_DURATION, translationParams) | |||
} | |||
|
|||
// exported for testing | |||
export function* _updateRecipientCache(recipient: RecipientWithQrCode) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please correct me if I am wrong but I don't think we use the underscore convention as part of the wallet code base. I understand you want to show that this is a private helper function but I don't want it to be confusing because we aren't doing it anywhere else
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not used a lot but we mention this in our TypeScript style guide
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So should we try to actively enforce this moving forward? There are plenty of places where we are exporting for testing only but I've never seen the underscore pattern used.
I'm happy either way but think we should strive for consistency.
packages/mobile/src/send/utils.ts
Outdated
recipientCache[recipient.e164PhoneNumber] = { | ||
contactId: '', | ||
...recipient, | ||
kind: RecipientKind.Contact, | ||
} | ||
addressToE164Number[recipient.address] = recipient.e164PhoneNumber |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This makes me nervous because it overwrites any existing mapping without having any type of check for security or correctness. I don't know the best way to mitigate this concern atm.
I am imagining a scenario where someone creates an account with a popular but unverified phone number. Anyone that scan's that QR, will have that phone number overwritten with the QR owner's address even though the phone number is not verified
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I agree, I was a bit lazy tbh, I found this code in some old PR and took it from there. I don't think we should be using phone numbers from this without checking if they're verified, how about this:
Instead of reusing these caches that use phone numbers, create a new one that maps address -> display name
that's used as fallback if none of the others have info about the transfer. This way the display name in the QR would only be used if the alternative is to show 'Unknown' in the feed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did the changes I suggested above, let me know what you think :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like it! I think this is a good short-term solution until we get CIP8 integrated. Please remind whoever implements the CIP8 work to remove this cache.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left a couple of comments.
How would you feel about holding off on this PR until the next release? Personally, I don't feel like we've worked out the UX considerations enough to make this a "must have" for this release.
No strong opinion, sounds good to me :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work! LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
@@ -42,6 +42,10 @@ export interface AddressToDataEncryptionKeyType { | |||
[address: string]: string | null // null means no DEK registered | |||
} | |||
|
|||
export interface AddressToDisplayNameType { | |||
[address: string]: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[address: string]: string | |
[address: string]: string | undefined |
packages/mobile/src/send/utils.ts
Outdated
yield put(addAddressToDisplayName(recipient.address, recipient.displayName)) | ||
yield put(storeLatestInRecents(recipient)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: I think it's an anti-pattern to dispatch multiple actions consecutively, but we're guilty of this in other places 😢
This is because we have a bunch of actions that are just setters.
See https://redux.js.org/style-guide/style-guide#model-actions-as-events-not-setters
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can reuse the storeLatestInRecents
action to avoid sending two with the same parameter :)
// Doesn't contain all known addresses, use only as a fallback. | ||
addressToDisplayName: AddressToDisplayNameType |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add a TODO
note about removing this once we have CIP8 working in the app?
// This is useful to test that correct params were sent to i18n. | ||
// For example, in the TransferFeedItem tests we are checking that the title of the item matches a cached value. | ||
// Without this it's impossible to check if the used value is the cached one since it only prints the i18n key. | ||
const printParamInsteadOfKey = { | ||
feedItemSentTitle: 'nameOrNumber', | ||
} | ||
const translationFunction = (key, params) => { | ||
const paramToPrint = printParamInsteadOfKey[key] | ||
return paramToPrint ? params[paramToPrint] || key : key | ||
} | ||
|
||
const useMock = [translationFunction, {}] | ||
useMock.t = translationFunction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing to do now, but it looks like we should revisit the decision of printing only the keys during unit test.
And print the actual EN strings.
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does sound like it would be better, it's one of the things I considered but I think there were some issues around values that may change (dates maybe? I think there was something else). They can be definitely normalised though and it'd be nice to use real strings :)
Hi @gnardini We have verified task on latest Android play store internal build v1.3.0(1004294316) & Test Flight build v1.3.0(27) and found the following.
However, we have updated below issues related to name as Unknown text is shown on transaction feed and profile pic as blank profile pic is shown:
Please let us know if we need to verify any thing else. |
Description
When scanning a QR, the link embedded on the QR has a display name. This PR stores that info on a cache to use it on the activity feed to show the name of the person we scanned the QR from.
Tested
Read a QR code to make a transfer and saw the display name of the scanned QR on the transactions feed.
Related issues
Part of Quality / bug fixing #4835