-
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
Add numbers between 1 and 10 for flexGrow #144
Conversation
src/components/flex/flex_item.js
Outdated
@@ -7,6 +7,7 @@ export const EuiFlexItem = ({ children, className, grow, ...rest }) => { | |||
'euiFlexItem', | |||
{ | |||
'euiFlexItem--flexGrowZero': !grow, | |||
[`euiFlexItem--flexGrow${grow}`]: Number(parseFloat(grow)) === grow && grow >= 1 && grow <= 10 |
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.
How come thing is parseFloat
, as opposed to parseInt
?
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.
absentmindedness, that's why
@@ -7,6 +7,7 @@ export const EuiFlexItem = ({ children, className, grow, ...rest }) => { | |||
'euiFlexItem', | |||
{ | |||
'euiFlexItem--flexGrowZero': !grow, |
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.
Does this need guarding against a numeric value?
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.
Don't think so. Any falsy value would work, proptypes says bool or number, so that's 0
or false
.
Just to check - do these layouts still collapse as you'd expect on mobile? |
Yep, collapsing works fine. |
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
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 sweet! I just had a couple minor comments.
src/components/flex/flex_item.js
Outdated
@@ -7,6 +7,7 @@ export const EuiFlexItem = ({ children, className, grow, ...rest }) => { | |||
'euiFlexItem', | |||
{ | |||
'euiFlexItem--flexGrowZero': !grow, | |||
[`euiFlexItem--flexGrow${grow}`]: Number(parseInt(grow)) === grow && grow >= 1 && grow <= 10 |
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 add a prop type checker to contain these conditions, and throw errors if it fails?
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 this just be
[`euiFlexItem--flexGrow${grow}`]: grow
now?
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.
Depends how much you trust people to fix prop type warnings I suppose! For the sake of that extra bit, I'd personally favour not adding superfluous classes, but can change if anyone contends otherwise (including yourself).
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 can still be a boolean though, no?
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.
(though even then we'd need to catch true
)
edit: nm, 1 == true
edit edit: I must be tired. Precisely because true >= 1 === true
we'd need to catch 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.
Hmm, my instinct is to simplify this as much as possible, which would mean relying on the prop-types error and the CSS to apply the correct styling. That way if someone passes in "11", debugging means checking 2 places instead of 3. And likewise adding support for 11 means making changes in 2 places instead of 3.
That being said, I don't feel very strongly about this. It's your call. 😄
EDIT: In terms of supporting the boolean value, then I think this will do the trick?
[`euiFlexItem--flexGrow${grow}`]: grow && grow > 0
export default () => ( | ||
<div> | ||
<EuiFlexGroup> | ||
<EuiFlexItem grow={1}>1</EuiFlexItem> |
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 add some additional content to this first item to demonstrate that it wraps without pushing the column wider?
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! Had one optional comment.
<EuiFlexItem grow={2}>2</EuiFlexItem> | ||
<EuiFlexItem grow={3}>3</EuiFlexItem> | ||
<EuiFlexItem grow={2}>2<br />wraps content if necessary</EuiFlexItem> | ||
<EuiFlexItem grow={3}>3<br />expands_to_fit_if_content_cannot_wrap</EuiFlexItem> |
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!
src/components/flex/flex_item.js
Outdated
|
||
if (validValues.indexOf(value) === -1) { | ||
return new Error( | ||
'Prop `' + propName + '` supplied to' + ' `' + componentName + '` must be a boolean or an integer between 1 and 10.' |
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 you want, you could use a template literal here:
`Prop \`${propName}\` supplied to \`'${componentName}\` must be a boolean or an integer between 1 and 10.`
Rather than dancing around JS hoops with |
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 the implementation is fine. My only worry is that this flexibility might create some choose your own adventure grid systems.
Cons:
- It requires stacking if you want two rows.
- Because of that, it'll require you to use an
EuiSpacer
to manage the spacing between those rows. You'd need to know to match the spacing size against the gutter size if you used anything but the defaults.
Pros:
- As long as you're aware of those cons, you can configure any layout you likely want. But you'll need to hand construct it.
Possible alternative
We also apply this to EuiFlexGrid
and allow the grow
prop to take on the number of columns passed to the parent wrapper. Meaning I could set columns={12}
and pass grow={4}, grow={4}, grow={4}, grow={6}, grow={6}
on flex items inside to create 3 columns on row 1 and 2 columns on row 2. This would allow for more conventional wraps and act similar to similar grid systems. The downside here is that "grow" would mean two different things depending upon the wrapper (grow in Group is proportional against a total, grow in Grid is proportional against a passed number of allowed columns).
I'm just spitballing here. If people are OK with Scott's implementation I think it's flexible enough to work how we'd want, but it would be off-pattern for how people normal consume grids (ands that OK, I'm just bringing it up).
FWIW we could add the grid style one in a later PR.
<EuiFlexItem grow={4}>4</EuiFlexItem> | ||
</EuiFlexGroup> | ||
|
||
<br/><br/> |
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 should be an EuiSpacer
. It will create a vertical margin to match the horizontal ones.
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 copied from an adjacent block, FYI)
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.
Then change it there too if you have time. Likely I built this stuff before I had spacer built. 😢
I always assume people will copy code out of the docs literally, so we should show them how to properly space stuff when we can.
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.
Updated the instances of <br /><br />
in the flex area.
👍 @snide If the additions you have in mind won't require changing or removing the functionality added in this PR, then I think this is a good step forward. The cons you mention sound like good things to be aware of when building layouts with these tools. @zinckiwi Maybe in a subsequent PR you can add a sandbox which demonstrates a layout using |
@cjcenizal Yeah, I agree. This is fine to merge. My stuff can go in later, and more likely, we'll need to create better "layout" documentation. |
* Add numbers between 1 and 10 for flexGrow * Parse grow prop better * Add more granular prop type checking to FlexItem and expand doc * Add changelog entry * Switch string to interpolated * Be explicit with grow prop className building * Clean up double-brs in docs
Here's the proposal for arbitrary (well, up to a certain point) weighting for
FlexItem
.