I'm finding that router.isActive is returning false any time a secondary route is open.
Is router.isActive suitable for checking 'am I on route (x)?' (e.g.: payments page) - regardless of hashstates, query params and secondary routes.
Should router.isActive be the right service/call to deduce this? Or is it intended for something simpler. Is there an alternative? Should write my own service?
E.g.:
/second, router.isActive('second', true) === true
second(modal:my-modal), router.isActive('second', true) === false
/second, router.isActive('', false) === true. (non-exact matches return true parent/child statesI've created a plnkr proof of concept, for easier testing:
Taking a look at the source here:
https://github.com/angular/angular/blob/master/packages/router/src/router.ts#L493
So you specify a urlTree or a string, and whether an exact match is necessary.
Lets take a look at what it does after that.
return containsTree(this.currentUrlTree, urlTree, exact);
So lets look at containsTree.
https://github.com/angular/angular/blob/master/packages/router/src/url_tree.ts#L16
Looks like it does an exact comparison vs. a contains against the tree depending on the value of exact.
A bit more investigation leads us here:
export function shallowEqual(a: {[x: string]: any}, b: {[x: string]: any}): boolean {
const k1 = Object.keys(a);
const k2 = Object.keys(b);
if (k1.length != k2.length) {
return false;
}
let key: string;
for (let i = 0; i < k1.length; i++) {
key = k1[i];
if (a[key] !== b[key]) {
return false;
}
}
return true;
}
So it looks like the urlTree comparisons are done using a 'generic' shallow comparison algorithm to determine exactness. That makes me think that the current isActive() method is not robust enough (or was intentionally designed that way) to make determinations at the level of granularity you need.
I'm not certain if there is a better way (other than maybe parsing it yourself), or if this is intentional for the isActive() method. I would guess that the isActive() method (when using exactness) was probably written this way because the term exact implies that even having the secondary route does not yield an exact match.
It's probably worth a discussion with the Angular guys to see if there is a way you can get a hook to that information.