Data: "*.content" returns an array of InternalModel

[mike-north]

A very typical pattern to follow in ember-data 1.0.0-beta.* is retrieving the contents of an array (i.e., a hasMany) via .content.

example

Ember.Route.extend({
  model() {
     return this.modelFor('otherRoute').get('items.content'); // Array of models
  }
});

In ember-data 1.13.x, this is not an array of DS.Model, but rather InternalModel. This concept shouldn't be leaked out of the ember-data internals.

[btecu]

I've also ran into this. I just thought that maybe we weren't supposed to access content.
It would be useful to have this clarified.

[jcope2013]

"ManyArray, the object Ember Data uses to represent DS.hasMany relationships has been changed so it no longer extends from RecordArray. This means if you were relying on the RecordArray's content property to access the underlying array you will now need to use the .toArray() method."

 return this.modelFor('otherRoute').get('items').toArray();

under beta 14 (https://github.com/emberjs/data/blob/master/CHANGELOG.md)

[mike-north]

Current best practices aside, .content is a pattern found in a huge number of ember apps. As they migrate from 1.x -> 2.x, this will often be a snag that they hit.

Additionally, InternalModel is a private and internal ember-data construct, but there is no indication in a call like

list.get('items.content'); 

that the developer is doing something private (i.e., underscores)

[wecc]

I've seen a lot of people asking questions about this when using 1.13.

I would like to suggest we move content to _content and use defineProperty() to add a deprecation warning when accessing content. This way we can also proxy content to toArray() and not break users apps.

[stefanpenner]

I would suggest just make content a cp. Botha deprecation and the content list itself continues to be in sync

[wecc]

I'm closing this in favor of #3245

[plicjo]

I just ran into this today in Ember 2.9. I'm a noob and this just crushed me. .toArray(). Got it!

[runspired]

@wecc @stefanpenner rediscovered this while spelunking to find where I was paying the materialization cost during a store.query. The way this forces materialization is useful, but also magical, and I suspect a computed property and swapping for our own ArrayProxy will greatly clean up confusion, debug story, and code exploration here.

[chilicoder]

@runspired can you link to any materials which explain technique (" swapping for our own ArrayProxy") in details?