Skip to content
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

Merged
merged 12 commits into from
Jun 8, 2018

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Jun 6, 2018

Deprecation warning for $breakpoints and any current responsive mixins

Refactored 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+:

$euiBreakpoints: (
  "xs": 0px,
  "s":  575px,
  "m":  768px,
  "l":  992px,
  "xl": 1200px
) !default;

The map has also been moved out of the mixins/_responsive.scss to a corresponding variables/_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:

@include euiBreakpoint('xs','s') {
  display: none;
}

will result in:

@media only screen and (max-width: 574px) {
  display: none;
}
@media only screen and (max-width: 767px) and (min-width: 575px) {
  display: none;
}

@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

@media only screen and (max-width: 574px) {
   .euiHideFor--xs {
     display: none !important;
   }
}

Components

EuiShowFor and EuiHideFor components take a sizes 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.

screen shot 2018-06-07 at 12 37 21 pm

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))
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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', () => {
Copy link
Contributor

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 ?

cchaos and others added 2 commits June 7, 2018 12:24
- Changed `EuiHideFrom` to `EuiHideFor`
- Looping through sizes in tests
- Fixed typo in `EuiShowFor` classname
Copy link
Contributor

@snide snide left a 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} {
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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...) {
Copy link
Contributor

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>
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

screen shot 2018-06-08 at 10 09 51 am

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@cchaos cchaos merged commit 2f7d21f into elastic:master Jun 8, 2018
@cchaos cchaos deleted the responsive-helpers branch June 8, 2018 16:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants