[HOLD for mentions doc] Add "handle" next to display name in report actions

[puneetlath]

As discussed here, we would like to add "handles" next to the display name in chat messages. It is the @amy style text that is to the right of Amy Evans name in the mockup.

The handles would be displayed with the following logic:

• Handles are only shown when they differ from the user's display name. We don't show the handle when it's the exact same as the display name because it is redundant. This is because we use the primary login as the display name when a first/last name isn't set.

The general logic for how we want to display the handle is laid out in pseudocode here:

if (displayName == "") {
    displayName = primaryLogin;
}

if (primaryLogin on viewer's domain && primaryLogin not publicEmail) {
    handle = frontOf(primaryLogin);
} else {
    handle = primaryLogin;
}

if (displayName == handle) {
    header = "<b>displayName</b>";
} else {
    header = "<b>displayName</b> @handle";
}

In words:

• When we are displaying a handle:
  • The handle is prefixed with an @ symbol
  • If their primary login is a phone number, we show the full phone number as the handle (e.g. @9765473456)
  • If their primary login is a public domain email address, we show the full email address as the handle (e.g. @[email protected])
  • If their primary login is a private domain email address on a different domain than the logged in user, we show the full email address as the handle (e.g. @[email protected])
  • If their primary login is a private domain email address on the same domain as the logged in user, we show the front of the email address as the handle (e.g. @bob)

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01901c3233ac120b6f
• Upwork Job ID: 1637899128487186432
• Last Price Increase: 2023-03-20

[puneetlath]

I don't think the front-end knows whether the domain is a public domain. So I'll need to have the back-end return that in the personal details.

[puneetlath]

Actually, that's not true. It's in the PUBLIC_DOMAINS constant in expensify-common, which is used in this component for example.

[ArekChr]

Hey @puneetlath I can work on a proposal for this issue

[puneetlath]

Sounds great @ArekChr!

I've updated the mockups and made some slight tweaks to the described behavior based on the discussion in this thread.

[ArekChr]

Hey, @puneetlath, I assume this feature is only about displaying handles?
Do we want support displaying a list of users when typing @... in chat input, or will that be a separate feature?

Edit:
Also, the same question about handles that are highlighted in inside messages, I see it in the design, but this is not mentioned in the description. That be a separate feature?

[puneetlath]

Hey @ArekChr that's correct, that will be a separate feature that's currently in planning. For now, we just want to display the handles in the chat header here.

[ArekChr]

Proposal

Please re-state the problem that we are trying to solve in this issue.

As discussed, we must add a "handle" next to the user's display name in chat messages. The handle should only be displayed when it differs from the user's display name. We must ensure the handle is displayed correctly based on the user's primary login.
An example is the @amy style text that is to the right of Amy Evans's name in the mockup.

What changes do you think we should make in order to solve the problem?

I propose creating a reusable component called UserHandle that will contain the necessary logic to display the handle. This component will accept a user object and return the formatted user name with the handle.
I will also add tests covering all cases to ensure the handles are displayed correctly.

To summarize, I will use the following logic for displaying the handle:

• If the user's display name is an empty string, we will use their primary login as the display name.
• If the user's primary login is on the viewer's domain and is not a public email, we will show the front of the primary login as the handle.
• If the user's primary login is a phone number, we will show the full phone number as the handle.
• If the user's primary login is a public email address, we will show the full address as the handle.
• If the user's primary login is a private domain email address on a different domain than the logged-in user, we will show the full email address as the handle.
• If the user's primary login is a private domain email address on the same domain as the logged-in user, we will show the front of the email address as the handle.

[MelvinBot]

Job added to Upwork: https://www.upwork.com/jobs/~01901c3233ac120b6f

[MelvinBot]

Triggered auto assignment to Contributor Plus for review of internal employee PR - @Santhosh-Sellavel (Internal)

[puneetlath]

@ArekChr given that the handle is just text, why create a component rather than just a function that returns the text for the handle? Not opposed to a component, just want to understand the reasoning.

[ArekChr]

@puneetlath, I assumed that this component would be designed for reuse in both the chat message body and header sections, with a component as its main building block. This would allow for different styles to be applied using a single property, such as the "variant" property, which could take values like "chat", "profile", and more. For instance, if the "chat" variant were used, the handle would have a blue background, while the "profile" variant would make it grey.

This approach offers a simpler component from the outside since styling does not need to be set externally when reusing it. Instead, it is defined once inside and can be easily reused with different styles by passing the appropriate variant as a property. For example:
<TextHandle user={user} variant="chat"/>
<TextHandle user={user} variant="profile"/>

Alternatively, I could create a function that returns the handle string, which would require passing the string inside a component and styling it externally using StyleUtils. However, this approach would require us to remember to use both the StyleUtils and the function that generates the handle each time it is used in the code.
Example:
<Text style={StyleUtilts.getStylesForHandle(user, "chat")}>{getHandleForUser(user)}<Text/>
<Text style={StyleUtilts.getStylesForHandle(user, "profile")}>{getHandleForUser(user)}<Text/>
or
<Text style={StyleUtilts.getStylesForChatHandle(user)}>{getHandleForUser(user)}<Text/>
<Text style={StyleUtilts.getStylesForProfileHandle(user)}>{getHandleForUser(user)}<Text/>

An additional advantage of the first reusable component is that it allows for separate testing of the function that generates the handle, the component that displays the specific element, and the colours for particular variants.

In both cases, the handle still needs to be passed into the text component because it will always have different styles to distinguish it from the rest of the text (in a chat message or next to the display name). That's why I assumed it could be a component which has more advantages, IMO.

What do you think about these options?

[puneetlath]

Got it! I think you are right that this will be a better approach when we are using the handle in more places. However, our general approach is to go with the simplest solution for our needs now, then refactor to make it more DRY as more use-cases come up.

So I think it's better for us to go with a function that returns text for now. And then when we figure out where else we want to display the handle, we can evaluate creating a component and moving the function's logic there.

[ArekChr]

Sure, I will go with the general approach! Can I start working on PR?

[puneetlath]

Yes, go ahead!

[puneetlath]

How's this one going @ArekChr?

[ArekChr]

Hey, @puneetlath, I didn't get a chance to focus on the handle last week as I had other things that needed my attention. However, I am available and ready to continue working on this task.

[ArekChr]

Hey @puneetlath, I will PR is almost ready. I will do a self-review and improve the code, plus I will also include more test cases, and then I will open this PR.
Do we have some design requirements regarding truncating the display name and handle for mobile?

[gedu]

Hey, from Callstack - expert contributor group, I can continue since @ArekChr is on sick leave

[puneetlath]

@gedu sounds good.

We had actually put this PR on hold and were discussing in this design doc. Would you mind responding to the comment I tagged you in?

[puneetlath]

@gedu while this issue is on hold, would you want to take this one: #18101

It was detailed in the same section of the mentions doc, but we decided to break it out separately.

[puneetlath]

@gedu just wanted to check in again and see if you want to take #18101

[gedu]

Sorry, I think I missed the notification, we are discussing internally and will back to you if I will take it

[puneetlath]

I'm going to go ahead and close this for now. I'll open a fresh issue when the design doc has been updated and we're ready to implement.