Skip to content
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

Merged
merged 8 commits into from
Oct 13, 2020
Merged

Conversation

gnardini
Copy link
Contributor

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

@@ -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) {
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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.

Comment on lines 191 to 196
recipientCache[recipient.e164PhoneNumber] = {
contactId: '',
...recipient,
kind: RecipientKind.Contact,
}
addressToE164Number[recipient.address] = recipient.e164PhoneNumber
Copy link
Contributor

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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 :)

Copy link
Contributor

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.

Copy link
Contributor

@tarikbellamine tarikbellamine left a 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.

@gnardini
Copy link
Contributor Author

How would you feel about holding off on this PR until the next release?

No strong opinion, sounds good to me :)

Copy link
Contributor

@i1skn i1skn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! LGTM

Copy link
Contributor

@jeanregisser jeanregisser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :shipit: 👍

@@ -42,6 +42,10 @@ export interface AddressToDataEncryptionKeyType {
[address: string]: string | null // null means no DEK registered
}

export interface AddressToDisplayNameType {
[address: string]: string
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[address: string]: string
[address: string]: string | undefined

Comment on lines 191 to 192
yield put(addAddressToDisplayName(recipient.address, recipient.displayName))
yield put(storeLatestInRecents(recipient))
Copy link
Contributor

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

Copy link
Contributor Author

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 :)

Comment on lines 96 to 97
// Doesn't contain all known addresses, use only as a fallback.
addressToDisplayName: AddressToDisplayNameType
Copy link
Contributor

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?

Comment on lines +37 to +49
// 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
Copy link
Contributor

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?

Copy link
Contributor Author

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 :)

@gnardini gnardini added the automerge Have PR merge automatically when checks pass label Oct 13, 2020
@mergify mergify bot merged commit c2974ff into master Oct 13, 2020
@mergify mergify bot deleted the feed-names branch October 13, 2020 22:54
@Lss-Ankit
Copy link

Lss-Ankit commented Oct 26, 2020

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.

  • Scanned user name is shown on transaction feed when user sending an amount by scanning QR code.
  • Also, verify that User name is shown on transaction feed for receiver as well.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
automerge Have PR merge automatically when checks pass wallet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Users SBAT see the name of a person in a QR code transaction in the feed
5 participants