-
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
Some random fixes #546
Some random fixes #546
Conversation
@@ -53,6 +60,7 @@ export class EuiConfirmModal extends Component { | |||
cancelButtonText, | |||
confirmButtonText, | |||
className, | |||
type, |
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.
Think we should just make this prop buttonColor
? Then you don't need the mapping and it's a little more flexible? Guessing we'll have other "types" beyond just these two, which are a little specifically named.
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's a very good question and I think it comes down to how we want to be building these components for use cases. Semantically or stylistically? And how rigorously are we trying to ensure proper usage?
We could decide on stylistically, and use buttonColor
(though which button do we mean), and then they (the consumers) have to decide on colors. Where as if we ask them what type
we choose the colors for them. So they're more deciding what it's supposed to represent versus how should it look. I tend to lean towards the former and use more semantic options that are clear.
On the flip side, or rather, almost a compromise to this, is that our color naming is pretty semantic already. So perhaps instead of asking them what buttonColor
, we still ask them what type
but that type
must be .oneOf(BUTTON_COLORS)
.
So that, for instance type="danger"
or type="success"
would color the button appropriately but also allow us to do any extra styling we may want (like color the title or add a giant flashing stop sign).
- Added drop shadows for overflows - Added padding to header to accomodate close button - Modal buttons should be normal size (not small)
Defaults to ‘confirm’ (positive/neutral), but can be ‘destroy’.
…tems` prop __’normal’ doesn’t do anything__
This reverts commit b27fe390272c84eda0af20434b83d588017b1b72.
Modals
Adjusting modals for mobile
Fixes EuiConfirmModal--option to set confirm button to red #520 Added a type prop to
EuiConfirmModal
Non-issues
Issues
flush
property makes focus background uneven #537 - Removing padding from both sides ofEuiEmptyButton
when flushFixes Fix accessibility issues in pagination #474 - Added disabled prop to placeholder (ellipses) pagination
Fixes <EuiFlexGroup> alignItems='baseline' support #423 - Added ‘baseline’ as option to
EuiFlexGroup
’salignItems
propFixes
euiHeader__notification
needs to be a component? #87 - Converted.euiHeader__notification
intoEuiHeaderNotification