Model says "someProperty: belongsTo('model-name')" but "get('someProperty').save()" doesn't exist

Ember Data
1

It was brought to my attention by one of my developers and I confirmed it thru testing several of our models the following “problem”:

  1. We define our models with belongsTo, like someProperty: belongsTo('model-name')
  2. Later on, when we have a reference to the object that has the property someProperty, we let abc = ref.get('someProperty'), make some changes via abc.set("a","b") to the returned object (yes, it’s a valid object, not null, the object existed in the database, etc)
  3. When we call abc.save() (remember, abc is the return value from our call to get('someProperty') which was a belongsTo property), we get a TypeError saying .save is not a function: Uncaught TypeError: abc.save is not a function

Now, I realize that if we instead did abc.get('content').save(), that would work - it appears that the return from belongsTo properties are simply proxies, with a content property that has our actual model instance.

For now, my developers have resorted to just doing let abc = ref.get('someProperty.content'), but I can’t hep but feel that there’s got to be a better solution that getting what I presume is a “private” property.

How do we go about getting the actual model instance when we get() a belongsTo property, instead of that proxy object? Or should that proxy object also be proxying the .save() calls? Or did we miss some documentation somewhere that already covers this exact thing…?

Thanks, everyone!

2

Does anyone have any insight into this? It looks incredibly messy having my developers doing get("foobar.content") everywhere instead of just get("foobar") - why can’t that thing just proxy save()/destroyRecord() or return content directly? Or implement then() and call then() right after get’ing if it’s already resolved?

Any one at all, any thoughts?

3

Your observations about using .content are correct. I would avoid using it. .get(‘related-thing’) will always return a promise and does so for our sanity. In your particular case, calling save in the .then() is most preferable. It can make for unpleasant code at times. When we run into such cases, we craft our route model topology around the whole notion of keeping the async nature of things easy on the eyes.

4

But that’s the thing - if the proxy is already resolved, doing .get().then() never results in the then() callback being called, so .then() only seems to help if it’s unresolved…do you just special case that every time?