Repository navigation
RouterLinkActive initial render state prior to first router navigation #62973
Description
Which @angular/* package(s) are relevant/related to the feature request?
router
Description
Hi team !
I wanted to open this issue to discuss your view regarding the current state of the directive RouterLinkActive and your plans regarding it.
Today, this directive has a very neat api and we strongly recommend its usage in our company.
However, the way it handles the display of the active class creates a visually annoying flicker...
You can see the flicker when you open for example https://material.angular.dev/components/categories and notice how the background around the Components button only appears after a short delay.
(Note: angular.dev does not have this behavior but the active class was managed with completely home-made code ? also, angular.dev is missing aria-current attributes for the active anchors)
For more context, there are two problems.
First one is the fact the class is added / removed through a queued microtrask.
Second is that at startup / hydration, a call to router.isActive will not be correct until the router has performed its first navigation internally...
Proposed solution
It depends greatly on what's the plan regarding Angular Routing in general...
As the team is working on turning many facets of old Angular into signals (Forms is another example), I guess Routing is in the works.
I have opened the draft PR #62974 that removed the flicker for my internal project, but it probably has a bunch of issues...
Alternatives considered
I guess copy-pasting the internal code done for angular.dev would work, but I would prefer to use something provided by @angular/router...
Activity
atscott commentedon Aug 4, 2025
Yes, the internals of
RouterLinkandRouterLinkActivewill be converted to signals eventually. I have a branch with this done already but current priorities prevent me from spending time on finalizing it.I'm not clear on how the proposed change in your PR addresses any flicker though. The state is still dependent on asynchronous router navigation. I don't believe setting the classes in a microtask would be the cause of any flicker either.
I don't think there's anything actionable to take from this issue at the moment. If you're saying simply converting things to signals will address the problem, then perhaps this will be resolved when that's done.
quentinderoubaix commentedon Aug 4, 2025
Sorry, it seems I am not expressing myself clearly...
Indeed, signals are not enough for the flickering thing !
Which is why in my draft PR the
isActivesignal was basically this (not including contentchildren links and router events):Until the Router has navigated at least once, the
isActivefunction cannot be trusted butLocationand its path can be used for the initial check.This felt like a really ugly workaround though...
As a final comment, pre-rendered html from an Angular app built as a SSG would contain the correct active class, but would instantly remove it during hydration, then add it back a short while later... feels like a pity.
Thanks for checking this issue, I am aware this is very minor in the grand scheme of things and the quantity of stuff you have to work on...
atscott commentedon Aug 4, 2025
Okay, yea that makes sense. I think it's probably fair to have the
RouterLInkActiveeagerly assume the current path will become active when the Router hasn't yet navigated anywhere. It does irk me thatnavigatedlikely isn't the right thing to use since it gets set and reset at times that don't make sense here. We'd probably want to use something like!!router.lastSuccessfulNavigationinstead.[-]Future of RouterLinkActive... signal-based and no flickering ?[/-][+]RouterLinkActive initial render state prior to first router navigation[/+]