5.0.0-beta.1 Fragment Array model updates don't work with did-update

[mike-engel]

I've been in the middle of updating our ember app from 3.12 to 3.24 now that this beta is available, and for the most part it's been smooth sailing! I've run into one issue though, which is that updates to a fragment array model don't seem to trigger a change, or at least one recognized by ember-modifiers' did-update modifier.

Here's an example.

// models/webhook.js
export default class Webhook extends Model {
  @fragmentArray('header') headers
  @attr body
}

// models/header.js
export default class Header extends Fragment {
  @attr name
  @attr value
}

Then, if I have a glimmer component with a did-update modifier like this

{{! template.hbs }}
<div {{did-update this.validateHeaders @webhook.headers}}>
  ...
</div>

then this.validateHeaders only runs when the headers property changes length (i.e. header fragments are added or removed, but not modified).

It's possible that this is intended behavior, and that a custom computed property needs to be set up to track this (which is what I did, below) but it feels like this should work.

// controller.js
export default class WebhookComponent extends Component {
  @computed('args.webhook.headers.@each.{name,value}')
  get headers() {
    return this.args.webhook.headers.serialize();
  }
}

{{! template.hbs }}
<div {{did-update this.validateHeaders this.headers}}>
  ...
</div>

Thanks!

[patocallaghan]

@mike-engel I'm unsure of the correct behaviour here but out of curiosity do you know what happens with regular Ember Data hasMany relationships? Do they trigger did-update to run?

[runspired]

I hit a very similar sounding issue when landing the refactor of @ember-data/model to native classes. It resulted in one failure in this library for array changes not dirtying the parent owner. After investigating it seemed likely the issue was with the array code. I'll try to find some time soon to poke at a fix here.