bottom-nav component

Question

bottom-nav component

jelbourn opened this issue 9 years ago · 55 comments

jelbourn commented 9 years ago

See https://material.io/design/components/bottom-navigation.html

baldo12 commented 6 years ago

News?

👍2

Answer 1 · 2016-05-09T18:34:17.000Z

Thanks for opening this up @jelbourn. I plan on implementing and have already begun some of the coding. I'm also working on writing up a design doc as you pointed out. There's several more things I need to think about that will hopefully come out in the design document but here's my initial thoughts.

I've been looking at an android/java implementation to learn from that: https://github.com/roughike/BottomBar

So far I've thought about providing a declarative approach such as

<md-bottomnav>
    <md-bottomnav-item>
    </md-bottomnav-item>
</md-bottomnav>

and a programatic approach that consumes an array

<md-bottomnav [items]="items">

The spec mentions that the component can be used for bottom navigation but it doesn't mention anything about its behavior automatically positioning itself to the bottom. I'm not sure if it's more in the spirit that using this component should automatically fix it to the bottom of its containing element, if it shouldn't be concerned with overall layout whatsoever (leaving that up to the consumer of the component), or if it should be a container component that takes up the full height of the view and has a projection area.

Answer 2 · 2016-05-09T18:36:58.000Z

@mikehaas763

For the API, the first approach is preferable. When you want to include items programmatically, you would use ngFor on the item.

The bottom-nav should behave like the toolbar in WRT to the user being able to decide where to place it.

Answer 3 · 2016-05-09T18:37:56.000Z

Agree with @jelbourn. Also, can we make it md-bottom-nav rather than md-bottomnav? Will be easier to read.

Answer 4 · 2016-05-09T18:41:46.000Z

@jelbourn makes sense, was thinking the same thing about ngFor but wasn't sure what would be more preferable.

@kara I agree. My thinking was that I wasn't sure if it should be consistent with sidenav. However, I think of sidenav as one word but with bottom not so much.

Answer 5 · 2016-05-10T01:57:11.000Z

WIP design document (not very far yet): https://docs.google.com/document/d/1h3fQaEaWYKv9GISAYitKSjbPvgNBB4_veIo2hOAquOE/edit?usp=sharing

Answer 6 · 2016-05-12T02:38:46.000Z

Thinking about the API a bit more while working on the design doc, the main piece of the component from a UI perspective is the set of icons. So I have to think about how to use MD icons and could use some feedback.

A few ideas:

Mimic some of the functionality that's in MdIcon in the MdBottomNavItem component (perhaps extracting pieces into services). This would mean create the same @Input()s, inject MdIconRegistry, etc.
Compose MdIcon within MdBottomNavItem and delegate to it
Subtype MdIcon with MdBottomNavItem. I haven't test this yet with A2 components and am not sure how well it works or if there are any edge cases related to decorators or other constructs.

Although I'm generally in the composition over inheritance camp as most people are, I think this may be a good use case for it. The nav items are essentially just icons. The only differences I know of being added on in the subtype right now are:

optionally displaying a text label underneath
communicating with the host element to have the ink effect that's specified in the spec starting at the location of the clicked icon

Thoughts?

Answer 7 · 2016-05-12T02:42:51.000Z

@mikehaas763 The content of the bottom-nav items should be completely up to the user. People will most likely put an <md-icon> in there, but the component itself should have no dependency on it.

It should be something like

<md-bottom-nav>
  <a md-nav-item ...> <md-icon>home</md-icon> </a>
  ...
</md-bottom-nav>

Answer 8 · 2016-05-12T03:02:20.000Z

@jelbourn I took this statement from the spec too literally: "Because bottom navigation actions are presented as icons, they should be used for content that can be suitably communicated with icons".

Meaning I thought it was a restriction material2 would want to match. That makes it a lot easier though so I'll just make that a projection area.

Answer 9 · 2016-05-12T20:55:19.000Z

@jelbourn Do you agree that the component should provide default styling so that if something like the following is used then it will look as it would in the spec?

<a md-nav-item>
  <md-icon>home</md-icon>
  <span>Home</span>
</a>

Answer 10 · 2016-05-12T21:03:55.000Z

@mikehaas763 yes, but it should be via an explicit attribute rather than looking for something like span. See md-card for examples of what I mean.

Answer 11 · 2016-05-18T01:45:35.000Z

update: I'm doing some prototyping to help flush out some design considerations I'm not sure of yet at mikehaas763/material2 in my bottomnav branch. master...mikehaas763:bottomnav

Answer 12 · 2016-05-28T22:44:34.000Z

Forgive my ignorance, but I use a tabs for this exact same functionality... I use CSS to flip the views and you could do the same to hide the indicator. Looking at the design spec's it seems you could use the same code for both components instead of creating something totally different and having to maintain two implementations .

Here is an example of a simply flipped tabs component: http://plnkr.co/edit/hyacHu?p=preview

Tabs & Bottom Nav: Text or icons, full width, truncation, ripples,
Tabs: Indicator, scrollable
Bottom Nav: On the bottom
If you don't want the wrapped views you don't have to use the md-tabs-content directive

I'm just thinking adding a few attributes or css classes would be better than a whole new component..

Answer 13 · 2016-05-31T18:36:15.000Z

I see the bottom nav as being different from tabs in a few ways:

It same a slightly different visual presentation
It is only for navigation (essentially a <nav> containing <a> elements)
It is not paginated (which tabs will be eventually)

Answer 14 · 2016-05-31T18:56:17.000Z

Right, but with so much being the same I was curious why have two codebases.
Tabs can be paginated, they don't have to be, especially because bottom navs are recommended to be no more than 4.

The biggest thing I get is semantically you wouldn't have it be "Tabs" as even though the code is identical the use case is different which I get..

Answer 15 · 2016-09-24T03:55:00.000Z

Hi! Looking in the design doc, you forgot to include that in tablets and desktops this should be displayed aside, to the left.

btw. I agree this may share some code with tabs, but it would easier to understand if you separate concerns.

Answer 16 · 2016-09-28T01:38:05.000Z

@michaeljota just for clarity purposes, my understanding of the spec is different.

Larger displays, like desktop, may achieve a similar effect by using side navigation.

This says to me that a consuming application can optionally choose to use a side nav on bigger displays, but not that the component itself should concern itself with resizing and snapping itself to a side nav.

If it were a valid use case in the future to have a component that did have knowledge to dynamically use a side nav or bottom nav based on screen size, then I'd think that should be a new component that wraps each respectively. Eg. AutoNavigationMenu etc :)

In any case, I'm starting small anyway and can add more features as time goes on.

Answer 17 · 2016-09-28T01:47:32.000Z

Yeah, I see your point. I'm spanish speaker, in spanish may and can are the same, and we almost take them as should, so that's on me.

But you are right, that may it's saying it is optional. This component should not care about being in a large screen or whatever. :)

Answer 18 · 2016-10-22T18:38:28.000Z

Does the library already have any utility styling for reseting hyperlinks to essentially no styling? I have to do something similar with this component's default styling.

Answer 19 · 2017-06-13T15:48:05.000Z

Hey all.
Have created a bottom-nav for a project I'm working on. The current implementation I have is as follows and programatic.
Ideally looking to contribute to the design doc and implenetation since I'm already using material2 for the project. Let me know what you think.

<bottom-nav [tabs]="navBarTabs"></bottom-nav>

With an interface for the tabs:

export interface NavTab {
  title: string;
  icon: string;
  link: string;
}

@Component({
  selector: 'bottom-nav',
  templateUrl: './bottom-nav.ng.html',
  styleUrls: ['./bottom-nav.scss']
})
export class BottomNavComponent {
  @Input() tabs: NavTab[];
}

Picture for reference:

Answer 20 · 2017-06-13T15:56:21.000Z

@pyle revisiting this, my current thinking is that the bottom-nav should have the same API as the tab-nav-bar:

<nav md-bottom-nav>
  <a md-bottom-nav-item routerLink="troubleshoot"> ... </a>
  <a md-bottom-nav-item routerLink="status"> ... </a>
  <a md-bottom-nav-item routerLink="faq"> ... </a>
</nav>

Answer 21 · 2017-06-13T22:51:20.000Z

@jelbourn I like that implmentation a lot better, easier to read from the HTML side. I'll start on the design doc sometime next week and open it up for comments

Answer 22 · 2017-09-01T16:25:58.000Z

Hello all, I have been working on in a component, but this one is using bootstrap 4, if any of you want to do an angular material version, just send a pull request it follows the api that you have been speaking here.

https://github.com/robertofd1995/BottomBar_Component

Thanks also to @pyle , he help me showing me his version

Answer 23 · 2017-09-04T06:04:03.000Z

Just so I keep everyone updated (and don't lose the doc). I started the design doc and have been working on it more as of late. Time is the factor regarding the progress :)

Answer 24 · 2017-12-13T12:30:16.000Z

Any update on this one? I would be happy to contribute. I have implemented my own custom mat-bottom-nav that I use in my application. Let me know what steps would I need to go trough for you to be able to feature it in.

Answer 25 · 2017-12-13T21:59:27.000Z

Hey @MaciejCaputa I've been flat chat and haven't even worked on this. The first step is finishing the design doc so that it's all polished and ready. (I can provide edit access if you'd like to contribute)
Once that's been reviewed and tweaked the implementation can be done.

Out of curiosity, is your implementation similar to Jeremy's comment above?

Answer 26 · 2017-12-13T22:47:23.000Z

Thanks for answering @pyle.

There are couple of ways to provide the API and I think that there should be some flexibility in how developer can provide data for menu.

One option is to provide @Input() items (I use it in in one of my projects since for different user roles we have different menus) onmat-bottomnav where items is an array of objects with icon, label, and absolute route as properties. Then the menu is rendered internally. Moreover additional @Input properties on mat-bottomnav such as background color, icon color. According to material guidelines user may or may not wish to display labels for non-active items.

<mat-bottomnav tabs="tabs"></mat-bottomnav>

Other more declarative approach would be to define menu using mat-bottomnav and mat-bottomnav-item with latter having icon, label, route as input properties.

<mat-bottomnav text="hide">
  <mat-bottomnav-item route="/home" icon="label" label="Home">
  </mat-bottomnav-item>
</mat-bottomnav

Even more declarative approach would be to do something like this:

<mat-bottomnav color="primary">
  <mat-bottomnav-item route="/home">
    <mat-icon>home</mat-icon>
    Home
  </mat-bottomnav-item>
</mat-bottomnav

As you can see there are things that need to be decided on. I can document it in the docs once you give me the edit access. Then we can decide on an approach and formalise the API.

There will be also more questions to answer such as do we allow mat-bottomnav to have other number of items than between 3 and 5. Should it be responsive and be displayed on the side on larger screens as per material guidelines.

Answer 27 · 2017-12-14T15:06:20.000Z

If you read the comments above, the latest example seems to be closes to what is preferred by the Material team, because it would be up to the user what, and how, to put inside the buttons.

I think this should be close to the current implementation of other navigation components.

Answer 28 · 2018-01-19T00:50:17.000Z

Curious has to how this is going, I am not sure if I should just design my own, use a proof of concept posted here or wait and use an alternative

Answer 29 · 2018-01-21T06:12:11.000Z

Apologies to people who are waiting for this.
I haven't finished the design doc and final spec, but started writing the code this weekend to test out some of the implementation ideas. I hope to have it in master before Q1 ends 😄

Answer 30 · 2018-03-05T15:23:52.000Z

When it will be done, will it also apply to Material1?

Answer 31 · 2018-03-05T17:04:36.000Z

@mak3 I've written alpha code in my fork that works, but still need to test etc; And it won't apply to Material1, only Material2 since it's for Angular not AngularJS

Answer 32 · 2018-03-17T11:03:26.000Z

@pyle can you tell us when this will be done? That kind of navigation is a must have for many people and everyone is currently building a custom solution.

@pyle can you please give us an update on this. I've looked into your existing code, which looks already promising. Since you already got so far I don't want to do another custom solution for this. It would be really nice if the material team could provide a solution for this 👍

Answer 33 · 2018-09-11T13:24:56.000Z

@pyle how is it going, any progress? We all badly need mobile navigation and bottom navigation is a must have.

Answer 34 · 2018-10-20T12:22:37.000Z

@pyle It's been almost 2 YEARS since this issue started, and we still don't have a bottom navbar. Why is it taking so long?

Answer 35 · 2018-10-23T05:57:15.000Z

Hey all, sorry for the silence but I've been pretty busy as of late (and the times before).
While it has been a while since an update and since i've actually worked on this please note that I don't work on material full time (nor am i developer fulltime) and can't give as many cycles as I'd like without coding 24/7/365 :)

That being said, im going to dig up my previous code and see where I got up to. From memory I had it working no issues but needed to add some tests and polish up some of the styles.

Answer 36 · 2018-10-25T10:56:53.000Z

https://twitter.com/stephenfluin/status/1054499414461472768
Why is @StephenFluin requesting this, while md-bottom-nav one still on the list ?

Answer 37 · 2018-10-25T14:58:45.000Z

@GoNode5 Hey there! We use multiple sources of information to try to prioritize between technical debt, refactoring, new features, new components, bugfixing, API changes, and more. Not everyone reads our GitHub issues, so combining conversations with developers, information from social media channels, and our GitHub issues & PRs gives us a more holistic picture of developer needs and wants.

Answer 38 · 2018-10-26T15:10:13.000Z

App bars: bottom
Are there plans to give native support to this component?
Material Guidelines

Answer 39 · 2018-11-09T22:13:11.000Z

@max-SS that's offtopic for this thread on bottom navigation.

There is an issue for App bars: top. But I don't see one for App bars: bottom yet. Would you like to open a feature request?

Answer 40 · 2018-12-20T17:55:35.000Z

Ok thank you very much for the correction.

Answer 41 · 2019-01-26T02:30:23.000Z

Apologies to people who are waiting for this.
I haven't finished the design doc and final spec, but started writing the code this weekend to test out some of the implementation ideas. I hope to have it in master before Q1 ends 😄

Any updates...

Answer 42 · 2019-02-10T21:28:47.000Z

any news please guys?

Answer 43 · 2019-03-12T12:47:18.000Z

Are there any updates on this component? You guys should really prioritize this, a lot of people are waiting for this since 2016(?!)...

Answer 44 · 2019-03-26T03:41:12.000Z

This has been open for 3 years?

Answer 45 · 2019-04-10T20:43:23.000Z

Please feel free to click the 👍 in the OP to express your interest in this feature. It is currently a P5, the lowest priority and it is listed in the repo's README that it is "not planned".

If you need this functionality soon, please look at creating your own implementation and possibly contributing it to an open source project like https://github.com/tiaguinho/material-community-components.

Answer 46 · 2019-05-09T14:06:58.000Z

+1 waiting for this component

Answer 47 · 2019-06-23T13:56:19.000Z

So, i've got a bottombar written in Angular, using Angular Material Theming.

Here's a Stackblits: https://stackblitz.com/edit/mat-bottom-bar
Demo: https://mat-bottom-bar.stackblitz.io/

@Splaktar reckon this could be a candidate for the community components?

Answer 48 · 2019-06-24T02:08:12.000Z

@breningham as mentioned in #408 (comment), bottom navigation (this issue) is different from App bars: bottom. However, I think that would be a good contribution to https://github.com/tiaguinho/material-community-components. Also I think that the shadow should be on top, rather than bottom, for a bottom app bar.

Answer 49 · 2019-06-24T02:19:03.000Z

Related: MDC's issue for tracking the bottom navigation feature.

I've opened #16367 to track the creation of a mat-bottom-app-bar.

Answer 50 · 2020-02-09T15:35:04.000Z

New year, new component? Any updates here?

Answer 51 · 2020-02-10T23:49:35.000Z

@jlandsmann no updates here. This P5 issue is very low priority at this time.
It's likely that MDC would need to implement material-components/material-components-web#59 (which hasn't had any movement on it) before one would be added to Angular Material.

Answer 52 · 2021-03-05T17:00:09.000Z

Any updates?

Answer 53 · 2021-05-05T06:01:30.000Z

This seems like an option: https://github.com/kevlatus/ngx-bottom-nav#readme

Answer 54 · 2023-01-29T13:03:24.000Z

hi are there any plans to add this component?, i've try to read the whole conversation but it's not clear to me, what is the official angular-material team position about this feature request:

will be implemented? (if so there are plans)
will not be implemented but there is an official suggested workoround (ex: use tabs)
other...
Please someone of the angular material team could clarify?
Thank you for your works!