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

Interoperability of EuiBottomBar and EuiNavDrawer #3146

Closed
sorenlouv opened this issue Mar 22, 2020 · 7 comments
Closed

Interoperability of EuiBottomBar and EuiNavDrawer #3146

sorenlouv opened this issue Mar 22, 2020 · 7 comments

Comments

@sorenlouv
Copy link
Member

APM has started using EuiBottomBar and we’re running into an issue where it overlays on top of EuiNavDrawer.

image

Talking to @cchaos I can see why it happens (not every consumer of EuiBottomBar also uses EuiNavDrawer so EUI can’t simply offset by default).

Currently, the only way for us to fix this is by hardcoding margin-left: 48px; z-index: 9;. This doesn’t seem great because if EuiNavDrawer ever changes width this will break.

Would it be possible to have a prop to indicate that the consumer is using EuiNavDrawer - like <EuiBottomBar hasNavDrawer={true} />

@cchaos
Copy link
Contributor

cchaos commented Mar 23, 2020

@sqren Yeah, I know that it's hard to utilize the bottom bar in the current Kibana implementation alongside EuiNavDrawer.

The main issue with trying to manage this from the EUI side, is that there are actually multiple sizes of the EuiNavDrawer depending on it's state. So consuming applications will still need to know the collapsed and locked state of their nav drawer. Your screenshot is showing the "locked open" state, which is are far more than 48px.

This is why I've advocated that the consuming applications (Kibana) creates a global service like the Toast and Modal services that can then control the placement and extra margins when necessary in one place.

@seeruk
Copy link
Contributor

seeruk commented Apr 22, 2020

Another one that doesn't quite work is an EuiPage with restrictWidth set to true. It shrinks the page even if there's plenty of room either side of the page for the menu. Ideally it'd just re-centralise the EuiPage in the leftover space and as you get to a small enough size for the EuiPage to touch the nav drawer, that'd be the ideal time for the EuiPage to start shrinking in size.

@cchaos
Copy link
Contributor

cchaos commented Apr 22, 2020

@seeruk Sounds unrelated to either EuiBottomBar or EuiNavDrawer. Maybe you could open another ticket with a screenshot for guidance?

@cchaos
Copy link
Contributor

cchaos commented Sep 18, 2020

This component is being deprecated in favor of EuiCollapsibleNav

@cchaos cchaos closed this as completed Sep 18, 2020
@sorenlouv
Copy link
Member Author

sorenlouv commented Sep 19, 2020

@cchaos Is EuiCollapsibleNav a direct replacement for EuiBottomBar?

Won't this make the screen jump when the user edits a field, since it will make the "You have unsaved changes" mode kick in? That seems a bit disruptive.

@cchaos
Copy link
Contributor

cchaos commented Sep 20, 2020

I'm not quite following your second question. But EuiCollapsibleNav is replacing EuiNavDrawer not EuiBottomBar. EuiCollapsibleNav doesn't have the same icon only, skinny, version. It always sits on top of all the content like a normal flyout when it is open. On the Kibana side, the CoreUI team has implemented a global style to shrink the width of the EuiBottomBar if the user has docked the EuiCollapsibleNav (man navigation).

@sorenlouv
Copy link
Member Author

sorenlouv commented Sep 21, 2020

Ah, sorry. I get it now. When you said "This component is being deprecated in favor of EuiCollapsibleNav" I thought you meant it was replacing EuiBottomBar. Replacing EuiNavDrawer makes a lot more sense 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants