Canary - Add documentation for ObjectController deprecation

[zyllorion]

33042d9

Says to migrate to model.propertyName but no example is given in documentation or tests. Where is best practice to define this?

[rwjblue]

👍 - We absolutely need to add this to the deprecations guide (and have the deprecation link to the guide).

For more information in the interim #10062 (comment) probably has the best list of things to check/work on.

A few other references:

• Deprecate Ember.ObjectController. #10062 - Made the deprecation.
• Remove ObjectController proxying behavior. TryGhost/Ghost#4748 - Updated Ghost to remove the usage of Ember.ObjectController.

[zyllorion]

Great, thanks!
On a related issue, have there been, or are there, changes to the method of controller property access? Just having a few issues with latest build passing a controller property (array of objects) and can't see anything obvious in commit history. {{component-name param=myControllerArray}} now passes null, used to work, fairly sure I havn't changed anything in that area of code.

[zyllorion]

While I think of it, the documentation could really use an example of how to load multiple models into a controller, especially if this is an area that is changing.

[rwjblue]

{{component-name param=myControllerArray}} now passes null

@zyllorion - No, that should still work properly. JSBin demo

While I think of it, the documentation could really use an example of how to load multiple models into a controller, especially if this is an area that is changing.

Maybe, I'm not really sure if we should document it differently. The hooks are present (the route's model and setupController hooks) and are documented in general.

[zyllorion]

The reason I mention is that when I started, it took me ages to find a forum post that worked, ending up with the slightly obscure:

export default Ember.Route.extend({
    model: function(params) {
        var self = this;
        //may be able to remove wrapping promise?
        return new Ember.RSVP.Promise(function(resolve) {
            new Ember.RSVP.hash({
                model1: self.store.find('model-name-1', params.some_id),
                model2: self.store.find('model-name-2', params.some_id),
                model3: self.store.findAll('model-name-3')
            }).then(function(results) {
                resolve({
                    model1: results.model1,
                    model2: results.model2,
                    model3: results.model3
                });
            });
        });
    },

    setupController: function(controller, model) {
        controller.set('model', model);
    },

Re the other issue, the reason for asking that was if we are removing proxying behaviour by specifying {{model.fieldName}} then logically I'd expect a requirement for {{controller.propertyName}} or {{view.propertyName}} and hence it made sense that the code didn't work anymore (though I havn't found out why or how to access the property yet, working on it!).

[jcope2013]

@zyllorion this shorter version should work also

no need to wrap it in a promise or call then function on a hash in a model hook, it will wait for the promises to resolve before the template loads and set model to the return value (model will be same as what you previously had)

export default Ember.Route.extend({
    model: function(params) {
        var self = this;
        return Ember.RSVP.hash({
                model1: self.store.find('model-name-1', params.some_id),
                model2: self.store.find('model-name-2', params.some_id),
                model3: self.store.findAll('model-name-3')
        });
    }
});

[zyllorion]

@jcope2013 Aha, great I suspected there was a simpler way so thanks for that. Slightly tangential question; what would be the recommended way to propogate, handle and feedback any errors in the ajax calls? With the wrapping promise I could set a failure function to re-route to an error/advice page, without there's probably some Ember magic I need to know about?

[SphtKr]

Additionally, besides the deprecation guide, please update the guide page on using controllers ASAP. If this is deprecated, it's currently being taught as best practice by that guide. The guide also doesn't eschew proxying access to model.x as x, rather it repeatedly does exactly this. If this is bad practice please change that guide.

[rwjblue]

@SphtKr - Thanks for pointing this out, would you mind making a PR to https://github.com/emberjs/website fixing that guide?

[SphtKr]

I'd be willing to do that, but I'm a little unsure exactly what best practice is now... Especially in the case of ArrayController's impending deprecation. I get that we should do model.x instead of x, but will both ObjectController and ArrayController simply be replaced with Controller and everything else remain the same?

More generally...while I appreciate the spirit behind the categorical response, "hey, don't gripe, contribute!" I think this may be something the core team has to address, because previously this proxying behavior was a selling point...e.g. from the linked guide:

The advantage of this architecture is that it is easy to get started by accessing the properties of the model via the object controller. If, however, you need to transform a model property for a template, there is a well-defined place to do so without adding view-specific concerns to the model.

So, not being in tune with the new architecture direction that is guiding this change, I'm not sure I could adequately rewrite this myself. That is, there is a message change here and not just a technical change, and I'm not exactly sure what the new message/narrative is around use of the controller layer in the architecture now (I think many of us aren't, and that's why the ObjectController deprecation feels like it came out of left field).

Don't misunderstand me, I'm thrilled with 90% or more of the changes I see happening in Ember, and I know every change breaks someone's workflow. But this particular one seems like a pretty significant shift in architecture direction hidden in a technical change--and my point was more that arguably that whole guide (and the ArrayController one too, really) now no longer even makes sense.

[neverfox]

I concur with @SphtKr in that I'm lost on the justification behind the change and would appreciate an explanation so that I can better understand it.

[mixonic]

That is, there is a message change here and not just a technical change, and I'm not exactly sure what the new message/narrative is around use of the controller layer in the architecture now (I think many of us aren't, and that's why the ObjectController deprecation feels like it came out of left field).

@SphtKr you are 100% correct. We have a lot of messaging items to touch on before 2.0.

The object controller changes are not in release yet. We need to update the docs and add a deprecation guide. Definitely before we make the 1.11 release. There is an effort to revamp the guides and docs being lead by @trek amongst others (check it out here), but it sounds like documentation updates should continues to go into the website repo until otherwise noted.

As to the justification for this change: Proxies are very confusing to new developers. As experience Ember users, all of us are probably comfortable with them. We know that a template like this:

{{name}}
<button {{action "save" model}}>save</button>

means the name probably comes from the model. We know that the model needs to be referenced explicitly because this is actually a proxy.

For new developers this is a disaster. It is a tricky concept to learn, and throws up a hurdle when they try to do anything more complicated that display data. Even experienced developers will be bit by having a proxy where they don't expect one in a large app.

Proxies use unknownProperty and setUnknownProperty, which is mean dynamic behavior that cannot be optimized as well as a static class shape.

For these reasons, and to generally align Ember with the component patterns in other solutions (none of which use proxies), we will be removing object and array proxies.

[mixonic]

Deprecation guide added in: emberjs/website#2082