New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: angular.component helper #10007

Closed
johnlindquist opened this Issue Nov 11, 2014 · 119 comments

Comments

@johnlindquist
Contributor

johnlindquist commented Nov 11, 2014

Please see this demo: https://jsbin.com/yixote/11/edit?html,js,output

Thanks to "bindToController" in angular 1.3, we're able to create a much simpler api for building components.

Just as "angular.service" helps us to easily build an "angular.provider", I strongly believe a simplified "angular.component" could help us easily build components with "angular.directive".

I'm sure everyone will have plenty of feedback :)

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Nov 11, 2014

Contributor

I feel like it's adding another way to do the same thing, which I tend to not like doing, buuuuut, maybe.

@petebacondarwin what do you think?

Contributor

caitp commented Nov 11, 2014

I feel like it's adding another way to do the same thing, which I tend to not like doing, buuuuut, maybe.

@petebacondarwin what do you think?

@johnlindquist

This comment has been minimized.

Show comment
Hide comment
@johnlindquist

johnlindquist Nov 11, 2014

Contributor

@caitp does anyone use angular.provider? Nope, the use angular.factory or angular.service. I think it's time for angular.directive to get the same treatment :)

Contributor

johnlindquist commented Nov 11, 2014

@caitp does anyone use angular.provider? Nope, the use angular.factory or angular.service. I think it's time for angular.directive to get the same treatment :)

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Nov 11, 2014

Contributor

people use angular.provider if they want to be able to operate on the object meaningfully within config blocks :> anyways, my personal opinion is that we sort of offer too many flavours of koolaid already, it's much simpler for people if there's just one way to do everything.

On the other hand, the directive API is ridiculously complicated, so maybe some sugar would be useful for it. Lets see what people think

Contributor

caitp commented Nov 11, 2014

people use angular.provider if they want to be able to operate on the object meaningfully within config blocks :> anyways, my personal opinion is that we sort of offer too many flavours of koolaid already, it's much simpler for people if there's just one way to do everything.

On the other hand, the directive API is ridiculously complicated, so maybe some sugar would be useful for it. Lets see what people think

@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Nov 11, 2014

Member

IMO convince shortcuts are cool / important but I would rather not do it in 1.3 for 2 reasons:

  • learning directives is already hard and introducing yet another approach will only further confuse people. On the other hand guys who know what they are doing are probably having convenience shortcuts;
  • component is kind of bad name / timing given Angular2 effort.

I'm not opposed but I would prefer that we don't do it. My private, personal opinion :-)

IMO convince shortcuts are cool / important but I would rather not do it in 1.3 for 2 reasons:

  • learning directives is already hard and introducing yet another approach will only further confuse people. On the other hand guys who know what they are doing are probably having convenience shortcuts;
  • component is kind of bad name / timing given Angular2 effort.

I'm not opposed but I would prefer that we don't do it. My private, personal opinion :-)

@johnlindquist

This comment has been minimized.

Show comment
Hide comment
@johnlindquist

johnlindquist Nov 11, 2014

Contributor

@petebacondarwin I agree with your points, but those of us building convenience shortcuts would love to standardize on these shortcuts for the community, teaching, etc. Having something blessed by the angular team would be wonderful, but we can figure out something else if not.

Contributor

johnlindquist commented Nov 11, 2014

@petebacondarwin I agree with your points, but those of us building convenience shortcuts would love to standardize on these shortcuts for the community, teaching, etc. Having something blessed by the angular team would be wonderful, but we can figure out something else if not.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Nov 11, 2014

Member

@johnlindquist - hey I haven't even commented yet!

I think this would defeat a strong reason to migrate to v2!!

But seriously while it would be nice to make directive development easier I agree that 1.3 is probably not the place.

From what I see this helper would change

mod.directive ('cmpnt', function () {
  return {
    controllerAs: 'cmpnt',
    link: linkFn,
    scope: scopeDef,
    template: template,
    controller: ControllerFn
  };
});

Into

mod.component ('cmpnt', template, scopeDef, controller, linkFn);

While it certainly has fewer chars I am not convinced this is much more grokable. Also as a general rule we are trying to move away from optional positional params.

Personally I don't think this should go in the core for 1.x but if there was large community pressure we could look at improving the defaults for the DDO in a 1.4 release.

Member

petebacondarwin commented Nov 11, 2014

@johnlindquist - hey I haven't even commented yet!

I think this would defeat a strong reason to migrate to v2!!

But seriously while it would be nice to make directive development easier I agree that 1.3 is probably not the place.

From what I see this helper would change

mod.directive ('cmpnt', function () {
  return {
    controllerAs: 'cmpnt',
    link: linkFn,
    scope: scopeDef,
    template: template,
    controller: ControllerFn
  };
});

Into

mod.component ('cmpnt', template, scopeDef, controller, linkFn);

While it certainly has fewer chars I am not convinced this is much more grokable. Also as a general rule we are trying to move away from optional positional params.

Personally I don't think this should go in the core for 1.x but if there was large community pressure we could look at improving the defaults for the DDO in a 1.4 release.

@johnlindquist

This comment has been minimized.

Show comment
Hide comment
@johnlindquist

johnlindquist Nov 11, 2014

Contributor

@petebacondarwin sorry, I thought @pkozlowski-opensource was you :)

  1. grokable - I would argue that:
mod.component('card', template);

is _much_ more grokable than

mod.directive('card', function(){
return {
template: template
}
})

The goal is to lessen the barrier between creating directives and cover the 90% scenario. Also, if the focus is on injecting providers into the controller (and not the directive), the factory function (the second param in .directive) just becomes cruft.

  1. params - I totally agree on position params. If you want lots of {options}, use .directive(), if you want to cover the 90% scenario, use .component() or whatever you want to name it.
  2. 1.3 - Agreed, 1.3 is probably the wrong place, but the Angular community now has years of experience under its belt and it feels to me like it's time to start wrapping some of the most common tasks with more helpful APIs and revisit how we introduce newcomers to Angular.

Anyway, this all stems from the larger community sentiment that "angular is hard". I teach angular all the time and I've seen people get super confused over what should be the easiest concepts because of the API. I know angular is easier than it lets on, but I think a simpler API blessed by the angular team would go a long way to convince everyone else :P.

Obviously none of this is necessary and it doesn't add any functionality, but that doesn't mean it's not worth it!

/end rant?

Contributor

johnlindquist commented Nov 11, 2014

@petebacondarwin sorry, I thought @pkozlowski-opensource was you :)

  1. grokable - I would argue that:
mod.component('card', template);

is _much_ more grokable than

mod.directive('card', function(){
return {
template: template
}
})

The goal is to lessen the barrier between creating directives and cover the 90% scenario. Also, if the focus is on injecting providers into the controller (and not the directive), the factory function (the second param in .directive) just becomes cruft.

  1. params - I totally agree on position params. If you want lots of {options}, use .directive(), if you want to cover the 90% scenario, use .component() or whatever you want to name it.
  2. 1.3 - Agreed, 1.3 is probably the wrong place, but the Angular community now has years of experience under its belt and it feels to me like it's time to start wrapping some of the most common tasks with more helpful APIs and revisit how we introduce newcomers to Angular.

Anyway, this all stems from the larger community sentiment that "angular is hard". I teach angular all the time and I've seen people get super confused over what should be the easiest concepts because of the API. I know angular is easier than it lets on, but I think a simpler API blessed by the angular team would go a long way to convince everyone else :P.

Obviously none of this is necessary and it doesn't add any functionality, but that doesn't mean it's not worth it!

/end rant?

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Nov 11, 2014

Member

In many ways I agree with you John. The complicated directive api is a major factor in the drive to v2 where the api is completely reworked to get away from this unnecessary complexity.

I also note that most of the service confusion comes from the difference between service and factory rather than with provider.

The question is where is the right place to make the improvement.

Member

petebacondarwin commented Nov 11, 2014

In many ways I agree with you John. The complicated directive api is a major factor in the drive to v2 where the api is completely reworked to get away from this unnecessary complexity.

I also note that most of the service confusion comes from the difference between service and factory rather than with provider.

The question is where is the right place to make the improvement.

@johnlindquist

This comment has been minimized.

Show comment
Hide comment
@johnlindquist

johnlindquist Nov 11, 2014

Contributor

@petebacondarwin are you at Google HQ now? I'm coming over next month or so to talk with the guys about doing new videos for the homepage, etc. Would be fun/constructive to play around with simple APIs, even if they land in a different project.

Contributor

johnlindquist commented Nov 11, 2014

@petebacondarwin are you at Google HQ now? I'm coming over next month or so to talk with the guys about doing new videos for the homepage, etc. Would be fun/constructive to play around with simple APIs, even if they land in a different project.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Nov 28, 2014

Member

I am as always in London, UK. Give me a shout when you are next over this side of the pond

Member

petebacondarwin commented Nov 28, 2014

I am as always in London, UK. Give me a shout when you are next over this side of the pond

@demisx

This comment has been minimized.

Show comment
Hide comment
@demisx

demisx Dec 12, 2014

I would like to add my 2 cents since we are in the business of developing various enterprise applications. Please keep in mind that I share our team opinion only hoping it may add value.

I like the idea of simplifying the directive API, but calling this variant a 'component' would be very confusing. In our understanding, A component bears a much higher abstraction. A component is a stateless isolated chunk of product functionality (think of app features) that entire app is broken down into. A component may encapsulate a various number of resources/assets that are necessary to deliver that particular app feature. For example, a 'profile' component, besides directives, may contain services, images, SASS, filters etc. - everything that is necessary for this component/feature to work. What @johnlindquist shows here, appears to be more of a UI widget, then component, since it is implemented via one directive. So, maybe, if this was defined as module.widget instead, it would make more sense. Otherwise, there would be an overlap of concepts.

demisx commented Dec 12, 2014

I would like to add my 2 cents since we are in the business of developing various enterprise applications. Please keep in mind that I share our team opinion only hoping it may add value.

I like the idea of simplifying the directive API, but calling this variant a 'component' would be very confusing. In our understanding, A component bears a much higher abstraction. A component is a stateless isolated chunk of product functionality (think of app features) that entire app is broken down into. A component may encapsulate a various number of resources/assets that are necessary to deliver that particular app feature. For example, a 'profile' component, besides directives, may contain services, images, SASS, filters etc. - everything that is necessary for this component/feature to work. What @johnlindquist shows here, appears to be more of a UI widget, then component, since it is implemented via one directive. So, maybe, if this was defined as module.widget instead, it would make more sense. Otherwise, there would be an overlap of concepts.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Dec 15, 2014

Member

Heard this is actually going to happen! ['hip', 'hip'] 👏

Member

kentcdodds commented Dec 15, 2014

Heard this is actually going to happen! ['hip', 'hip'] 👏

@vivainio

This comment has been minimized.

Show comment
Hide comment
@vivainio

vivainio Dec 15, 2014

Hopefully using templateUrl instead of direct template is going to be straightforward.

Hopefully using templateUrl instead of direct template is going to be straightforward.

@thorn0

This comment has been minimized.

Show comment
Hide comment
@thorn0

thorn0 Dec 15, 2014

Contributor

#5893 is related to this kind of directives, so it might make sense to consider doing it as well

Contributor

thorn0 commented Dec 15, 2014

#5893 is related to this kind of directives, so it might make sense to consider doing it as well

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Dec 17, 2014

Member

Oh, just wanted to make sure that this is mentioned, but I believe it is the desire of everyone to move to the controllerAs syntax. If this angular.component supported that by default it would be great. Not sure how to make that happen without requiring the developer to specify the controller's name (vm for example), but I definitely think that angular.component should default to bindToController and controllerAs: 'somethingSpecifiedByTheDeveloper'.

Member

kentcdodds commented Dec 17, 2014

Oh, just wanted to make sure that this is mentioned, but I believe it is the desire of everyone to move to the controllerAs syntax. If this angular.component supported that by default it would be great. Not sure how to make that happen without requiring the developer to specify the controller's name (vm for example), but I definitely think that angular.component should default to bindToController and controllerAs: 'somethingSpecifiedByTheDeveloper'.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Dec 17, 2014

Member

@kentcdodds - this is included in @johnlindquist's proposal. By default it uses the name provided as the first parameter to the call unless it is specifically provided as a controllerAs property on the config parameter.

Member

petebacondarwin commented Dec 17, 2014

@kentcdodds - this is included in @johnlindquist's proposal. By default it uses the name provided as the first parameter to the call unless it is specifically provided as a controllerAs property on the config parameter.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Dec 17, 2014

Member

Duh, must have missed that. Thanks for setting me straight @petebacondarwin :-)

Member

kentcdodds commented Dec 17, 2014

Duh, must have missed that. Thanks for setting me straight @petebacondarwin :-)

@Zizzamia

This comment has been minimized.

Show comment
Hide comment
@Zizzamia

Zizzamia Dec 24, 2014

Contributor

In angular-seed there is already an orientation to build Component related app. I can understand can be confusing have Web Components and Angular Components, but have an official angular.component will totally #simplify the way to scaffold new projects and improve your angular.component version by version. +1 for angular.component

Contributor

Zizzamia commented Dec 24, 2014

In angular-seed there is already an orientation to build Component related app. I can understand can be confusing have Web Components and Angular Components, but have an official angular.component will totally #simplify the way to scaffold new projects and improve your angular.component version by version. +1 for angular.component

@petebacondarwin petebacondarwin modified the milestones: 1.4.x, 1.3.x Jan 12, 2015

@a-lucas

This comment has been minimized.

Show comment
Hide comment
@a-lucas

a-lucas Jan 22, 2015

@demisx

I totally agree on the component naming. widget is much more appropriate than component.

a-lucas commented Jan 22, 2015

@demisx

I totally agree on the component naming. widget is much more appropriate than component.

@demisx

This comment has been minimized.

Show comment
Hide comment
@demisx

demisx Jan 22, 2015

@a-lucas 👍 FYI, here is how we define and break down app into components: AngularAtom component based organization) post. A component is so much more, than just a directive.

demisx commented Jan 22, 2015

@a-lucas 👍 FYI, here is how we define and break down app into components: AngularAtom component based organization) post. A component is so much more, than just a directive.

@a-lucas

This comment has been minimized.

Show comment
Hide comment
@a-lucas

a-lucas Jan 22, 2015

@demisx
I still don't understand the difference between a module and a component. This folder structure described in the link you provided matches almost exactly the one used in the MEAN.js project.

I usually organize my code the same way, because it makes it easier to find and visualize files in large projects. ( The project I actually work on has around a hundred controllers)

For re-usability purpose, it is better to have every folder being an independent module. But this is not that easy. Taking the example of a profile module (or profile component). One of the mandatory condition for re usability of the profile 'component' is that both project uses a very similar data structure.

But again, this can be tweaked into sub-module : I do have for example my profile module organized this way :

  • profile module
    • personal informations sub-module
      /partials & controllers & routes
    • address sub-module
      /partials & controllers & routes
    • documents sub-modules
      /partials & controllers & routes
    • status sub-modules
      /partials & controllers & routes
      and the list goes on.

I just don't get what advantages components would bring to this existing code organisation.

a-lucas commented Jan 22, 2015

@demisx
I still don't understand the difference between a module and a component. This folder structure described in the link you provided matches almost exactly the one used in the MEAN.js project.

I usually organize my code the same way, because it makes it easier to find and visualize files in large projects. ( The project I actually work on has around a hundred controllers)

For re-usability purpose, it is better to have every folder being an independent module. But this is not that easy. Taking the example of a profile module (or profile component). One of the mandatory condition for re usability of the profile 'component' is that both project uses a very similar data structure.

But again, this can be tweaked into sub-module : I do have for example my profile module organized this way :

  • profile module
    • personal informations sub-module
      /partials & controllers & routes
    • address sub-module
      /partials & controllers & routes
    • documents sub-modules
      /partials & controllers & routes
    • status sub-modules
      /partials & controllers & routes
      and the list goes on.

I just don't get what advantages components would bring to this existing code organisation.

@demisx

This comment has been minimized.

Show comment
Hide comment
@demisx

demisx Jan 22, 2015

@a-lucas We currently don't use the concept of a widget at all. Entire app is broken down into components. A component can be a widget too. I've just suggested the term widget if Angular team were still going to implement this directive-based approach. So it would be angular.widget instead of angular.component, since directives deal with UI and components deal with so much more, than UI. We see a component as a grouping of various files and other sub-components. Components are similar to modules in other languages, but we chose the term component so it's not confused with the Angular modules themselves.

demisx commented Jan 22, 2015

@a-lucas We currently don't use the concept of a widget at all. Entire app is broken down into components. A component can be a widget too. I've just suggested the term widget if Angular team were still going to implement this directive-based approach. So it would be angular.widget instead of angular.component, since directives deal with UI and components deal with so much more, than UI. We see a component as a grouping of various files and other sub-components. Components are similar to modules in other languages, but we chose the term component so it's not confused with the Angular modules themselves.

@thorn0

This comment has been minimized.

Show comment
Hide comment
@thorn0

thorn0 Jan 22, 2015

Contributor

Agree on this. Widget is a better word.

Contributor

thorn0 commented Jan 22, 2015

Agree on this. Widget is a better word.

@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Jan 22, 2015

Member

I don't think naming is the main problem here... Regardless of the name used there are many flavours of widgets / components, ex.: do I use transclude or not? Should a template by embedded or downloaded from a URL? If we start to combine all those possibilities, how this new API will differ as compared to the existing one?

There are certain class of directives and we could have different APIs for those (this is what Angular2 is trying to do) but I don't think one class of directives will help a lot here, regardless of its name...

I don't think naming is the main problem here... Regardless of the name used there are many flavours of widgets / components, ex.: do I use transclude or not? Should a template by embedded or downloaded from a URL? If we start to combine all those possibilities, how this new API will differ as compared to the existing one?

There are certain class of directives and we could have different APIs for those (this is what Angular2 is trying to do) but I don't think one class of directives will help a lot here, regardless of its name...

@demisx

This comment has been minimized.

Show comment
Hide comment
@demisx

demisx Jan 22, 2015

@pkozlowski-opensource Agreed. I don't think introducing this in 1.x will add any value.

demisx commented Jan 22, 2015

@pkozlowski-opensource Agreed. I don't think introducing this in 1.x will add any value.

@thorn0

This comment has been minimized.

Show comment
Hide comment
@thorn0

thorn0 Jan 22, 2015

Contributor

I see no harm in expressing explicitly this knowledge about the different kinds of directives in the API of 1.x. This distinction is a really important gotcha about the framework.

Contributor

thorn0 commented Jan 22, 2015

I see no harm in expressing explicitly this knowledge about the different kinds of directives in the API of 1.x. This distinction is a really important gotcha about the framework.

@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Jan 22, 2015

Member

@thorn0 the only harm I can see is introducing multiple-way-of-doing-the-same-thing. I'm still astonished how much difficulty people are having with various ways of registering services in DI (.service, .factory, .value etc.).

But this is kind of secondary - the main issues are:

  • what distinct classes of directives we can see (regardless of their names)
  • what are the APIs proposed for those
  • how the proposed API differs from the existing one (conceptual difference and actual difference in the code)

I think that answering the above questions is more important that debating if we want to have it in core or not at this point. If we can clearly identify distinct concepts and find good API for those, I'm all for embedding this in AngularJS. So let's focus the discussion on the concrete proposals.

@thorn0 the only harm I can see is introducing multiple-way-of-doing-the-same-thing. I'm still astonished how much difficulty people are having with various ways of registering services in DI (.service, .factory, .value etc.).

But this is kind of secondary - the main issues are:

  • what distinct classes of directives we can see (regardless of their names)
  • what are the APIs proposed for those
  • how the proposed API differs from the existing one (conceptual difference and actual difference in the code)

I think that answering the above questions is more important that debating if we want to have it in core or not at this point. If we can clearly identify distinct concepts and find good API for those, I'm all for embedding this in AngularJS. So let's focus the discussion on the concrete proposals.

@ajoslin

This comment has been minimized.

Show comment
Hide comment
@ajoslin

ajoslin Mar 6, 2015

Contributor

I was trying to get from Angular 1's directive syntax to Angular 2's component syntax in a simple way. The best I could do was this:

app.directive('ngTrademark', function() {
  return {
    restrict: 'E',
    scope: {},
    controller: function() {},
    controllerAs: 'ngTrademark',
    bindToController: {
      version: '='  
    },
    template: 'The version is {{ngTrademark.version}}'
  };
});

This is way too verbose. How about some sugar that will set some defaults for us and pave the way for angular 2 migration:

app.component('ngTrademark', function() {
  return {
    bind: {
      version: '='
    },
    template: 'The version is {{ngTrademark.version}}'
  };
});

And then adding a custom controller for example's sake:

myModule.component('ngTrademark', function() {
  return {
    bind: {
      name: '&'
    },
    controller: TrademarkController,
    template: 'The version is {{ngTrademark.fancyVersion()}}'
  };
  function TrademarkController() {
     this.fancyVersion = function() {
       return '~~' + this.version + '~~';
     };
  }
});

And module.component simply maps to a directive with some overridable defaults:

{ 
  restrict: 'E', 
  controller: function() {}, 
  controllerAs: directiveName, 
  scope: {},
  bindToController: componentDef.bind
}

There could also be a similar function (module.decorator?) for attribute/decorator directives.

Thought of this at ng-conf with @pkozlowski-opensource, @CarmenPopoviciu and @mzgol.

Contributor

ajoslin commented Mar 6, 2015

I was trying to get from Angular 1's directive syntax to Angular 2's component syntax in a simple way. The best I could do was this:

app.directive('ngTrademark', function() {
  return {
    restrict: 'E',
    scope: {},
    controller: function() {},
    controllerAs: 'ngTrademark',
    bindToController: {
      version: '='  
    },
    template: 'The version is {{ngTrademark.version}}'
  };
});

This is way too verbose. How about some sugar that will set some defaults for us and pave the way for angular 2 migration:

app.component('ngTrademark', function() {
  return {
    bind: {
      version: '='
    },
    template: 'The version is {{ngTrademark.version}}'
  };
});

And then adding a custom controller for example's sake:

myModule.component('ngTrademark', function() {
  return {
    bind: {
      name: '&'
    },
    controller: TrademarkController,
    template: 'The version is {{ngTrademark.fancyVersion()}}'
  };
  function TrademarkController() {
     this.fancyVersion = function() {
       return '~~' + this.version + '~~';
     };
  }
});

And module.component simply maps to a directive with some overridable defaults:

{ 
  restrict: 'E', 
  controller: function() {}, 
  controllerAs: directiveName, 
  scope: {},
  bindToController: componentDef.bind
}

There could also be a similar function (module.decorator?) for attribute/decorator directives.

Thought of this at ng-conf with @pkozlowski-opensource, @CarmenPopoviciu and @mzgol.

@demisx

This comment has been minimized.

Show comment
Hide comment
@demisx

demisx Mar 6, 2015

👍 Nice. I like the bind syntax. The only thing I don't like naming it component. As I've mentioned earlier, all of our aps are divided into components and many of these components are a higher abstraction, then a single directive. We woudn't be able to keep 1-to-1 relationship between components and directives. Our components may or may not include directives and they usually include a bunch of other files, besides directives (e.g. services, providers, templates, configs - just about anything). If you called this a widget, then it may work.

Anyway, just wanted to add my 2 cents and my highly subjective opinion.

demisx commented Mar 6, 2015

👍 Nice. I like the bind syntax. The only thing I don't like naming it component. As I've mentioned earlier, all of our aps are divided into components and many of these components are a higher abstraction, then a single directive. We woudn't be able to keep 1-to-1 relationship between components and directives. Our components may or may not include directives and they usually include a bunch of other files, besides directives (e.g. services, providers, templates, configs - just about anything). If you called this a widget, then it may work.

Anyway, just wanted to add my 2 cents and my highly subjective opinion.

@kentcdodds

This comment has been minimized.

Show comment
Hide comment
@kentcdodds

kentcdodds Mar 6, 2015

Member

My alternative highly subjective opinion is I like the term component as I
think it maps well to what the JavaScript community at large is referring
to these things. React has components and there's Web Components. So I
prefer the name component.

  • Kent C. Dodds

(Sent from my mobile device, please forgive typos or brevity)
On Mar 5, 2015 11:31 PM, "Dmitri Moore" notifications@github.com wrote:

[image: 👍] Nice. I like the bind syntax. The only thing I don't like
naming it component. As I've mentioned earlier, all of our aps are
divided into components and many of these components are a higher
abstraction, then a single directive. We woudnt be able to keep 1-to-1
relationship between components and directives. Our components may or may
not include directives and they usually include a bunch of other files,
besides directives (e.g. services, providers, templates, configs - just
about anything). If you called this awidget`, then it may work.

Anyway, just wanted to add my 2 cents and my highly subjective opinion.


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

Member

kentcdodds commented Mar 6, 2015

My alternative highly subjective opinion is I like the term component as I
think it maps well to what the JavaScript community at large is referring
to these things. React has components and there's Web Components. So I
prefer the name component.

  • Kent C. Dodds

(Sent from my mobile device, please forgive typos or brevity)
On Mar 5, 2015 11:31 PM, "Dmitri Moore" notifications@github.com wrote:

[image: 👍] Nice. I like the bind syntax. The only thing I don't like
naming it component. As I've mentioned earlier, all of our aps are
divided into components and many of these components are a higher
abstraction, then a single directive. We woudnt be able to keep 1-to-1
relationship between components and directives. Our components may or may
not include directives and they usually include a bunch of other files,
besides directives (e.g. services, providers, templates, configs - just
about anything). If you called this awidget`, then it may work.

Anyway, just wanted to add my 2 cents and my highly subjective opinion.


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

@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Mar 6, 2015

Member

So, there are many "overloaded" words that we use in IT (module, package, component, widget, controller etc.). People use those words to mean different things and will have different mental models, so there will always difference in preferences here. So make the discussion more productive, here is my proposal:

  • let's say that we are going to stick to the same name as Angular2 is using (currently: component)
  • let's re-focus the discussion on the more important part: API and the semantic of this helper. As long as we've got API and semantics right, we can stick any name on it.

How does it sound?

So, there are many "overloaded" words that we use in IT (module, package, component, widget, controller etc.). People use those words to mean different things and will have different mental models, so there will always difference in preferences here. So make the discussion more productive, here is my proposal:

  • let's say that we are going to stick to the same name as Angular2 is using (currently: component)
  • let's re-focus the discussion on the more important part: API and the semantic of this helper. As long as we've got API and semantics right, we can stick any name on it.

How does it sound?

@timjacobi

This comment has been minimized.

Show comment
Hide comment
@timjacobi

timjacobi Jul 3, 2015

I don't like it, sorry. Why not use something that is similar to the directive syntax, just simplified. Makes it easier to recognize the pattern.

I don't like it, sorry. Why not use something that is similar to the directive syntax, just simplified. Makes it easier to recognize the pattern.

@ChristianKohler

This comment has been minimized.

Show comment
Hide comment
@ChristianKohler

ChristianKohler Jul 3, 2015

Contributor

Because we want to move away from the ddo syntax and move to a syntax closer to angular 2.

We'll always have the ddo syntax in Angular 1.x and it doesn't make much sense to just simplify the ddo which would make it only more complicated for beginners (like factory vs. service). The main reason imho for this feature is to align with angular 2.

I think most of the people would use it in combination with ES7/Typescript decorators which would make a component almost angular 1/2 agnostic :-)

Contributor

ChristianKohler commented Jul 3, 2015

Because we want to move away from the ddo syntax and move to a syntax closer to angular 2.

We'll always have the ddo syntax in Angular 1.x and it doesn't make much sense to just simplify the ddo which would make it only more complicated for beginners (like factory vs. service). The main reason imho for this feature is to align with angular 2.

I think most of the people would use it in combination with ES7/Typescript decorators which would make a component almost angular 1/2 agnostic :-)

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Jul 3, 2015

Contributor

well, you'd need the same decorators exposed by Angular2 for that, and who knows if those are going to change more than they already have or not. Matching the API 100% is very difficult because angular2 is still sort of in flux

Contributor

caitp commented Jul 3, 2015

well, you'd need the same decorators exposed by Angular2 for that, and who knows if those are going to change more than they already have or not. Matching the API 100% is very difficult because angular2 is still sort of in flux

@DavidSouther

This comment has been minimized.

Show comment
Hide comment
@DavidSouther

DavidSouther Jul 3, 2015

Contributor

@caitp it's looking less and less in flux every release. Exposing decorators with as similar an API as possible will ease migration. Though the decorators in 1.x should not land until after 2.0 has stabilized.

Contributor

DavidSouther commented Jul 3, 2015

@caitp it's looking less and less in flux every release. Exposing decorators with as similar an API as possible will ease migration. Though the decorators in 1.x should not land until after 2.0 has stabilized.

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Jul 3, 2015

Contributor

I'm skeptical, we've historically been pretty bad at api stability, but especially during the beta cycle I would not want to expose these

Contributor

caitp commented Jul 3, 2015

I'm skeptical, we've historically been pretty bad at api stability, but especially during the beta cycle I would not want to expose these

@pbastowski

This comment has been minimized.

Show comment
Hide comment
@pbastowski

pbastowski Jul 3, 2015

Guys, what do you think of decorator libraries, like my angular2-now library for Angular 1: https://github.com/pbastowski/angular2-now

It gives Angular 1the current Angular 2 component syntax, as shown below. Is this something that you would be interested in or am I completely off the topic here?

import {SetModule, Component, State, View, Inject, bootstrap, Filter, Options} from 'angular2now';

@State({ name: 'root', url: '', abstract: true, html5Mode: false })

@Component({ selector: 'my-app' })
@View({ templateUrl: 'client/app/app.html' })
@Inject(['$rootScope', '$state', '$location', 'helpers'])

class ftDesiree {
    constructor($rootScope, $state, $location, helpers) {
        ...
    }
}

Even if Angular 2 changes its API somewhat, this is still much nicer than the Angular 1 DDO, etc, right?

Guys, what do you think of decorator libraries, like my angular2-now library for Angular 1: https://github.com/pbastowski/angular2-now

It gives Angular 1the current Angular 2 component syntax, as shown below. Is this something that you would be interested in or am I completely off the topic here?

import {SetModule, Component, State, View, Inject, bootstrap, Filter, Options} from 'angular2now';

@State({ name: 'root', url: '', abstract: true, html5Mode: false })

@Component({ selector: 'my-app' })
@View({ templateUrl: 'client/app/app.html' })
@Inject(['$rootScope', '$state', '$location', 'helpers'])

class ftDesiree {
    constructor($rootScope, $state, $location, helpers) {
        ...
    }
}

Even if Angular 2 changes its API somewhat, this is still much nicer than the Angular 1 DDO, etc, right?

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Jul 3, 2015

Contributor

it's pretty much identical to the DDO when you get down to it

Contributor

caitp commented Jul 3, 2015

it's pretty much identical to the DDO when you get down to it

@pbastowski

This comment has been minimized.

Show comment
Hide comment
@pbastowski

pbastowski Jul 3, 2015

Along the same lines of thinking, it's also pretty much identical to Angular 2 as it currently stands.

So, are we looking for something much simpler than this even?

Along the same lines of thinking, it's also pretty much identical to Angular 2 as it currently stands.

So, are we looking for something much simpler than this even?

@awerlang

This comment has been minimized.

Show comment
Hide comment
@awerlang

awerlang Jul 3, 2015

I don't believe in something being new/different as to being nicer.

Shall we rewrite our directives to be more Angular2-like so we'll have a little less work when/if (emphasis on if) porting to the some future major release? Do we have any garantees of that work? Is this an effort we wish to be in? Shall this in any case put a constraint in Angular2 design?

As a sidenote, angularjs.org still doesn't feature controllerAs, will it feature a new syntax to something that can be achieved already?

Just take the best out of Angular 1 while you can. Stop trying to fulfill your programmers' egos, many trying to market your own extension, no one really willing to join efforts, e.g. as soon as Angular2 gets out, all these are past.

Didn't want to look harsh, no offence intended in case you feel like that.

awerlang commented Jul 3, 2015

I don't believe in something being new/different as to being nicer.

Shall we rewrite our directives to be more Angular2-like so we'll have a little less work when/if (emphasis on if) porting to the some future major release? Do we have any garantees of that work? Is this an effort we wish to be in? Shall this in any case put a constraint in Angular2 design?

As a sidenote, angularjs.org still doesn't feature controllerAs, will it feature a new syntax to something that can be achieved already?

Just take the best out of Angular 1 while you can. Stop trying to fulfill your programmers' egos, many trying to market your own extension, no one really willing to join efforts, e.g. as soon as Angular2 gets out, all these are past.

Didn't want to look harsh, no offence intended in case you feel like that.

@pbastowski

This comment has been minimized.

Show comment
Hide comment
@pbastowski

pbastowski Jul 3, 2015

@awerlang No offence :) There is nothing wrong with Angular 1 syntax. If you like it then keep on using it.

However, these are not dreams or egos. My team is using the decorator library for developing production apps for our customer. There are several other libraries that do the same or similar job and some of them are also used by various people for building production systems.

It's good to have choice ;)

@awerlang No offence :) There is nothing wrong with Angular 1 syntax. If you like it then keep on using it.

However, these are not dreams or egos. My team is using the decorator library for developing production apps for our customer. There are several other libraries that do the same or similar job and some of them are also used by various people for building production systems.

It's good to have choice ;)

@caitp

This comment has been minimized.

Show comment
Hide comment
@caitp

caitp Jul 3, 2015

Contributor

arguably, it's actually not very good to have a choice. It creates multiple ways to do a given thing, and that's generally not very good for an API (leads to confusion). This is a problem with the angular.component helper itself, but I think we've sort of let it slide this time? The point of the angular.component helper isn't really a "make migration to angular2 easier" or "make angular1 look like angular2" --- it's really just for making the common use case that a lot of people following john papa's style a lot easier to write.

We've discussed this, and we don't actually want to make angular1 look like angular2, because this will effectively make migration more difficult, not easier. The approach we're leaning on for migration right now is to support running angular1 stuff in angular2, and vice versa (I do not speak for Herr AngularTeam, but this is basically the conclusion you get from reading the plans)

Contributor

caitp commented Jul 3, 2015

arguably, it's actually not very good to have a choice. It creates multiple ways to do a given thing, and that's generally not very good for an API (leads to confusion). This is a problem with the angular.component helper itself, but I think we've sort of let it slide this time? The point of the angular.component helper isn't really a "make migration to angular2 easier" or "make angular1 look like angular2" --- it's really just for making the common use case that a lot of people following john papa's style a lot easier to write.

We've discussed this, and we don't actually want to make angular1 look like angular2, because this will effectively make migration more difficult, not easier. The approach we're leaning on for migration right now is to support running angular1 stuff in angular2, and vice versa (I do not speak for Herr AngularTeam, but this is basically the conclusion you get from reading the plans)

@pbastowski

This comment has been minimized.

Show comment
Hide comment
@pbastowski

pbastowski Jul 3, 2015

@caitp Ok. Good to know.

@caitp Ok. Good to know.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Jul 3, 2015

Member

Thanks everyone who is showing an interest in this issue. We are keen to get some form of this into Angular 1.5. As is pointed out, the primary reason is to make it easier to write the most common form of directive; but there are some upgrade side-effects too.

This component style of writing directives is certainly closer conceptually to components in Angular 2, and while I am totally in agreement that we should not be trying to sugar the Angular 1 syntax to make it look superficially like that of Angular 2 the benefits of writing components in this way will lead to easier maintenance and cleaner code.

It is worth linking in here the team's document on proposed 1->2 upgrade strategies.
https://docs.google.com/document/d/1xvBZoFuNq9hsgRhPPZOJC-Z48AHEbIBPlOCBTSD8m0Y/edit
This is still a WIP progress but you can see the directions that we are considering. Feel free to comment if you would like to contribute to the discussion.

Member

petebacondarwin commented Jul 3, 2015

Thanks everyone who is showing an interest in this issue. We are keen to get some form of this into Angular 1.5. As is pointed out, the primary reason is to make it easier to write the most common form of directive; but there are some upgrade side-effects too.

This component style of writing directives is certainly closer conceptually to components in Angular 2, and while I am totally in agreement that we should not be trying to sugar the Angular 1 syntax to make it look superficially like that of Angular 2 the benefits of writing components in this way will lead to easier maintenance and cleaner code.

It is worth linking in here the team's document on proposed 1->2 upgrade strategies.
https://docs.google.com/document/d/1xvBZoFuNq9hsgRhPPZOJC-Z48AHEbIBPlOCBTSD8m0Y/edit
This is still a WIP progress but you can see the directions that we are considering. Feel free to comment if you would like to contribute to the discussion.

@orizens

This comment has been minimized.

Show comment
Hide comment
@orizens

orizens Aug 23, 2015

hi.
I just saw this thread.
a couple of months ago, after reading pascal precht post about using angular 2 with ES5, I created angular2to1 npm module in order to experiment with the new component syntax.
Up to now, I implemented some of these annotations: Component, View, Class in its simple form. Still, a lot of work to do, however, it gave me the oppoertunity to explore some of angular 2 syntax and concepts whle working in angular 1.
Currently, I'm using it in my open source project Echoes Player, i.e in the "youtube-videos" component.
Do you think (as i do) that its a module that will give benefits to others?

orizens commented Aug 23, 2015

hi.
I just saw this thread.
a couple of months ago, after reading pascal precht post about using angular 2 with ES5, I created angular2to1 npm module in order to experiment with the new component syntax.
Up to now, I implemented some of these annotations: Component, View, Class in its simple form. Still, a lot of work to do, however, it gave me the oppoertunity to explore some of angular 2 syntax and concepts whle working in angular 1.
Currently, I'm using it in my open source project Echoes Player, i.e in the "youtube-videos" component.
Do you think (as i do) that its a module that will give benefits to others?

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Aug 24, 2015

Member

@orizens You should be getting involved with https://github.com/ngUpgraders. This is the team that are working towards a single solution for this, which has the approval of the Angular team.

Member

petebacondarwin commented Aug 24, 2015

@orizens You should be getting involved with https://github.com/ngUpgraders. This is the team that are working towards a single solution for this, which has the approval of the Angular team.

@shairez

This comment has been minimized.

Show comment
Hide comment
@shairez

shairez Dec 22, 2015

Contributor

Sorry to nudge in with yet another question -

The problem I run into when writing lots of "component like" directives is the unnecessarily repeated configuration over and over again.

The first being the .controller registration by name, and the second one being the controllerAs as "vm".

Registering controllers

Registering controllers by name in a component based architecture is useful only for unit tests, where you'd want to use $controller to create an instance of the component's controller.

But registering it over and over again is redundant and can be done by the .component.

controllerAs

The controllerAs: "vm" is the best practice AFAIK and I think it should be the default moving forward, you can always override it.

Maybe we should add an "opt in" configuration for people who want to use a default "controllerAs", because adding it for every component is very annoying.

Example

So we should end up with something where the .component becomes a true "annotation like" thing, something like:

angular
 .module('myModule')
 .component('myComp', {
   controller: MyCompController,
   templateUrl: 'my-comp.html'
  })

function MyCompController(){

}

$controller('myComp') // <-- should be an instance of MyCompController

And we could refer to our component as "vm" in our templates.

I'd love to hear what you think about it and what are the cons of this approach

Contributor

shairez commented Dec 22, 2015

Sorry to nudge in with yet another question -

The problem I run into when writing lots of "component like" directives is the unnecessarily repeated configuration over and over again.

The first being the .controller registration by name, and the second one being the controllerAs as "vm".

Registering controllers

Registering controllers by name in a component based architecture is useful only for unit tests, where you'd want to use $controller to create an instance of the component's controller.

But registering it over and over again is redundant and can be done by the .component.

controllerAs

The controllerAs: "vm" is the best practice AFAIK and I think it should be the default moving forward, you can always override it.

Maybe we should add an "opt in" configuration for people who want to use a default "controllerAs", because adding it for every component is very annoying.

Example

So we should end up with something where the .component becomes a true "annotation like" thing, something like:

angular
 .module('myModule')
 .component('myComp', {
   controller: MyCompController,
   templateUrl: 'my-comp.html'
  })

function MyCompController(){

}

$controller('myComp') // <-- should be an instance of MyCompController

And we could refer to our component as "vm" in our templates.

I'd love to hear what you think about it and what are the cons of this approach

@wesleycho

This comment has been minimized.

Show comment
Hide comment
@wesleycho

wesleycho Dec 22, 2015

Contributor

I absolutely would not want to see controllerAs: vm as default, and would be very unhappy if that were the case, as would a lot of the angular community as well that I interact with daily - as far as I've seen, controllerAs: vm is divisive, and IMO, far from a best practice.

Anyhow, such a feature request probably should belong in a separate issue rather than clutter up this one.

Contributor

wesleycho commented Dec 22, 2015

I absolutely would not want to see controllerAs: vm as default, and would be very unhappy if that were the case, as would a lot of the angular community as well that I interact with daily - as far as I've seen, controllerAs: vm is divisive, and IMO, far from a best practice.

Anyhow, such a feature request probably should belong in a separate issue rather than clutter up this one.

@shahata

This comment has been minimized.

Show comment
Hide comment
@shahata

shahata Dec 22, 2015

Contributor

@shairez I think you are saying two things:

  1. controllerAs should default to vm and not to component name - I agree that defaulting to component name might not be the correct thing to do. It would be easier for people to always use the same name unless they need to reference different controllers in the template, which is where they would configure a custom controllerAs. We are already discussing this and will probably default to $ctrl.
  2. there should be an easy way to get the controller of a component for unit tests - $controller('myComp'). That's a nice idea. For ES6 apps you can actually do something like $controller(MyCompController) but I understand how in ES5 apps you wouldn't want to put MyCompController on the global namespace. @petebacondarwin WDYT?
Contributor

shahata commented Dec 22, 2015

@shairez I think you are saying two things:

  1. controllerAs should default to vm and not to component name - I agree that defaulting to component name might not be the correct thing to do. It would be easier for people to always use the same name unless they need to reference different controllers in the template, which is where they would configure a custom controllerAs. We are already discussing this and will probably default to $ctrl.
  2. there should be an easy way to get the controller of a component for unit tests - $controller('myComp'). That's a nice idea. For ES6 apps you can actually do something like $controller(MyCompController) but I understand how in ES5 apps you wouldn't want to put MyCompController on the global namespace. @petebacondarwin WDYT?
@Narretz

This comment has been minimized.

Show comment
Hide comment
@Narretz

Narretz Dec 22, 2015

Contributor

We've talked about the default controllerAs name and we will probably
change it before 1.5. We're just not sure what it'll be and we're going to
be open for suggestions.
Am 22.12.2015 20:34 schrieb "Shahar Talmi" notifications@github.com:

@shairez https://github.com/shairez I think you are saying two things:

  1. controllerAs should default to vm and not to component name - I
    agree that defaulting to component name might not be the correct thing to
    do. It would be easier for people to always use the same name unless they
    need to reference different controllers in the template, which is where
    they would configure a custom controllerAs. We are already discussing
    and will probably default to $ctrl.
  2. there should be an easy way to get the controller of a component
    for unit tests - $controller('myComp'). That's a nice idea. For ES6
    apps you can actually do something like $controller(MyCompController)
    but I understand how in ES5 apps you wouldn't want to put
    MyCompController on the global namespace. @petebacondarwin
    https://github.com/petebacondarwin WDYT?


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

Contributor

Narretz commented Dec 22, 2015

We've talked about the default controllerAs name and we will probably
change it before 1.5. We're just not sure what it'll be and we're going to
be open for suggestions.
Am 22.12.2015 20:34 schrieb "Shahar Talmi" notifications@github.com:

@shairez https://github.com/shairez I think you are saying two things:

  1. controllerAs should default to vm and not to component name - I
    agree that defaulting to component name might not be the correct thing to
    do. It would be easier for people to always use the same name unless they
    need to reference different controllers in the template, which is where
    they would configure a custom controllerAs. We are already discussing
    and will probably default to $ctrl.
  2. there should be an easy way to get the controller of a component
    for unit tests - $controller('myComp'). That's a nice idea. For ES6
    apps you can actually do something like $controller(MyCompController)
    but I understand how in ES5 apps you wouldn't want to put
    MyCompController on the global namespace. @petebacondarwin
    https://github.com/petebacondarwin WDYT?


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

@shairez

This comment has been minimized.

Show comment
Hide comment
@shairez

shairez Dec 22, 2015

Contributor

@wesleycho you're right, I should have probably opened up 2 separate issues for these questions, there is a nicer way of suggesting it though.

@shahata @Narretz thanks for the comments, let me know if there is another open issue for the discussion of the consistent controllerAs name (couldn't find it), I'd love to help!

About the controller registration, I'm also waiting for @petebacondarwin response, and then we can decide whether to open up a new issue for that as well. (I will also submit a PR if we'll agree it's a good addition)

Thanks!

Contributor

shairez commented Dec 22, 2015

@wesleycho you're right, I should have probably opened up 2 separate issues for these questions, there is a nicer way of suggesting it though.

@shahata @Narretz thanks for the comments, let me know if there is another open issue for the discussion of the consistent controllerAs name (couldn't find it), I'd love to help!

About the controller registration, I'm also waiting for @petebacondarwin response, and then we can decide whether to open up a new issue for that as well. (I will also submit a PR if we'll agree it's a good addition)

Thanks!

@drpicox

This comment has been minimized.

Show comment
Hide comment
@drpicox

drpicox Dec 23, 2015

Contributor

+1 to controllerAs: 'vm' as default, and my reason is the following:

If all directives have the same controller name you can leverage on that:

<my-logic-toggle as="someToggle"></my-logic-toggle>
<some-content ng-show="vm.someToggle.opened></some-content>

or

<button ng-click="vm.pager.first()">First</button>
<my-pager as="pager" elements="element as vm.elements">
  <my-element element="element"></my-element>
</my-pager>
<button ng-click="vm.pager.next()">Next</button>

or

<button ng-click="vm.play()">Play</button>
<audio as="audio">
    <source src="some.mp3" type="audio/mpeg">
</audio>

and controller contains (it requires a controller because Angular forbids use DOM objects in template expressions):

vm.play = function() {
  vm.audio.play();
};

It assigns it inside vm because it is a variable for all template, it does not matters about scopes in the same template. But I have to confess that I have a second one directive to connect things inside scopes (for example inside an ng-repeat).
Anyway, it is very handy to connect component controllers just like that, ng2 introduces it but we can use it in ng1 (I'm doing it since 1.2).

Btw: it can be vm, or ctr, or anyother else, but it should be always the same name, short to save some bytes, if possible

Contributor

drpicox commented Dec 23, 2015

+1 to controllerAs: 'vm' as default, and my reason is the following:

If all directives have the same controller name you can leverage on that:

<my-logic-toggle as="someToggle"></my-logic-toggle>
<some-content ng-show="vm.someToggle.opened></some-content>

or

<button ng-click="vm.pager.first()">First</button>
<my-pager as="pager" elements="element as vm.elements">
  <my-element element="element"></my-element>
</my-pager>
<button ng-click="vm.pager.next()">Next</button>

or

<button ng-click="vm.play()">Play</button>
<audio as="audio">
    <source src="some.mp3" type="audio/mpeg">
</audio>

and controller contains (it requires a controller because Angular forbids use DOM objects in template expressions):

vm.play = function() {
  vm.audio.play();
};

It assigns it inside vm because it is a variable for all template, it does not matters about scopes in the same template. But I have to confess that I have a second one directive to connect things inside scopes (for example inside an ng-repeat).
Anyway, it is very handy to connect component controllers just like that, ng2 introduces it but we can use it in ng1 (I'm doing it since 1.2).

Btw: it can be vm, or ctr, or anyother else, but it should be always the same name, short to save some bytes, if possible

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Jan 2, 2016

Member

@drpicox - I am not convinced that your suggestions are a good idea, if I understand it right.
I think you are saying that these snippets would be contained within a component that has a controller and that this controller would be attached to the scope as vm, right?

That is OK but I don't like that you are making that assumption for your custom directives, such as my-logic-toggle. This is brittle, since it is always possible that someone might choose to name their controller something else, overriding the default of vm or whatever it is. Moreover it is inconsistent, since you have one bit of template referring to something simply as someToggle and another bit referring to it as vm.someToggle.

I would be more comfortable if the as attribute referenced the controller explicitly...

<my-logic-toggle as="vm.someToggle"></my-logic-toggle>
<some-content ng-show="vm.someToggle.opened></some-content>

in which case this particular argument to have a consistent naming is no longer necessary.


That being said, I still do think that we need a consistent naming for directive controllers that are made available on the scope; just not for the reason given.

Member

petebacondarwin commented Jan 2, 2016

@drpicox - I am not convinced that your suggestions are a good idea, if I understand it right.
I think you are saying that these snippets would be contained within a component that has a controller and that this controller would be attached to the scope as vm, right?

That is OK but I don't like that you are making that assumption for your custom directives, such as my-logic-toggle. This is brittle, since it is always possible that someone might choose to name their controller something else, overriding the default of vm or whatever it is. Moreover it is inconsistent, since you have one bit of template referring to something simply as someToggle and another bit referring to it as vm.someToggle.

I would be more comfortable if the as attribute referenced the controller explicitly...

<my-logic-toggle as="vm.someToggle"></my-logic-toggle>
<some-content ng-show="vm.someToggle.opened></some-content>

in which case this particular argument to have a consistent naming is no longer necessary.


That being said, I still do think that we need a consistent naming for directive controllers that are made available on the scope; just not for the reason given.

@petebacondarwin

This comment has been minimized.

Show comment
Hide comment
@petebacondarwin

petebacondarwin Jan 2, 2016

Member

I made a new issue #13664

Member

petebacondarwin commented Jan 2, 2016

I made a new issue #13664

@drpicox

This comment has been minimized.

Show comment
Hide comment
@drpicox

drpicox Jan 2, 2016

Contributor

@petebacondarwin You're right and I agree.

Also about being explicit, thanks, I'll introduce it.
I missed it because I was more concerned in performance than expressivity, implicit version of vm there is no need for $parse.

Contributor

drpicox commented Jan 2, 2016

@petebacondarwin You're right and I agree.

Also about being explicit, thanks, I'll introduce it.
I missed it because I was more concerned in performance than expressivity, implicit version of vm there is no need for $parse.

@shairez

This comment has been minimized.

Show comment
Hide comment
@shairez

shairez Jan 6, 2016

Contributor

As for the second point I raised - auto creating a controller - I've opened up a separate issue #13683

let me know what you think

Contributor

shairez commented Jan 6, 2016

As for the second point I raised - auto creating a controller - I've opened up a separate issue #13683

let me know what you think

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment