Ember.js: Ember.Component destroy doesn't tear down properties

Created on 3 Jun 2015  路  9Comments  路  Source: emberjs/ember.js

I have a property that is being maintained after my component has been destroyed.

Currently, I am clearing it out myself in willDestroy but I think that it should be torn down with destroy.

Most helpful comment

@munsellj That's expected. The object you made when defining the basic-form component is shared by all instances of that component. When the input's content changes, the name property on the original object is being changed.

Here's a fork of your twiddle that helps demonstrate it. If you go to the child route, you'll see that the first two instances of the basic-form component will mirror each other. The third instance is given its own model that isn't shared with the others.

You can get around it by using a simple computed property:

Ember.Component.extend({
  model: function () {
    return { name: null };
  }.property()
});

Or by setting the property in an initializer:

Ember.Component.extend({
  model: null,

  setDefaultModel: function () {
    this.set('model', { name: null });
  }.on('init')
});

Hope that helps!

All 9 comments

Cleanup that needs to be done when your component is destroyed is exactly what willDestroy is for.

Can you please share a JSBin showing why that is not the right solution in your case?

Ah, I was under the impression that Ember.Component cleaned it up for you.

It's not necessarily the wrong solution, just something I assumed and it didn't appear to be working.

I don't really know what kind of cleanup you are talking about. A demo/example would be very helpful.

Created a jsbin, but appears to be working outside of my app. http://jsbin.com/qucaho/3/

Basically what I'm experiencing is that address.address1 is maintained when I go back to index route and then back to address route.

I must be doing something wrong some where else, thanks for the help. Going ahead and closing.

@AO16 I'm experiencing a similar issue in one of my apps. Did you ever determine the cause in your case?

@rwjblue I was able to create an Ember Twiddle that demonstrates this issue:
https://ember-twiddle.com/008932c6a02fe3e8c204136e18762eb2?numColumns=2&openFiles=components.basic-form.js%2Ctemplates.parent.child.hbs&route=%2Fparent%2Fchild

Steps to Reproduce:

  • Click Go To Parent Route
  • Click Go To Child Route
  • Type something in the text field
  • Click Go Back To Parent
  • Click Go To Child Route
  • Observe the that text field is still populated with the value previously entered and was not reset

The interesting part is that I can only reproduce the issue if the model property is declared in the Component and initialized with an Object(even an empty object). If you remove or comment out line 4 of components/basic-form.js the issue will not occur and the text field will be empty upon each transition into child route as expected.

I tried with a few various interactions of hierarchy and route transitions and it always seems to occur regardless of the transition pattern. It also doesn't appear to matter if the component property(model in this example) is a plain JS Object or an Ember.Object, happens in both cases.

Can this be re-opened or should I file another bug?

@munsellj That's expected. The object you made when defining the basic-form component is shared by all instances of that component. When the input's content changes, the name property on the original object is being changed.

Here's a fork of your twiddle that helps demonstrate it. If you go to the child route, you'll see that the first two instances of the basic-form component will mirror each other. The third instance is given its own model that isn't shared with the others.

You can get around it by using a simple computed property:

Ember.Component.extend({
  model: function () {
    return { name: null };
  }.property()
});

Or by setting the property in an initializer:

Ember.Component.extend({
  model: null,

  setDefaultModel: function () {
    this.set('model', { name: null });
  }.on('init')
});

Hope that helps!

@WCPetersen makes sense, thanks for the response! Saw email notification in the car and without even reading this realized that was probably the case and made the connection. Feel like I read about this repeatedly in blog posts and still didn't make the connection.

image

Was this page helpful?
0 / 5 - 0 ratings