Search code examples
ember.jsember-dataember-components

Ember {{#each}} shows previously deleted records


I've been fighting a bug in an app I'm working on. I have created a JSBin to illustrate it and these are the steps you should take to reproduce it:

  1. Click on the link that says "New Rule Set"

You'll see the Rule Set Builder template display that box. Notice that I've included the id, isDeleted, isDirty and isSaving properties to easily see the state of that record. I am also displaying the length of the hasMany relationship.

  1. Click on the "Remove" link to destroy that record

As expected, the Rule Set box disappears and the length indicates that there are 0 rule sets. I am both using removeObject from the parent model and destroyRecord on the object I'm trying to delete, although I think Ember data should take care of that for me.

Notice that in the console I'm logging the firstObject, which weirdly enough appears to be there even when the length is 0. I don't know if this is related to what happens in the next step.

  1. Click on the "New Rule Set" link again

You'll see that two boxes are displayed. The first one is the rule set that you had previously deleted. Notice how it isDeleted, not isDirty and not isSaving, which as indicated here means that the change has persisted.

Obviously hitting "Remove" again from the isDeleted record throws an error in the console saying:

Uncaught Error: Attempted to handle event deleteRecord on while in state root.deleted.saved.

What am I missing? Is {{#each}} supposed to show records that isDeleted?

Thank you for your help!


Solution

  • I submitted an issue in the Ember Data repo and it turns out that this has been reported already.

    Take a look at #2666 for follow-up and some ways to get around it for now. The latest one I saw was posted by dwickern and it involves using a computed property instead

    comments: Ember.computed.filterBy('model.comments', 'isDeleted', false)
    

    Apparently ember-data.1.0.0.beta-12 doesn't have the problem and there is already a Pull Request #2722 with a possible solution.