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

[7467] Add "Collapse/Expand" button to sidebar. #7723

Merged
merged 7 commits into from
Aug 18, 2016

Conversation

cjcenizal
Copy link
Contributor

@cjcenizal cjcenizal commented Jul 12, 2016

Addresses #7467.

Blocked by #7711. Once that PR is merged, we'll rebase this one.

Changes

  • Allow user to pin/unpin the sidebar, and store preference in localStorage.
  • Add "Expand/Collapse" button to sidebar.
  • Add appSwitcherState service.
  • Add support for "classes" attribute to app-switcher-link.
  • Remove animation from sidebar, and no longer expand on hover.
  • Add default tooltips for sidebar items.

Expanded and collapsed states

sidebar_pin

Note: If there is a tooltip specified for an app, then the app's title will be prepended to the tooltip text, e.g. "Visualize - Make your data beautiful."

Tooltips on disabled links

image

@kimjoar
Copy link
Contributor

kimjoar commented Jul 12, 2016

Can you include a screenshot or gif in PRs such as this? Makes it a lot easier for us that don't have Kibana running all the time to see how it looks like (and to review the non-code parts of the PR)

(I recommend Gif Brewery if you want to make gifs, it's awesome)

@cjcenizal
Copy link
Contributor Author

@kjbekkelund Great call on Gif Brewery.

@alt74
Copy link

alt74 commented Jul 12, 2016

very nice and simple. I dig it. thanks @cjcenizal 👍

@panda01 panda01 self-assigned this Jul 13, 2016
@Bargs
Copy link
Contributor

Bargs commented Jul 14, 2016

You added the tooltips ❤️ ❤️ ❤️ ❤️

@epixa epixa assigned cjcenizal and unassigned panda01 Jul 22, 2016
@cjcenizal cjcenizal force-pushed the 7467/pin-sidebar-functionality branch 4 times, most recently from 1fc33d3 to a45bf55 Compare July 27, 2016 18:32
appSwitcherLinkClasses: 'new classes',
};
const element = create(attrs);
expect(element.attr('class')).to.contain(attrs.appSwitcherLinkClasses);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never been a big fan of tests that use the same data as input and as what they check. What if create(attrs) didn't work so class is wrong, but because you have a typo in attrs.appSwitcherLinkClassses (aka it's undefined) it doesn't fail? I much prefer actually typing it out.

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 think that's a very reasonable point. The reason I like this pattern is that it makes intention crystal-clear; there's no doubt what I want to happen in this test because the variable carries meaning. If I'm comparing against a literal value, then I need to read the entire test (or rely on a comment) to extract that meaning. Whenever I read a test and find it confusing, it's usually because I don't understand the intention behind the test.

I don't think I can objectively say this way is better than your suggestion, though, since there are pros and cons to both.

@kimjoar
Copy link
Contributor

kimjoar commented Aug 1, 2016

LGTM

@kimjoar kimjoar removed their assignment Aug 1, 2016
@Bargs
Copy link
Contributor

Bargs commented Aug 3, 2016

@cjcenizal I think calling the new service appSwitcherState is a little confusing since it affects more than just the app-switcher directive. Until I realized this controls the entire sidebar it seemed really odd that kbn_chrome.js had such intimate knowledge of the appSwitcherState. It seems like chromeState or kbnChromeState would be a more apt name, no?


<!-- Open/close sidebar -->
<app-switcher-link
app-switcher-link-classes="appSwitcherButton.classes"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it's necessary to add this custom attribute to the app-switcher-link directive. You can change this line to class="{{appSwitcherButton.classes}}"

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Haha, old instinct from writing React components. 😄

@Bargs
Copy link
Contributor

Bargs commented Aug 3, 2016

@cjcenizal I'm all done reviewing for now. Let me know what you think about the comments above. I've run out of time today, so I'll get to the other x-plugins PR tomorrow.

@cjcenizal
Copy link
Contributor Author

cjcenizal commented Aug 4, 2016

@Bargs Thanks for the excellent feedback. I've addressed most of it. In terms of naming, I think all of the names we're using right now are confusing, so maybe we can clean things up a bit in this PR.

Currently, kbn_chrome.js uses chrome.html as a template. Let's rename that to kbn_chrome.html.

The sidebar is defined by <nav class="app-links-wrapper"> -- the idea of "app links" makes very little sense to me. Let's call this component a "Global Nav", which I think reflects its role better and complements the concept of a Local Nav (@alt74 feel free to chime in).

Let's also encapsulate this markup inside its own directive: <global-nav>. We'll need to rename classes and child directives to reflect this new name. appSwitcherState will become globalNavState.

Thoughts?

@Bargs
Copy link
Contributor

Bargs commented Aug 4, 2016

+:100: to everything you said about naming. The hardest part about reviewing this PR was wrapping my head around the existing naming schemes.

@Bargs
Copy link
Contributor

Bargs commented Aug 10, 2016

These links added by x-pack at the bottom aren't showing up in this PR branch (screenshot is from master):

screen shot 2016-08-10 at 7 37 33 pm

@Bargs
Copy link
Contributor

Bargs commented Aug 10, 2016

Aside from the issue above, everything looked good. I'll look at it one more time after that's fixed, but you might want to get another set of fresh eyes since a lot has changed since the previous reviewer looked at it. I always get a bit paranoid with big renames.

@cjcenizal
Copy link
Contributor Author

@Bargs Thanks! I'll get another pair of eyes. The X-Plugins don't show up because of all the changes in this PR. Once I get a LGTM I will update the X-Plugins PR to be compatible with this one.

@Bargs
Copy link
Contributor

Bargs commented Aug 11, 2016

Ahhhh, right, I totally forgot about that. My brain is burnt out for today I think

@@ -72,6 +72,15 @@ uiModules
// links don't cause full-navigation events in certain scenarios
// so we force them when needed
this.ensureNavigation = appSwitcherEnsureNavigation;

$scope.getTooltip = link => {
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 prefer that you stuck with the controller concept here and used this.getTooltip() and switcher.getTooltip() in the view.

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'm not opposed but could you explain the rationale for controller over scope methods?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$scope is a perfectly fine way of exposing values to the view, but it has drawbacks when you start involving child scopes (shadowing, unreflected writes, etc.)

Since around angular 1.5 and the new component type, controllers have just been promoted to be the preferred way to expose values to the view as they provide a namespace preventing the inherited values problem, they can be required by child directives/components, and I think they generally describe their purpose better (the controller controls the view, not the $scope).

@spalger
Copy link
Contributor

spalger commented Aug 11, 2016

One note, nothing serious, looks great (to me)!

@Bargs Bargs removed their assignment Aug 11, 2016
@spalger
Copy link
Contributor

spalger commented Aug 15, 2016

LGTM

…rage.

- Add "Expand/Collapse" button to sidebar.
- Add appSwitcherState service.
- Add support for "classes" attribute to app-switcher-link.
- Remove animation from sidebar, and no longer expand on hover.
- Add default tooltips for sidebar items.
…te event. This prevents accidentally triggering handlers that shouldn't be affected by the appSwitcher position.
- Rename app_switcher -> global_nav, and rename associated services and subcomponents accordingly.
- Rename chrome.html -> kbn_chrome.html and create kbn_chrome.less.
@cjcenizal cjcenizal force-pushed the 7467/pin-sidebar-functionality branch from 05b5e1a to eb72cb6 Compare August 15, 2016 19:22
@cjcenizal cjcenizal merged commit 962f036 into elastic:master Aug 18, 2016
@cjcenizal cjcenizal deleted the 7467/pin-sidebar-functionality branch August 18, 2016 19:52
airow pushed a commit to airow/kibana that referenced this pull request Feb 16, 2017
…ionality

[7467] Add "Collapse/Expand" button to sidebar.

Former-commit-id: 962f036
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.

7 participants