removing bound scope properties on destroy #1415

Closed
moschel opened this Issue Jan 23, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@moschel
Contributor

moschel commented Jan 23, 2015

By the time the destroy event of a component is run, the bound scope properties are no longer bound to their parent component properties. In other words, if you pass a cross bind a scope property from a parent to child component like:

<my-component product="{product}"></my-component>

Then you want to clean up that product reference while the component is destroyed like:

events: {
  destroyed: function(){
    this.scope.attr('product', null);
  }
}

This won't throw an error, but the product property of the parent component won't be affected by this, because the property bindings are unbound before destroyed is called. I think we should change the order so the bindings are cleaned up after destroyed is called.

@daffl daffl added this to the 2.2.0 milestone Feb 3, 2015

@daffl daffl added the bug label Feb 3, 2015

@moschel

This comment has been minimized.

Show comment
Hide comment
@moschel

moschel Feb 9, 2015

Contributor

@daffl can't we close this?

Contributor

moschel commented Feb 9, 2015

@daffl can't we close this?

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Feb 9, 2015

Contributor

No. Referenced issues will be closed automatically once in master.

Contributor

daffl commented Feb 9, 2015

No. Referenced issues will be closed automatically once in master.

@justinbmeyer

This comment has been minimized.

Show comment
Hide comment
@justinbmeyer

justinbmeyer Feb 10, 2015

Contributor

We can close them before that if they are in minor. Too bad github doesn't have some setting like this.

Contributor

justinbmeyer commented Feb 10, 2015

We can close them before that if they are in minor. Too bad github doesn't have some setting like this.

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Feb 10, 2015

Contributor

We could make minor the default branch. I don't think that finding all the still open but referenced issues in merged PRs against minor is necessary though. I'd also rather have people watching an issue be notified if a new release has been made not just if the fix made it in a development branch.

Contributor

daffl commented Feb 10, 2015

We could make minor the default branch. I don't think that finding all the still open but referenced issues in merged PRs against minor is necessary though. I'd also rather have people watching an issue be notified if a new release has been made not just if the fix made it in a development branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment