belongsTo-relationship returning Ep.LazyModel

[hperl]

I'm not sure if this is a bug or just improper use on my side, but I have the problem that for a belongsTo relationship, the associated model never turns from an Ep.LazyModel instance to a proper (e.g. App.Foo) instance.

The JSON just serves the id, e.g. {foo_id: 42}.

Any hints?

[ghempton]

Can elaborate on how it never turns into one? Lazy models will load their underlying record once a property is observed/accessed.

[hperl]

I will investigate into this more, but from what I saw it looks like even though the Lazy Model loads the record, the main binding for the relationship does not reflect the loading. Maybe some kind of property change notification is needed after LazyModel.loaded()?

[ghempton]

It should automatically be updated. I'm not sure I fully understand what is happening here. Can you share some code?

[hperl]

So, I have the following models:

App.Foo = Ep.Model.create({
  name: Ep.attr('string'),
  bars: Ep.hasMany(App.Bar)
})
App.Bar = Ep.Model.create({
  desc: Ep.attr('string'),
  foo: Ep.belongsTo(App.Foo)
})

... and the following view template for a App.BarView (scoped to a bar instance):

Show Bar: {{desc}},
foo: {{foo}},
foo name: {{foo.name}}

This renders like this:

Show Bar: super bar,
foo: <Ep.LazyModel:ember123:(unloaded App.Foo):[1, foo1]>,
foo name: awesome foo

So it seems that the attributes of the belongsTo (foo) are getting fetched correctly, but the main path does not get changed (bar.foo). I did some further investigation and saw that Ep.LazyModel.load() gets called correctly (and returns the loaded model), however, no one notifies the associated model (bar) of this change.

I think the best thing to do is to just notify all associations that the model changed (without the associations becoming dirty). Any ideas? Or am I just doing it wrong?

[jasonkriss]

What's the use case for explicitly knowing when an Ep.LazyModel is resolved? You should be able to treat it just the same as if it were the actual Ep.Model that it proxies. Then, when you try to access/observe one of it's properties, it will resolve without you having to worry about it. I haven't had any issues with the way it works, but it's certainly possible there is a valid use case I am missing.

[hperl]

@jasonkriss you're right that this is only really an issue in special cases. For me this came up when I used an Ember.Select:

{{view Ember.Select
       contentBinding="controller.foos"
       valueBinding="foo"
       optionLabelPath="content.name"}}

In that case, selection is not properly handled, since the content is an array of App.Foos, but the current value binding is an Ep.LazyModel. I got around this by manually replacing the lazy model by its content, but this just a hack.

[ghempton]

This issue actually runs a little deep into Ember.js core. Ember has the notion of Ember.isEqual, but it still uses === in most places. In the case of Ember.Select, my guess is that it is using the latter. proxy.isEqual(content) will return true, but proxy === content will be false.

[ghempton]

Not really an issue here any more.