Can you alias the controller to another name?

[krimple]

This is more of a question - the controllerAs syntax lets you rename the controller 'this' instance to something else, and you can do that with ng-controller, but in the router you get an automatic rename to the component name.

I'm not a huge fan of this, as I'd like to use vm as my view model name if I want to, regardless of the component name. That kind of follows what I've seen in Angular 2.0 as a naming convention as well as using controllerAs with John Papa's naming conventions.

For example, I have a galleries use case that lists all galleries, and I'd prefer to have the controller instance name be vm, so I can inject 'galleries' as a model element. such as:

vm.galleries

rather than

galleries.galleries

Any way to do this? I'd like to see it as an 'as' property in the route instructions

Ken

[mgbee8]

I would +1 this.
If it is best practice to minimize the variables on scope this is a great way to achieve this.
This issue impacts existing directives I have created where I could go,
using controllerAs methodology, scope.vm.property, now, with the new router it is scope.component.property. If this directive is used in multiple components the issue is self evident.
To implement the new router and migrate to 1.4 I would need to return to assigning variables to scope again.

I would call this an alias instead of as.
I am certain this issue will continue to arise as users who have been following 'best practices' look at migrating to the new router, it would also aid in scenarios where users generate html from metadata and use vm or some other alias as a consistent controllerAs view model name

[krimple]

It does look like the code supports an 'as' token, and that it creates
aliases for it. However, it looks like with further research, it also
renames the route instruction. So if you alias the controller as 'vm', then
your route function is 'vm()' - not a great plan.

I'd be happy seeing them support contollerAs type renaming in the view but
then keeping the route name the name of the component. Or maybe having a
name= in the route path?

Ken Rimple
Training and Mentoring Services
Chariot Solutions
610-608-3935
@krimple

On Sun, Mar 15, 2015 at 10:50 AM, Michael notifications@github.com wrote:

I would +1 this.
If it is best practice to minimize the variables on scope this is a great
way to achieve this.
This issue impacts existing directives I have created where I could go,
using controllerAs methodology, scope.vm.property, now, with the new
router it is scope.component.property. If this directive is used in
multiple components the issue is self evident.
To implement the new router and migrate to 1.4 I would need to return to
assigning variables to scope again.

I would call this an alias instead of as.
I am certain this issue will continue to arise as users who have been
following 'best practices' look at migrating to the new router, it would
also aid in scenarios where users generate html from metadata and use vm or
some other alias as a consistent controllerAs view model name

Reply to this email directly or view it on GitHub
#179 (comment).

[timkindberg]

Seems like this could be another option on $componentLoaderProvider because its another way to control the 'conventions' of the new router. I'd consider this a 'convention'.

[krimple]

Tim, I'd agree. Would be nice if we could set a viewModelName property or something. like $componentLoaderProvider.setViewModelName('vm');

[timkindberg]

I think it would be a function that takes the component name and returns the viewModelName as a string. This would be in line with the other methods.

$componentLoaderProvider.setViewCtrlNameMapping(function(componentName){
    return 'vm'; // Ignore incoming component name and just set them all to 'vm'
});

[krimple]

Agreed
On Mar 15, 2015 10:54 PM, "Tim Kindberg" notifications@github.com wrote:

I think it would be a function that takes the component name and returns
the viewModelName as a string. This would be in line with the other methods.

$componentLoaderProvider.setViewCtrlNameMapping(function(componentName){
return 'vm'; // Ignore incoming component name and just set them all to 'vm'
});

Reply to this email directly or view it on GitHub
#179 (comment).

[mgbee8]

The as method works for aliasing the component, thanks for pointing that out Ken. I keep having to remember to read the code and not the documentation. This will make migration simpler to 1.4 and beyond. I still would recommend a means for aliasing the controller as originally requested.

[krimple]

So I'm fine with either one, although the more I think of it as: is better
as it's in the routing instruction, and therefore is one place to look as
opposed to searching around for the prefix. Plus you won't have a second
method call with the equivalent of case statements everywhere if you wanted
to customize each one differently.

You could argue that you should be able to change the default, and that the
as: would override the default.

Ken

Ken Rimple
Training and Mentoring Services
Chariot Solutions
610-608-3935
@krimple

On Mon, Mar 16, 2015 at 9:46 AM, Michael notifications@github.com wrote:

The as method works for aliasing the component, I keep having to remember
to read the code and not the documentation. This will make migration
simpler to 1.4 and beyond. I still would recommend a means for aliasing the
controller as originally requested.

Reply to this email directly or view it on GitHub
#179 (comment).

[btford]

@timkindberg – thanks for the suggestion. I'm willing to try something like this, but I think it needs to be scoped so that components written with different conventions can still be used in the same application.

This may be related to other issues that have recently been brought up with regards to configuring component conventions.

[timkindberg]

@btford the 'as' solution is great too, if I understand it correctly. I hadn't learned of it yet when I made my suggestion above. So 'as' might be good enough on its own.

[btford]

No worries. I think it was still in the pipeline at that time. I'm going to update the docs with more info.

[mgol]

The ideal solution migration-wise would be to get the ability to scope the template to the controller, not scope (that would simplify the module.component helper as we discussed recently). This won't happen before 1.5, though and people will most likely still need an override for situations where they need the scope.

[InvisibleGit]

+1 for controllerAs allowance. For various reasons we use some conventions in out template files, weather it's 'vm', or we subclass our controllers which use the same template file, and thus the same alias for the controller.

I'm not sure 'as:' syntax is what we need, but will wait for updated docs...