Computed Property Based on Nested Fragment

[lmcardle]

I have a fragment that looks like this:

level1: {
  level2: [
    {
      level3: [
        {
          propFoo: 'bar'
        }
      ]
    }
  ]
}

Within a template, if I loop over level's 2 and 3 together, I get live updating (i.e. it works as expected):

{{#each level1.level2 as |x|}}
  {{#each x.level3 as |y|}}
    <p>{{y.propFoo}}</p>
  {{/each}}
{{/each}}

If I have an action and remove one of the y's, the list displayed is updated with one less y.

I need to move this to the controller in a computed property. However, I can't seem to get the computed property to re-fire when one of the y's gets removed. This is what I have currently:

sortedLevel3: Ember.computed('[email protected].[]', function() {
  // do something
  // return sorted level 3 list
}

{{#each sortedLevel3 as |y|}}
  <p>{{y.propFoo}}</p>
{{/each}}

While the above works the first time the page is loaded, the sortedLevel3 function never gets called a second time once one of the items in level3's array is removed. Any idea what I am missing?

[lmcardle]

One additional piece of info:
level1 is a regular ember data model
level2 is a fragmentArray
level3 is a fragmentArray

[workmanw]

Hey @lmcardle what version of ember-data are you on? Since we're using Ember.ArrayProxy, I suspect this is related to: emberjs/ember.js#12475 .

If I understand that issue properly, you should be able to use level2.content.@each instead (see below). Maybe give that a shot?

sortedLevel3: Ember.computed('[email protected].[]', function() {
  // do something
  // return sorted level 3 list
}

[slindberg]

I believe @workmanw is correct that this is the same issue as emberjs/ember.js#12475. The fragment array base class does the same thing as RecordArray by overriding the content property.

Closing since this is a bug in Ember. The commenters on that issue reported success with adding the content property to the dependent key chain, so I would start there if you can't upgrade Ember. It is fixed in Ember 2.3.x, but it doesn't look like it will be backported to 2.0-2.2.