-
Notifications
You must be signed in to change notification settings - Fork 842
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
Beta Badges #705
Beta Badges #705
Conversation
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.
This looks really nice - thank you
</p> | ||
<p> | ||
They can also be used in conjunction | ||
with <EuiLink href="/#/display/card">EuiCards</EuiLink> and EuiKeyPadMenuItems. |
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.
Can you also make EuiKeyPadMenuItems a link to key pad menu?
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, I meant to do that. Thanks.
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.
These look great. Minor comments in the API naming, but otherwise they look hot.
I think it'd be nice if you could pass an icon specifically to the keypad one. I imagine a "beaker" icon or something might read better initially other than the "B" or "L".
This is a really nice example though of all our components coming together individually.
|
||
font-size: $euiSizeM; | ||
font-weight: $euiFontWeightBold; | ||
letter-spacing: .05em; |
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.
This is great. Should we make some spacing vars in typography? $euiSpacingS/M/L
...etc?
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.
This is a very rare case, mainly only needed for bold and uppercase type. I don't think it's necessary to make variables as it wouldn't really be an override.
Though looking at this I did just realize that the font-size isn't using a font-size variable like it should. I'll change that.
text-transform: uppercase; | ||
line-height: $euiSizeL; | ||
text-align: center; | ||
white-space: nowrap; |
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 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, I can add a max-width for card implementations. But you're right that these should not contain more than 1-2 words ever.
return ( | ||
<EuiToolTip | ||
position={tooltipPosition} | ||
content={description} |
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.
Normally when we've done this kind of passthru we've tried to keep the naming similar... aka EuiIcon
's type
prop becomes iconType
when passed through to another component. Just helps better understand the API a bit. Might want to consider doing that here. For example, I see you're doing it in the line above will tooltipPosition
left: 50%; | ||
transform: translateX(-50%); | ||
z-index: 3; // get above abs positioned image | ||
min-width: 40%; /* 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.
Nice touch here.
width: $euiSizeL; | ||
padding: 0 8px; /* 2 */ | ||
overflow: hidden; /* 2 */ | ||
letter-spacing: 3rem; /* 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.
Same comment on variabalizing this 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.
Yeah, and same response to this as well, super-specific use case here where I'm just separating the letters enough to only show 1 letter. Doesn't make sense for it to be a variable.
<div className="euiKeyPadMenuItem__inner"> | ||
{betaLabel && | ||
<span className="euiKeyPadMenuItem__betaBadgeWrapper"> | ||
<EuiBetaBadge label={betaLabel} title={betaLabel} description={betaDescription} className="euiKeyPadMenuItem__betaBadge" /> |
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.
Similar comment about passthru naming. betaLabel
should maybe be betaBadgeTitle
, description becomes toolTipContent
...etc.
Just thinking out loud here. I know we're now three removed from the tooltip, but I think it might make it easier to understand. What do you think?
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 would have to be betaBadgeTooltipContent
or else it could get confusing what the tooltip will be for. Does that then start getting down a slippery slope of giant naming conventions?
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're right, and I think we should be OK with being overly explicit. Think of someone with no knowledge of the component on some random page. At least they'll understand what is what just by reading it, otherwise you might assume the description is tied to the menu item directly.
It's pretty rare to have a three deep passthru like this. Even more so for one that isn't initially visible during render.
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 would you do for naming when a prop can be used in multiple ways? For instance, the title
prop will either be the EuiTooltip title={title}
or <span title={title}>
.
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.
Dealers choice! I'd probably use a unique name if it's an either / or. Whatever you think is best.
- Fixing use of font-size variables - Adding example of badge inline with title - Max-widthed the card version - Now always using the label as the tooltip title or title attr if title is not supplied - Fixing naming conventions to better suit imported components - Allowing icon only badges
@snide Ok I addressed all your comments.
|
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.
👍 🙌
Fixes #682
This adds a new component called
EuiBetaBadge
that only accepts alabel
anddescription
. It will only add a tooltip if thedescription
prop exists.Can be used on cards
And Key Pad Menu Items
This will truncate to only one letter and ensure the full label is supplied to the tooltip as a title or if there is no tooltip (no description) it will add the title just as a norma
title
attribute.cc @nreese