Use icon data to determine tool tips for MultipleAvatars#19104
Conversation
stitesExpensify
left a comment
There was a problem hiding this comment.
Code looks great, solid cleanup. I haven't tested though, I'll leave that to @s77rt
s77rt
left a comment
There was a problem hiding this comment.
Looks good but the design may contradict with current behaviour so need to be sure we want that change.
| props.isFocused ? StyleUtils.getBackgroundAndBorderStyle(focusedBackgroundColor) : undefined, | ||
| hovered && !props.isFocused ? StyleUtils.getBackgroundAndBorderStyle(hoveredBackgroundColor) : undefined, | ||
| ]} | ||
| avatarTooltips={optionItem.isPolicyExpenseChat ? [optionItem.subtitle] : avatarTooltips} |
There was a problem hiding this comment.
@JmillsExpensify @shawnborton is Showing Workspace the desire behavior here?
There was a problem hiding this comment.
Hmm what do we do for users? I feel like we stay consistent and just always show the room title?
There was a problem hiding this comment.
for users we show the login email
There was a problem hiding this comment.
Interesting... I lean towards just using the room title, or basically whatever the text to the right of the avatar or the chat header says?
There was a problem hiding this comment.
I agree, I think this change is fine in that case. Also, I think rooms don't use tooltips currently, so this would only be for Workspace chats.
|
@s77rt pushed changes |
| return ( | ||
| <View style={avatarContainerStyles}> | ||
| <Tooltip text={props.icons[0].name}> | ||
| <Tooltip text={props.shouldShowTooltip && props.icons[0].name}> |
There was a problem hiding this comment.
Hm, so, I've got a question here... if we don't want to show the tooltip, why is it being rendered at all? Should this maybe be more like {props.shouldShowTooltip && <Tooltip>}?
There was a problem hiding this comment.
This was the previous pattern used, we would usually do a check like tooltips = showTooltip ? <tooltips> : undefined and just pass in undefined for the tooltips
There was a problem hiding this comment.
maybe shouldShowTooltipText is a better name for this, since I think having the mouse change is still useful even when we dont show the text
There was a problem hiding this comment.
Would you mind shooting me a screenshot (or maybe a video) of what happens with a tooltip when this props.shouldShowTooltip is false? I think maybe I'm just misunderstanding what it's supposed to do.
There was a problem hiding this comment.
Screen.Recording.2023-05-18.at.11.15.05.AM.mov
it changes the mouse to indicate it's clickable, but no tooltip appears
There was a problem hiding this comment.
Thanks! I think that we should not be relying on a non-rendered tooltip for that (it feels like it's a side effect that's being abused and isn't very obvious). What I suggest is:
- Not rendering
<Tooltip>if we aren't showing a tooltip - Use a style to change the cursor if
<Tooltip>is not rendered
How difficult would it be to do that?
There was a problem hiding this comment.
I think the mouse cursor is due to the fact that the avatars are clickable and not related to the tooltip.
We have already changed the behaviour a little and the <Tooltip /> will render the child as is if there is no tooltip to show.
App/src/components/Tooltip/index.js
Lines 151 to 153 in 9e43cb7
There was a problem hiding this comment.
OK, that should work. Thanks
There was a problem hiding this comment.
While looking at the changes to <Tooltip> I think it would have been helpful to have the comment for text propType to mention that when text is empty, only the children will be displayed. I don't think it's obvious anywhere in the code that the text prop would control that. You would only know it if you looked at the render method, which shouldn't be necessary when implementing a component.
There was a problem hiding this comment.
App/src/components/Tooltip/index.js
Line 149 in 9e43cb7
This is the current comment
Reviewer Checklist
Screenshots/VideosMobile Web - ChromeMobile Web - SafariiOSAndroid |
tgolen
left a comment
There was a problem hiding this comment.
We talked briefly 1:1 about a possible way to clean this up so that the styles and the props make more sense. Right now, the <MultipleAvatars> is very coupled to whatever is rendering it (ie. it needs to know that it's rendered in a report action, the search, the LHN, or an IOU preview, etc.). This makes it hard to reuse. Let's extract this out a little bit by adding these separate props to <MultipleAvatars>:
borderColorborderColorHoveredborderColorPressed
NAB: at some point it would be good to split <MultipleAvatars> into two separate components:
<MultipleAvatars><MultipleAvatarsHorizontal>
| /** Whether to show the toolip text */ | ||
| shouldShowTooltip: PropTypes.bool, | ||
|
|
||
| /** Whether avatars are displayed within an IOUAction */ |
There was a problem hiding this comment.
NAB: this comment could be a little bit better like this (since it doesn't actually have anything to do with IOUs)
| /** Whether avatars are displayed within an IOUAction */ | |
| /** Whether avatars are displayed with the highlighted background color instead of the app background color. This is primarily the case for IOU previews. */ |
|
Ah, did you decide to not make these changes for the styles then? #19104 (review) |
|
@tgolen I started to work on those in a separate PR, do you think that they should be done in this PR? |
|
I think a separate PR is OK as long as it gets done 👍 |
|
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
|
🚀 Deployed to staging by https://github.com/tgolen in version: 1.3.18-0 🚀
|
|
🚀 Deployed to staging by https://github.com/tgolen in version: 1.3.18-0 🚀
|
|
🚀 Deployed to staging by https://github.com/tgolen in version: 1.3.18-0 🚀
|
|
@grgia Do we need to QA anything here? |
|
@mvtglobally yes, I updated the QA steps |
|
🚀 Deployed to production by https://github.com/yuwenmemon in version: 1.3.18-2 🚀
|




Details
When we get all the icons for a report, every icon is an object that has a key
nameassociated with its login. This is a much more reliable source to match for the tooltips.Fixed Issues
$ #19091
Tests
(WEB / DESKTOP ONLY)
Offline tests
QA Steps
(WEB / DESKTOP ONLY)
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
Mobile Web - Chrome
N/A
Mobile Web - Safari
N/A
Desktop
iOS
N/A
Android
N/A