Scopes Not Destroyed with menuClose directive

[jgw96]

From @calendee on August 19, 2016 21:5

Short description of the problem:

When using the sidemenu links to navigate from the current view, the current view's controller/view is not destroyed nor is its scope disconnected. It remains active and all watches are still active.

What behavior are you expecting?

When using the sidemenu links to navigate, the current view and controller should be destroyed. Since the menu-close directive causes the app's history root to be reset, that process should disconnect the current view's scope.

When using $ionicHistory.nextViewOptions with historyRoot or disableBack, the current view/scope should be clobbered on the next state change.

Steps to reproduce:

1. Visit http://plnkr.co/edit/veYrgw7Y4m8jY4ScIFcO and open the console.
2. Notice the console logs out "HomeCtrl Interval Triggered!" every 3 seconds
3. Open the sidemenu
4. Tap "Check-in"
5. Notice the console continues to log that "HomeCtrl Interval Triggered!" every 3 seconds
6. Notice the $destroy event is never fired for the HomeCtrl - no console logging occurs.

Which Ionic Version? 1.3

Plunker that shows an example of your issue

http://plnkr.co/edit/veYrgw7Y4m8jY4ScIFcO

Run ionic info from terminal/cmd prompt: (paste output below)
Your system information:

Cordova CLI: 6.2.0
Gulp version:  CLI version 3.9.1
Gulp local:   Local version 3.9.1
Ionic Framework Version: 1.3.1
Ionic CLI Version: 2.0.0-beta.30
Ionic App Lib Version: 2.0.0-beta.16
ios-deploy version: 1.8.6
ios-sim version: 4.1.1
OS: Mac OS X El Capitan
Node Version: v4.4.7
Xcode version: Xcode 7.3.1 Build version 7D1014

Copied from original issue: ionic-team/ionic-framework#7788

[jgw96]

From @tomasztunik on September 7, 2016 5:20

I've tested one theory and added $ionicConfigProvider.views.maxCache(0); to confirm if it is not because of the cache and indeed scope gets destroyed when you disable cache but the interval keeps on going regardless.

You need to manage your intervals on your own and stop them in either $destroy or in $leave events (you can restart them in the $enter event)

[jgw96]

From @calendee on September 7, 2016 14:33

The problem is that the $destroy never happens. The interval was just for an example. The real problem is that the destory never happens; so, all scope watches still exist and can never be gotten rid of.

[jgw96]

From @tomasztunik on September 7, 2016 14:44

http://plnkr.co/edit/m7rIwxHaVlVKMXkSQmV8?p=info check updated plunker, if you disable cache it does log the $destroy event in the console.

When you use caching you should listen to $ionicView.leave event to clean up the view and then $ionicView.enter to set up whatever you want to do, global listeners, intervals etc.

(check http://ionicframework.com/docs/api/directive/ionView/)

[jgw96]

From @calendee on September 7, 2016 15:45

The goal is not to disable caching. By disabling it for this one scenario, you lose all the benefits of caching throughout the entire app.

The goal is to destroy a controller that should no longer be in the history stack.

[jgw96]

From @tomasztunik on September 7, 2016 18:35

caching stack in ionic (nor in browsers for example) is not linked to history stack so it won't work the way you think it should. Thanks to that it's possible to take advantage of cache when switching root contexts of the app etc.

If you have a single view where cache is causing more trouble for you than help and handling your use cases with enter/leave events is too much hustle you can disable caching for selected views in the stateProvider configuration using cache: false - then you'll have your destroy event triggered every time.

Ionic cache is using FIFO queue so as long as the cache queue won't overflow and start pushing out older views your controller will stay in memory and all not cleaned up listeners and what not will stay active.

[jgw96]

From @tamakisquare on December 23, 2016 22:17

@calendee - I think the scope of the issue can be narrowed down as outlined below.

As mention in issue #8911, I have got this same issue (scope not being destroyed and thus no $destroy event is fired) only when I use $ionicHistory.nextViewOptions with the disableAnimate option set to true. Even with disableBack and historyRoot set to true, as long as disableAnimate is not set (or set to false) everything would work as expected.

I am on Ionic v1.2.4.

[calendee]

I was able to solve this issue with prior view's scopes not getting destroyed by doing the following after navigation to the new view is completed.

  $timeout(function() {
    $ionicHistory.clearCache();
  }, 300);

This destroys the scopes on the prior views and releases all watches.

@tamakisquare this may help you as well.

[tamakisquare]

@calendee - Thanks for the tip. Unfortunately, for my case, a mass clear cache call cannot be used. Is there a way that I can perform clearCache() but on a selected view only?

[calendee]

Unfortunately, the clearCache is global and has no means to be selective.