-
Notifications
You must be signed in to change notification settings - Fork 843
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
Responsive refactors and addition of helpers #909
Conversation
CHANGELOG.md
Outdated
@@ -5,6 +5,12 @@ | |||
- Added `resize` prop to `EuiTextArea` that defaults to ‘vertical’ (only height) ([#894](https://github.com/elastic/eui/pull/894)) | |||
- Added multiple style-only adjustments to `EuiFormControlLayout` buttons/icons ([#894](https://github.com/elastic/eui/pull/894)) | |||
- Shifted `readOnly` inputs to not have left padding unless it has an icon ([#894](https://github.com/elastic/eui/pull/894)) | |||
- Added responsive helpers in the form of `EuiShowFor` and `EuiHideFrom` components and corresponding CSS classes. ([#909](https://github.com/elastic/eui/pull/909)) |
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.
Just a small suggestion: EuiShowWithin
and EuiHideWithin
might reduce the cognitive overhead a bit, because I had to double-check and compare "for" vs. "from" mentally, and then I realized they actually mean the same thing. And maybe it's just me, but I usually think of a breakpoint being within a min and a max.
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 hear ya with the naming, though I think "within" sounds odd. How about both of them just using "For"? This is usually how other frameworks handle it.
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.
Sounds good to me!
import { EuiHideFrom } from './hide_from'; | ||
|
||
describe('EuiHideFrom', () => { | ||
test('is rendered', () => { |
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 we also loop through and test all of the sizes like we do in https://github.com/elastic/eui/blob/master/src/components/button/button.test.js#L91 ?
- Changed `EuiHideFrom` to `EuiHideFor` - Looping through sizes in tests - Fixed typo in `EuiShowFor` classname
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. Had some small questions, but address them how you think best.
} | ||
|
||
@each $size in $euiBreakpointKeys { | ||
.euiHideFor--#{$size} { |
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.
As utilities should we use the same prefixing as our other css utilities? eui-
. Know you're using these in the component themselves, so I could see why we'd name them this way too, but I'd probably err to uniformity against the CSS stuff since that's something you tend to memorize? Oh it's a utility, i know it starts with...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.
As long as you're ok using the utility class naming style in the components, I'm fine with it too and can change it.
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 think it's fine to use them there.
// A sem-complicated mixin for breakpoints, that takes any number of | ||
// named breakpoints that exists in $euiBreakpoints. | ||
|
||
@mixin euiBreakpoint($sizes...) { |
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 really nice function and so much better. Bravo.
{sizes.euiBreakpointKeys.map(function (size, index) { | ||
return renderSizes(size, index); | ||
})} | ||
</EuiCodeBlock> |
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 would love to see this using our "blue" wrapper boxes to show people the actual sizing. It might help visualize the sizing more quickly. Even possibly listing out the more common scenarios (tablet and below is... size={xs,s}
...etc.
Don't think it needs to be for this PR, and I'm happy to set it up after you merge since you did all the leg work.
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.
Ah, I can do that.
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.
@snide Here's the problem I'm running into with your suggestion. The screen and especially that side of the page never gets large enough to show the full width of anything above size 's'. Unless I'm just not understanding what you mean.
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.
Didn't think about this. One thing we could do is make some page outlines that were fixed positon, or just take these bars and fix them to the bottom of the page (maybe make them thinner).
Always something we can do a bit later. Don't want to hold up your PR on this.
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, ok, I'll push this idea off for later.
Deprecation warning for
$breakpoints
and any current responsive mixinsRefactored responsive breakpoints
Reasoning: The naming between the breakpoints map and mixins were misleading and the mixin
screenSmallMediumLarge()
was too much of a hack. The refactor ensure the breakpoints you specify are the breakpoints you get.$breakpoints
map is now$euiBreakpoints
and starts at 0-1200px+:The map has also been moved out of the
mixins/_responsive.scss
to a correspondingvariables/_responsive.scss
file.There is now one
euiBreakpoint()
mixin that accepts an array of named break points match those in the$euiBreakpoints
map.Example usage:
will result in:
@include euiBreakpoint('xs','s')
is also a direct replacement for@include screenXSmall()
. Be mindful that the breakpoint name to px values have changed in the new map.EUI components should all now be updated to use the new map and mixin.
Added responsive utilities
Classes
The responsive classes utilize the map and mixin to create
.euiShowFor--[size]
and.euiHideFor--[size]
classes.Example compiled
Components
EuiShowFor
andEuiHideFor
components take asizes
prop as an array of named sizing which correlate to the same SASS map. They wrap the child element in a<span>
with the corresponding utility class applied.