-
Notifications
You must be signed in to change notification settings - Fork 14.1k
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
feat(explore): Dataset panel option tooltips #19259
feat(explore): Dataset panel option tooltips #19259
Conversation
Codecov Report
@@ Coverage Diff @@
## master #19259 +/- ##
=======================================
Coverage 66.65% 66.65%
=======================================
Files 1675 1675
Lines 64653 64658 +5
Branches 6503 6505 +2
=======================================
+ Hits 43092 43096 +4
Misses 19875 19875
- Partials 1686 1687 +1
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
@@ -46,9 +46,15 @@ export const Tooltip = ({ overlayStyle, color, ...props }: TooltipProps) => { | |||
overlayStyle={{ | |||
fontSize: theme.typography.sizes.s, | |||
lineHeight: '1.6', | |||
maxWidth: 250, |
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 width is relative to the tooltip's container, maybe we can do something like calc(100% - gridUnit * 4)
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.
It's not relative to tooltip's container, it's the tooltip's container 🙂 But you're right, let's use grid units
@@ -46,9 +46,15 @@ export const Tooltip = ({ overlayStyle, color, ...props }: TooltipProps) => { | |||
overlayStyle={{ | |||
fontSize: theme.typography.sizes.s, | |||
lineHeight: '1.6', | |||
maxWidth: 250, | |||
minWidth: 120, |
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.
Might as well make this gridUnit based, too.... it's a nice round number at least :D
display: flex; | ||
flex-direction: column; | ||
font-size: ${theme.typography.sizes.s}px; | ||
line-height: 1.2; |
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.
Not relevant to this PR, but we should probably add a range of line heights to our theme at some point. CC @michael-s-molina
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.
PR LGTM.
But I have a concern about the design. Description
and name
/verbose_name
are used with different intents.
name
/verbose_name
is related to query and modeling for the dataset.description
may have a lot of content for the current column/metric, this field is unrelated to query and modeling.
The description information put into the tooltip may make this popup larger than before.
// @ts-ignore | ||
// eslint-disable-next-line import/no-extraneous-dependencies | ||
import { render, screen } from 'spec/helpers/testing-library'; |
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.
Should we bring RTL
into Superset-ui ?
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 think it makes more sense to test this component with RTL rather than deeply comparing JS objects created by React. However, like Michael noticed in a comment in different PR, we shouldn't import from spec/
in superset-ui
. I'll import RTL directly until we solve the problem of cyclic dependencies
@@ -60,22 +96,27 @@ export const getMetricTooltipNode = ( | |||
labelRef?: React.RefObject<any>, | |||
): ReactNode => { | |||
// don't show tooltip if it hasn't verbose_name, label and hasn't truncated |
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.
update comment: // don't show tooltip if it hasn't verbose_name, label, description, and hasn't truncated
@@ -36,21 +68,25 @@ export const getColumnTooltipNode = ( | |||
labelRef?: React.RefObject<any>, | |||
): ReactNode => { | |||
// don't show tooltip if it hasn't verbose_name and hasn't truncated |
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.
update comment: // don't show tooltip if it hasn't verbose_name, description and hasn't truncated
Hey @zhaoyongjie, thanks for comments. Currently this component (drag&drop field) is overloaded with tooltips and it is definitely not a good user experience. Additionally, besides the tooltip the user gets while hovering over the name, we also show 4 additional/optional tooltips that appear while hovering over an icon. This is not a good flow, as:
Although name and description may come from the different sources, they have the same context - these are basically the details of the column or metrics, so it makes sense to put them in one tooltip. Although it may become long it will still be more readable than it is now. |
return ( | ||
<> | ||
<TooltipSection label={t('Metric name')} text={metric.metric_name} /> | ||
{(metric.label || metric.verbose_name) && ( |
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 both are falsy, but not empty, it could potentially render something.
Even if they're typed as strings (which would be fine), it's better to be sure and assert this short circuit checks to boolean values, either with !!
or Boolean(condition)
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 think empty strings in logical expressions always resolve to False
and explicitly casting them to Boolean is redundant. Is there an example when that's not the case?
@@ -60,22 +96,27 @@ export const getMetricTooltipNode = ( | |||
labelRef?: React.RefObject<any>, | |||
): ReactNode => { | |||
// don't show tooltip if it hasn't verbose_name, label and hasn't truncated |
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.
is this comment adding anything? (we should add the description property in any rate)
@@ -36,21 +68,25 @@ export const getColumnTooltipNode = ( | |||
labelRef?: React.RefObject<any>, | |||
): ReactNode => { | |||
// don't show tooltip if it hasn't verbose_name and hasn't truncated |
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.
is this comment adding anything? (we should add the description property in any rate)
Thanks for the explanation! If this description is large, the tooltip will mask the other columns above it when the user pick another column. Screen.Recording.2022-03-21.at.6.39.01.PM.mov |
@zhaoyongjie Generally in Superset we let the user hover over the tooltip itself, but it's probably not a correct behaviour as the tooltip should disappear when user is not hovering over the trigger. In other words, by default we should hide the tooltip as soon as the cursor moves from the trigger, even if user tries hovering over the tooltip text. There are some cases in which such flow could be allowed (like for example filter cards in native filters, where some tooltip elements are interactive), but here it doesn't make much sense. |
d21a84b
to
24d2afa
Compare
@zhaoyongjie As we discussed, tooltips disappear when you stop hovering on the label, so they shouldn't be annoying for the users when they browse the dataset panel Screen.Recording.2022-03-24.at.13.14.13.mov |
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
* feat(explore): Add description to column/metric tooltips in dataset panel * Fix tests * Address code review comments (cherry picked from commit 45c28c8)
* feat(explore): Add description to column/metric tooltips in dataset panel * Fix tests * Address code review comments
SUMMARY
This PR introduces changes to the tooltips that appear when user hovers over metric/column label in dataset panel in Explore.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
Before:
After:
TESTING INSTRUCTIONS
Add some labels and descriptions to metrics and columns, verify that tooltips display correctly
ADDITIONAL INFORMATION
CC @kasiazjc