Notify:false fires the controller twice when changing state

[PhiLhoSoft]

The Bug

When a $state.go is called with {notify: false} as follows, a bug occurred:

$state.go('foo', {}, {notify: false})

On the next state change, the current controller will be initialised a second time.

Plunker Link

Follow the steps to reproduce on Plunker:

http://plnkr.co/edit/wMiVOb?p=preview
and
http://plnkr.co/edit/iqDuQrsjVWfySOrg1nv0?p=preview

---

Navigate to foo state, then click on Change URL button. The URL changes without reloading the controller, which is the wanted behavior.

Click on the Change state 1 button.
The URL changes, I see a $stateChangeStart event with the current URL parameters, the controller is called.
Then I see a $stateChangeSuccess event with the new URL parameters and the controller is called again.

If you click now on the Change state 2 button, both events have the same URL parameters, so there is no double controller call.

It looks like the notify: false parameter don't do a "real" URL parameters update, so UI-router has to do a double state change to reconcile the parameters it knows with the ones it discovers, then with the ones requested...

I saw a number of issues more or less related, like #1758, but I am not sure if they are entirely the same. So I went ahead and made my own issue with a demonstration to illustrate it. 😄

[PhiLhoSoft]

I feel this issue went unnoticed, as more recent ones are triaged as bug or design or similar, or get answers.
Might I have at least a comment on it? Is it a bug? Is there a workaround? Am I doing something wrong?

[christopherthielen]

A few comments:

The docs for notify says:

If true will broadcast $stateChangeStart and $stateChangeSuccess events.

Using notify: false will simply suppress the firing of those events. I realize that when this option was originally introduced, it was intended to implement the use cases ya'll are using it for. However, the ramifications of suppressing those events was never fully thought out, and in fact it turned out to be a Very Bad Idea™ because it leaves the router internally inconsistent. Therefore, please do not use notify: false.

We are deprecating state events ($stateChangeStart/Success/Error) in favor of a new architecture (which includes full Dynamic Params support). As such, notify: false is also deprecated, and usingit will harm your migration path to UI-Router 1.0. Instead, use reloadOnSearch if at all possible, as it is much closer to a "Dynamic Params" implementation. If that is not possible, you may continue to use notify: false, and I think PR #2003 may possibly help here, if it gets merged in.

[JerryBels]

Hello guys,

I feel my need is related to this. I have 3 divs on which I want to activate a class if the state and params are as expected.

<div ng-class="{menuActive: $state.is('details', {tab: 0})}">0</div>
<div ng-class="{menuActive: $state.is('details', {tab: 1})}">1</div>
<div ng-class="{menuActive: $state.is('details', {tab: 2})}">2</div>

On the "details" page, I can also get from tab 0 to 1 or 2 manually, but then the class in the menu is not updating - it's exactly what dynamic params will be made for, no ? Is there a workaround for my production app until release is ready ?

Thanks ! :)

[sibsibsib]

I bumped into this yesterday. While trying to write some tests to replicate, I found that the issue is no longer happening as of 997deb7

[christopherthielen]

Fixed in f9b43d6

[shql]

Hi guys,

we bumped into this problem as well and the direct implementation of the fix in our app does not work. When trying the Plunker with the "supposed to be fixed" version also still shows the problem. Any hints?

Here is the "fixed" Plunker: http://plnkr.co/edit/48UyEowm1zTeoZotlTu6?p=preview

[adamrabie]

@shql +1. having exact same issue.

[Etheryte]

@adamrabie See #1758 for a solution until 1.0 becomes stable. You need to use reloadOnSearch: false on the parent state instead of using notify: false on your go call. This might mean a minor architecture change depending on the rest of the logic you're building.

[richardaum]

+1 this problem was NOT fixed.

[trinhhunganh]

+1

[modikejal10]

Have found this thing to work for me,
$state.go($state.current, {params},{notify:false,reload:$state.current});
Could update URL without state getting loaded again.
So the issue I was facing was I wanted to update the URL without loading the parent state, so I gave reload as the child state I am in, so that way when I change the tab, it doesnt reload the parent tab, and the parameter which I wanted to update was given with the child state in route defintiion.

[seansean11]

+1
I'm working on a legacy project that uses polling with Angular's $interval on the controllers load. This is causing a leak, where $interval's are being called and their references (for cancelling) them are lost when the state is changed. Switching to reloadOnSearch: false and trying to manually set up the history state is giving me issues. If there was a way to prevent this from happening, it would be sooooo awesome.