Skip to content
This repository was archived by the owner on Apr 12, 2024. It is now read-only.

ngView cleanup order #7606

Closed
geddski opened this issue May 28, 2014 · 12 comments · Fixed by #9374
Closed

ngView cleanup order #7606

geddski opened this issue May 28, 2014 · 12 comments · Fixed by #9374

Comments

@geddski
Copy link
Contributor

geddski commented May 28, 2014

@matsko I think the ngView cleanup order is incorrect. Current it's:

function cleanupLastView() {
  if(previousElement) {
    previousElement.remove();
    previousElement = null;
  }
  if(currentScope) {
    currentScope.$destroy();
    currentScope = null;
  }
  if(currentElement) {
    $animate.leave(currentElement, function() {
      previousElement = null;
    });
    previousElement = currentElement;
    currentElement = null;
  }
}

So a user lands on a page, the first view is shown, and currentElement is set. Next the user clicks on a link to go to the second view. cleanupLastView() gets called and should cleanup the first view. But previousElement is undefined still (it gets set below which is too late) and so the cleanup does not happen.

Only after navigating to a third view is previousElement defined and the cleanup starts to work.

Also it seems to me like the scope should be destroyed before the element is removed, but maybe that doesn't matter.

Correct me if I'm wrong but I think the order should be:

function cleanupLastView() {
  if(currentElement) {
    $animate.leave(currentElement, function() {
      previousElement = null;
    });
    previousElement = currentElement;
    currentElement = null;
  }
  if(currentScope) {
    currentScope.$destroy();
    currentScope = null;
  }
  if(previousElement) {
    previousElement.remove();
    previousElement = null;
  }
}
@Narretz Narretz added this to the 1.3.0 milestone Jul 1, 2014
@btford btford removed the gh: issue label Aug 20, 2014
@jeffbcross jeffbcross modified the milestones: 1.3.0-rc.5, 1.3.0 Sep 29, 2014
@IgorMinar
Copy link
Contributor

guys, this looks like a no-brainer issue. why is it still open?

cc: @matsko, @tbosch, @jeffbcross

@IgorMinar
Copy link
Contributor

I think that @geddski is wrong. the current code is not incorrect because the current view is removed via $animate.leave and previousElement.remove() serves only as a fallback in case the animation is taking too long and another animation already started removing the next view.

@matsko do we need this fallback at all? wouldn't it make it impossible to have more than one leave animation in progress? why would that be a bad thing?

@jeffbcross
Copy link
Contributor

"no-brainer" he says

@geddski
Copy link
Contributor Author

geddski commented Sep 30, 2014

Is that the case for apps that aren't using ngAnimate?

@IgorMinar
Copy link
Contributor

@jeffbcross I mean that it's an issue that can be resolved quickly, not necessarily that @geddski's proposal is right.

@IgorMinar
Copy link
Contributor

@geddski the $animate.leave will work even when ngAnimate is not present.

I'm pretty sure that the previousElement.remove() is unnecessary and should be removed. Unless @matsko screams we should make it so.

IgorMinar added a commit to IgorMinar/angular.js that referenced this issue Sep 30, 2014
it's unnecessary and inconsistent (because finishing animations reset  we see situations
where not previousElement is not always removed and more than one leave animation is going on at the same time).

Closes angular#7606
IgorMinar added a commit to IgorMinar/angular.js that referenced this issue Sep 30, 2014
it's unnecessary and inconsistent (because finishing animations reset  we see situations
where not previousElement is not always removed and more than one leave animation is going on at the same time).

Closes angular#7606
Closes angular#9355
@IgorMinar
Copy link
Contributor

I opened a PR. @matsko please review

@IgorMinar
Copy link
Contributor

here is a plunker with the demo of the current state: http://plnkr.co/edit/O3OYwOzihJgokI7gLLQ4?p=preview

@IgorMinar IgorMinar self-assigned this Sep 30, 2014
@jeffbcross
Copy link
Contributor

@IgorMinar our triage and planning process is flawed. We don't do a good job of reviewing issues by frequency/severity.

@geddski
Copy link
Contributor Author

geddski commented Sep 30, 2014

you may want to double check, I'm pretty certain it doesn't cleanup until you've visited the third view. If I'm right @IgorMinar owe's me lunch.

@IgorMinar
Copy link
Contributor

@geddski you are wrong

@IgorMinar
Copy link
Contributor

@matsko convinced me that my PR is wrong too, so I'm going to change it: #9355 (comment)

IgorMinar added a commit to IgorMinar/angular.js that referenced this issue Oct 1, 2014
…ion occurs at a time

the tracking depended on a local flag variable, which was susceptible to corruption due to
race conditions.

Closes angular#9355
Closes angular#7606
IgorMinar added a commit to IgorMinar/angular.js that referenced this issue Oct 1, 2014
…ion occurs at a time

the tracking depended on a local flag variable, which was susceptible to corruption due to
race conditions.

Closes angular#9355
Closes angular#7606
Closes angular#9374
IgorMinar added a commit to IgorMinar/angular.js that referenced this issue Oct 1, 2014
…ion occurs at a time

the tracking depended on a local flag variable, which was susceptible to corruption due to
race conditions.

using promises ensures that the previousLeaveAnimation is nulled out only if it hasn't been
canceled yet.

Closes angular#9355
Closes angular#7606
Closes angular#9374
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.