components: [Tabs] md-tab-link: routerLinkActive.isActive error

Ok I got [active] set correctly this way:

<nav md-tab-nav-bar>
	<a md-tab-link routerLink="/admin/management" routerLinkActive #rla1="routerLinkActive" [active]="rla1.isActive">Management</a>
	<a md-tab-link routerLink="/admin/profile" routerLinkActive #rla2="routerLinkActive" [active]="rla2.isActive">Profile</a>
</nav>

Thanks to all who helped fix this.

Setting version to Angular 2.4.5 fixed it for me!

Seems like recent deprecation of md- prefix broke the templates. For anyone still struggling with these, try using mat-…

This still seems to be an open issue on Angular 4 with Angular Material 2.0.0-beta5. I could get neither the example on material io nor the fix proposed in this thread to resolve the issue. The browser console says Can't bind to 'active' since it isn't a known property of 'a'.

It’s still an issue. Im using the following routes:

{
    path: 'organisation/:id',
    component: OrganisationComponent,
    children: [
      {path: '', component: OrganisationEditComponent},
      {path: 'locations', component: LocationsComponent},
    ]
  }

Then this as my component html:

<nav md-tab-nav-bar>
  <a md-tab-link
     [routerLink]="['./']"
     routerLinkActive #rla="routerLinkActive"
     [active]="rla.isActive">Algemeen</a>
  <a md-tab-link
     [routerLink]="['./locations']"
     routerLinkActive #rlb="routerLinkActive"
     [active]="rlb.isActive">Locaties</a>
</nav>
<router-outlet></router-outlet>

So now it works on the initial load, but whenever I go back to the ‘./’ route the md-tab-link active doesn’t get updated.

UPDATE:

I’ve fixed it by add this [routerLinkActiveOptions]="{exact: true}" to the first link, can someone explain why this is needed?

@andrewseguin This looks like it’s a bug in Angular, specifically router_link_active.ts. The function:

  private hasActiveLink(): boolean {
    return this.links.some(this.isLinkActive(this.router)) ||
        this.linksWithHrefs.some(this.isLinkActive(this.router));
  }

Should guard against links and linksWithHrefs being null/undefined. This is something we could fix.

Good afternoon!

I just ran into this very same issue today. When debugging my own code stil left me blocked, I turned to the web and found this thread. It changed the way I was looking at the issue and that helped me find a way to work around it in the immediate term.

I haven’t enough time to draft an example at the moment. I will follow up with one later on if this description is unclear, but want to offer what I have now in the meantime.

It looks like the problem here is that the RouterLinkActive.isActive() method is dependent upon a @ViewChildren query-induced injection to occur. AFAIK, that happens during the content initialization stage of compilation. The property annotated with @ViewChildren is “this.links”.

The call to RouterLinkActive.isActive( ) is part of the same content model where RouterLinkActive is getting links injected from RouterLink. which explains why “this.links.changes.some( )” causes “Cannot read property ‘some’ of undefined” to be thrown–it isn’t injected by the time the first call to isActive() expects it to be there, and the implementation of isActive( ) doesn’t have a defensive check allowing it to return false when it’s called so early.

I confirmed that adding that undefined check in isActive( ) solved my issue, but modifying the framework isn’t really a viable workaround. I couldn’t make the framework tolerate an early call to isActive(), so I forced my component to defer its first call.

Before workaround: <a md-tab-link routerLink="/lobby" routerLinkActive #rla="routerLinkActive" [active]="rla.isActive">Lobby</a>

After workaround: <a md-tab-link routerLink="/lobby" routerLinkActive #rla="routerLinkActive" [active]="rlaSafe && rla.isActive">Lobby</a>

And in the Component code

export class MyNavbarComponent implements AfterViewInit {
  private rlaSafe: boolean = false;

  public ngAfterViewInit() {
    this.rlaSafe = true;
  }

The additional boolean stops the flow control from reaching isActive() until after the view initialization lifecycle event has passed, by which time the response to RouterLinkActive’s @ViewChildren query has been injected and the call to isActive( ) therefore no longer gets tripped up on an uninitialized reference.

Its not transparent, so its a work-around and not a solution, but it unblocked the rest of what I have yet to do early this week, so I’m comfortable with it for now.

Angular 2.4.4 fixes the error and tabs change successfully; however [active] is not being set.

Hi everyone, I found this error after a sleepless night of thinking I was doing something wrong while trying to implement the documented MdTabNavBar Directive example shown at the bottom of https://material.angular.io/components/component/tabs#tabs-and-navigation (under “Tabs and Navigation”)…

Obviously, since this is still an open issue, that example (written verbatim) wont work. I think it would be great if someone put a quick note next to that example pointing to this issue so that people dont waste too much time thinking they are not following what they may think is documented correctly. Something like the following would suffice.

Note: In it’s current form, example above has a known bug and will not work, please consult Issue #1967 for more details and for for a work around whilst this issue is being resolved by the Angular team.

In my case the error was fixed by importing MatTabsModule from @angular/material

This should be long ago fixed in Angular.

Should we mention in the docs this rlaSafe workaround? I’ve spent a lot of time figuring out what I was doing wrong… There is differences between git Readme.md, material.angular.io docs and what we really should do.

Just say the words and I can update the README.md to point this issue and th rlaSafe workaround.

If you are affected, please re-open if you can provide a reproduction of the issue, otherwise we won’t be able to investigate.

@jelbourn This is still an open issue for me on the latest version. Please consider reopening this.

@vinagreti It does not look like they want to update any of the docs to address this bug. Instead they are trying to get the bug resolved ASAP. My PR to update the docs was declined.

It looks like the PR in the core is waiting on review still.

@DzmitryShylovich AFAICS your PR doesn’t introduce backwards incompatible changes at the moment, please correct me if I’m wrong.

@andrewseguin considering @DzmitryShylovich’s PR is safe to merge, could you raise the priority of this issue. I believe this is pretty much how tabs component will be used in the most of the apps.

/cc @jelbourn

P.S. Sorry for bothering during the holidays 😉. Happy Christmas! 🎄 🎅

@nayfin yes, but it’s not clear when it will be merged

@DzmitryShylovich will your pull request #13341 address these issues?

Thanks for the fast update. I updated the plunkr. All the relevant code is in app.component.html. I commented the hell out of it explaining what we are looking for. Hopefully it is just a syntactic mistake. Please let me know if I can help in any way. Thanks for all your hard work, this is an amazing set of components and I hope that I can contribute soon.

Please use the issue template which helps us reproduce and diagnose the issue. Including a plunkr with this bug will help us determine what is happening.