Ember.Object/ObjectProxy should support forwarding method calls to its content

Proposals
1

I’ve got an ArrayController whose content is a collection of Ember.Model objects, I’m using itemController, so each item is wrapped in an ObjectController.

At some point I want to save an item:

...
doAThing: function() {
   var item = this.firstObject();
   item.set("foo", "bar");
   item.save();
}
...

(Obviously I could also send the item to the router to handle, but the save happens somewhere).

This now blows up because item at this point is an ObjectController, not an Ember.Model object, so doesn’t have a save method.

I could do item.get("content").save(), but I then have to be sure of what kind of object I’m dealing with and that it’s definitely only one level deep and not in another ObjectProxy for whatever reason.

It would be nice if ObjectProxy automagically forwarded undefined methods to its underlying object, but I don’t think that’s possible until we have proxy objects in ES6.

Instead, ObjectProxy could have a send method which forwards to its content, calling send on an Ember.Object would just be the same as calling the method directly.

The above then becomes item.send("save") and we don’t have to care whether we’ve got the actual item, an ObjectController or other ObjectProxy.

2

YES! I like to use decorators (and encourage their use by others) and my code has no guarantee that the content of the decorator is the actual model. I was thinking invoke would be the better method name to avoid conflicting with actions.

3

invoke is already defined on Enumerable, not sure if that’s a good thing because it’s a similar concept, or potentially confusing but agree it sounds better than send.

4

I think it’s good personally because it’s fairly directly analogous… you’re proxying a method call in both situations, nothing more nothing less. Send has all that action baggage.

5

Agreed, especially if invoke of an array called invoke on its members which means that you can call it on an array of proxied objects and have it “do the right thing” on the contained objects.

6

Yes that’d almost be a necessary change IMO. It’d add an extra check to Enumerable#invoke but that’s not a critical path at all.

7

Hey, sorry to revive an old topic here but I’m struggling to find any other info on this topic. Was this ever put through? I’m constantly running into this issue and doing things like record.get('content').save() feels really gross.