-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Feature: Tooltip for QAB #40066
Feature: Tooltip for QAB #40066
Conversation
Niceee! Will we be able to put this into review today? |
@cubuspl42 Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
@@ -602,6 +602,10 @@ export default { | |||
trackManual: 'Crear Gasto', | |||
trackScan: 'Crear Recibo', | |||
trackDistance: 'Crear Gasto por desplazamiento', | |||
tooltip: { |
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.
Copy was verified here.
if (!shouldRenderWithoutHover) { | ||
return; | ||
} | ||
const childrenRect = e.nativeEvent.target?.getBoundingClientRect(); |
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.
The event target
here is specific to react-native-web
only.
}, []); | ||
|
||
useEffect(() => { | ||
const intervalID = setInterval(hideTooltip, 5000); |
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.
There's no observable user interaction to close this tooltip (cannot hover on mobile devices) so I assume that it should be closed in 5 seconds. Need design feedback here.
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.
@dubielzyk-expensify, whatcha' think? I think 5 seconds is fine.
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.
You can refer to the iOS Native screenshots in PR description to have a better sense.
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 feels right to me as long as it dismissed on any tap anyways.
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, any tap in the GC menu navigates you onwards to another page so it should be dismissed.
I like the little zoom out animation, but could we try it coming from the origin on where the pointing tip is? Feels a bit more correct |
@dubielzyk-expensify does this font size match your mocks? It looks like the tooltip font size is using normal font size which is 15px... just checking in case you intended for it to use the label size at 13px: |
src/styles/index.ts
Outdated
@@ -3674,6 +3674,22 @@ const styles = (theme: ThemeColors) => | |||
...wordBreak.breakWord, | |||
}, | |||
|
|||
quickActionTooltipWrapper: { | |||
backgroundColor: colors.green100, |
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.
cc @dubielzyk-expensify - are you thinking to use the same background color across themes?
Either way, I think we should make this a variable that is stored in both themes, basically treating it like any other color style we use.
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.
Yes I forgot to ask you about this. I couldn't get the exact color hex from the mockup.
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.
If we go with the one specified above, then yes, I was gonna keep the same look regardless of theme as it feels good in both light and dark mode
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.
Okay sweet, thanks for confirming. Even though they are the same across both themes, I think we should still take the same approach we do for all other colors here.
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.
Also noting that we do have existing tooltip styles, so maybe we can consider this an extension of that... like highlightTooltip
or something?
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 that idea!
src/styles/index.ts
Outdated
quickActionTooltipTitle: { | ||
fontFamily: FontUtils.fontFamily.platform.EXP_NEUE_BOLD, | ||
fontWeight: FontUtils.fontWeight.bold, | ||
fontSize: variables.fontSizeNormal, |
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.
cc @dubielzyk-expensify in case this should be label
and not normal
.
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.
Yep should be label
src/styles/index.ts
Outdated
fontWeight: FontUtils.fontWeight.bold, | ||
fontSize: variables.fontSizeNormal, | ||
lineHeight: variables.lineHeightXLarge, | ||
color: colors.green500, |
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.
Same comment as above, we should make these theme-friendly color values.
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.
If this color does not differ between the themes, should we make them theme-friendly? Otherwise can you give me the mockup in light mode?
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.
And I need the exact color of the text here as well.
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.
If this color does not differ between the themes, should we make them theme-friendly?
My vote is yes, in case we ever add a 3rd theme or make these theme dependent in the future.
src/styles/index.ts
Outdated
fontFamily: FontUtils.fontFamily.platform.EXP_NEUE_BOLD, | ||
fontWeight: FontUtils.fontWeight.bold, | ||
fontSize: variables.fontSizeNormal, | ||
lineHeight: variables.lineHeightXLarge, |
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.
Why do we need a huge line height here? I would think we could just vertically center the text via flex or use inner padding instead? I don't feel strongly though. Curious what we are using in the Figma.
Ah to be clear, I'm not challenging your font choice or background choice. I was just confirming that the font choice in this PR was correct, and it looks like it wasn't. I'm down with 13px. Then for your background color, again I'm cool with what it looks like but just wanted to confirm if it changes across themes or not? What does the light mode version look like? |
@@ -0,0 +1,137 @@ | |||
import React, {useEffect, useMemo, useRef, useState} from 'react'; |
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.
File-scoped comment.
The amount of duplication between index.tsx
and index.native.tsx
is unacceptable. This is a big one.
Likely, there's a tough refactoring ahead of us.
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.
The amount of duplication between index.tsx and index.native.tsx is unacceptable. This is a big one.
I have thought about this a lot but this is just a temporary fix for the current expected behavior. The tooltip's position logic is really complicated and it's very hard to mimic all that for native platforms. For example, I eliminated shouldShowBelow
check and horizontalShift
calculations.
But as the mockup here implied, I think they would want to make all that behaviors work on native in the future. So I think seperating these files is neccessary.
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'm not saying that we don't need any platform-splitting to *.tsx
and *.native.tsx
files, or that we need to implement all complex features on Native that the general-case Web hover-on tooltips need. On Native we'll be showing only the "educational" tooltips.
For example, you correctly assumed that it's not required to dynamically resize tooltips, as educational tootlips likely won't need this behavior soon, or ever. In general, the hover-on tooltips can resize in corner cases.
Still, there are many code de-duplication techniques that can be applied here, even with the simplifications and shortcomings we accepted.
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 give this a try. I feel like little effort has been put into de-duplication here so far. But if you run out of ideas, let me know, as I'll likely be able to help.
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.
HI @cubuspl42, I've tried it but considering the only difference between those files are how the wrapper and content are measure, and the complexity of the web implementation, I couldn't come up with a better solution. Could you please suggest me some approaches to speed things up?
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.
TooltipRenderedOnPageBody is still basically a copy-pasted component, though. We should use the same techniques in this case.
Deduplication for TooltipRenderedOnPageBody
would be to lift these logic up to GenericTooltip
but the bound measurement and getTooltipStyle
must stay in the same component otherwise it would cause a state "unsynchronization" and cause #18189. I think that's the minimum logic required for everything to function properly and won't need deduplication.
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.
How's about BaseGenericTooltip
Semantically, I don't think it's that's a lucky choice. In this case, we're not only having yet-another-layer of component that's actually used to render the same chunk of UI eventually. Remember that the name Tootlip
was always meaning the tooltip target wrapper, while TooltipRenderedOnPageBody
was focused on realizing the actual tooltip wrapper & content.
Pragmatically, we have another problem. As I'm challenging the amount of duplication in this new TooltipRenderedOnPageBody
replacement (let's call it RenderedTooltip
for this reasoning), the solution might involve creating BaseRenderedTooltip
, while BaseBaseGenericTooltip
sounds kind of mad.
So I'd vote for some Base-less Generic-less name, and RenderedTooltip
sounded like a minimal change, just throwing out the DOM-specific aspect (OnPageBody
/ on page <body>
).
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.
What also somehow bothers me is that BaseFoo
can mean anything, it just says "well, Foo was taken 🤷♂️". It's either because we want a BaseFoo
optionally-rendered by Foo
, it can also be cross-platform BaseFoo
, where actual platform-specific Foo
injects some delegates, and here it's just a BaseFoo
rendered in another cooridante space, owned by Foo
. It's a naming mess, in my opinion. I wouldn't add to it if possible.
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.
In our case, number 2 (base foo = cross-platform foo) collides with number 3 (base foo = different coords foo)
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.
@tienifr, we could at least lift this rendering logic up to a generic component, what do you think?
@eVoloshchak @Gonals can we get feedback to @tienifr on the above, please? |
I'm still testing its feasibility. Anyway, it still seems overkill. I'll push the latest changes today. |
Thanks, please do! |
Any news on this? We also got a new conflicts 😄 |
@tienifr I see commits, is it ready for @eVoloshchak to take another look? 🙏 |
Something was wrong with the popover size on But I resolved the issue with |
Check failures are not related to this PR. |
Seems like we have some conflicts |
All set! Awaiting input from @eVoloshchak. |
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.
Tests well
Awesome job, @tienifr!
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
@Gonals You could have waited for my final review 😞 |
🚀 Deployed to staging by https://github.com/Gonals in version: 1.4.86-0 🚀
|
1 similar comment
🚀 Deployed to staging by https://github.com/Gonals in version: 1.4.86-0 🚀
|
🚀 Deployed to staging by https://github.com/Gonals in version: 1.4.86-0 🚀
|
🚀 Deployed to production by https://github.com/AndrewGable in version: 9.0.0-9 🚀
|
Details
Display a tooltip the first time the QAB is set.
Fixed Issues
$ #38054
PROPOSAL: #38054 (comment)
Tests
Offline tests
NA
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label and/or tagged@Expensify/design
so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
Android: mWeb Chrome
iOS: Native
iOS: mWeb Safari
MacOS: Chrome / Safari
MacOS: Desktop