-
Notifications
You must be signed in to change notification settings - Fork 841
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
Define SideNav items with a tree structure #141
Define SideNav items with a tree structure #141
Conversation
Would be nice if we started pasting screenshots of the PR to get a glimpse of what's implemented/changed. Think you could do that here? 😅 |
@bevacqua Yep! I was going to add a gif once this was ready for review. Sorry, I should have added a WIP tag. |
@snide @gjones @Adrian-J @formgeist @bevacqua This is ready for your review! I suggest checking out this branch and playing with it in the browser to get a feel for the interaction. The side nav in the docs themselves is also worth trying out because, due to a quirk in the implementation, the subsections of each page aren't registered until after that page has been visited. Which means that each section initially doesn't show a caret, but does show a caret after you visit that page. To be honest, I didn't miss the caret. What do y'all think? |
@cjcenizal looks great. only comment, can the expanded version push the rest down instead of up? |
Does it have to be |
Thanks @Adrian-J that "pushing up" is a side-effect because this example is at the bottom of the page. So it's making the page taller and Chrome will "stick" you to the bottom of the page as the page expands. So long story short... yes, it's already pushing the rest down as you would expect. @formgeist I'll leave that one to @snide. |
Something does feel a little off to me with that caret, I think it's because I would expect it to be the So something like below (excuse the hasty, gross designs) becomes Also, I should add, I wouldn't be opposed to the carets being light grey and only appearing on hover. |
@cjcenizal makes sense. One more thing I haven't noticed before, I think the 2nd level vertical line should be left-aligned with the 1st level title. Looks cleaner that way. |
@Adrian-J It's funny you mention that because I actually had the same thought and tried it out: When I looked at it originally it felt weird to me, but now looking at it again I kind of like it. I'll let you and Dave hash it out. |
@cjcenizal I like this version much better. Great job! |
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.
Minor stuff. Feel free to merge whenever.
I do think it's really weird to see the carets in the docs only after you've clicked them. Can fix later, but if that happened in a prod scenario I'd think it was kind of busted.
margin-bottom: $euiSizeS; | ||
padding: 0; | ||
padding-left: $euiSizeS; /* 1 */ | ||
margin-left: -$euiSizeS; /* 1 */ |
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.
src-docs/src/views/flex/use_span.js
Outdated
|
||
export default () => ( | ||
<EuiFlexGroup useSpan> | ||
<EuiFlexItem useSpan>This a span within a span</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.
Any time you'd mix spans and divs? If not, should this just be on EuiFlexGroup
and not the items itself? Not a blocker, just if it's easy it's probably easier to consume.
Maybe give a better example of why you'd want to use spans? I assume it's because you want to sit within a button rather than KeyboardAccessible
? Maybe show the example inside of a button then to illustrate 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.
Any time you'd mix spans and divs?
Good question, but I'm not sure to be honest. Since I can't say one way or the other I think I should assume there's a good use case I'm just not aware of. We can find a way to lock it down later if people find this un-ergonomic.
Maybe give a better example of why you'd want to use spans?
Good call, I'll put it inside a button
to make this clearer.
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.
Yep, makes sense.
} | ||
|
||
&.euiSideNavItem--parent.euiSideNavItem-isSelected { | ||
color: $euiColorFullShade; | ||
&.euiSideNavItemButton-isOpenable { | ||
background: svg-load('../src/components/icon/assets/arrow_down.svg') center right no-repeat; |
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 possible, I'd instead use EuiIcon
instead of this hacky CSS solution. That way it can be colored (it should probably be subdued). Right now this breaks in dark mode because it's hard coded.
Don't want to hamper your PR, so if you merge it as is, just make an issue to cover it. We can figure it out later.
@cjcenizal Don't forget to update the changelog before you merge this. |
return { | ||
...section, | ||
}; | ||
}); |
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.
tiny stylistic proposal:
=> ({ ...section })
name: subSection.name, | ||
onClick: this.onClickLink.bind(this, subSection.id), | ||
})); | ||
} |
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.
#nicohat -- could lose the mutable var by turning this into a function that takes subSections and guards on it being falsy
name: subSection.name, | ||
onClick: this.onClickLink.bind(this, subSection.id), | ||
})); | ||
} |
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.
(and benefit from it here as well)
src/components/flex/flex_group.js
Outdated
justifyContent, | ||
useSpan, | ||
...rest, | ||
}) => { |
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.
Rather than useSpan
which seems overly prescriptive, could I suggest component: Component = 'div'
and return <Component ... />
? Could easily propType it to oneOf(['div', 'span'])
to lock it down to those two.
Edit: to clarify, usage would be <FlexGroup component='span' />
instead of <FlexGroup useSpan />
- Automatically determine open state based on selected item. - Add support for href and onClick. - Allow root items to be collapsed.
75e0b1b
to
0195fae
Compare
CHANGELOG.md
Outdated
@@ -1,8 +1,13 @@ | |||
# [`master`](https://github.com/elastic/eui/tree/master) | |||
|
|||
- `<EuiFlexItem>` now accepts integers between 1 and 10 for the `grow` prop. [(#144)](https://github.com/elastic/eui/pull/144) | |||
- `<EuiFlexItem>` and `<EuiFlexGrow>` now accept a `component` prop which you can set to `span` or `div`. [(#141)](https://github.com/elastic/eui/pull/141) |
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.
Perhaps an indication as to the default (which therefore shouldn't be explicitly specified)?
LGTM aside from one very minor comment about the changelog entry! |
Thanks @zinckiwi ! |
While I was playing with this, the static behavior of the carets felt weird. I'd click on an item to open it, and the caret felt redundant once it was opened. I wonder if we even need the caret? Is it there to communicate to users that something expands? If so, do we need to communicate that?
To-do:
isInline
prop on flex components