feat(core): renames Property into Input and Event into Output #4435

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
@vsavkin
Contributor

vsavkin commented Sep 30, 2015

BREACKING CHANGE:

Before: @directive({properties: ['one'], events: ['two']})
After: @directive({inputs: ['one'], outputs: ['two']})

Before: @component({properties: ['one'], events: ['two']})
After: @componet({inputs: ['one'], outputs: ['two']})

Before: class A {@Property() one; @event() two;}
After: class A {@input() one; @output() two;}

@vicb

This comment has been minimized.

Show comment
Hide comment
@vicb

vicb Sep 30, 2015

Member

@vsavkin could you give more context about this change ?

Input/Output sounds kind of similar (well opposite) while Property/Event do a better job at denoting the difference (you subscribe to an Event vs set a Property).

Member

vicb commented Sep 30, 2015

@vsavkin could you give more context about this change ?

Input/Output sounds kind of similar (well opposite) while Property/Event do a better job at denoting the difference (you subscribe to an Event vs set a Property).

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Sep 30, 2015

Member

@vicb this was discussed in the office (sorry we did not include you) and we decided that this naming is the most consistent. Would be happy to discuss any questions about it which you may have.

Member

mhevery commented Sep 30, 2015

@vicb this was discussed in the office (sorry we did not include you) and we decided that this naming is the most consistent. Would be happy to discuss any questions about it which you may have.

@mhevery mhevery assigned vsavkin and unassigned mhevery Sep 30, 2015

@tbosch

This comment has been minimized.

Show comment
Hide comment
@tbosch

tbosch Oct 1, 2015

Member

Victor, could you wait before merging this for my PR of the new compiler?
Will land tomorrow...
On Wed, Sep 30, 2015 at 3:44 PM Miško Hevery notifications@github.com
wrote:

@vicb https://github.com/vicb this was discussed in the office (sorry
we did not include you) and we decided that this naming is the most
consistent. Would be happy to discuss any questions about it which you may
have.


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

Member

tbosch commented Oct 1, 2015

Victor, could you wait before merging this for my PR of the new compiler?
Will land tomorrow...
On Wed, Sep 30, 2015 at 3:44 PM Miško Hevery notifications@github.com
wrote:

@vicb https://github.com/vicb this was discussed in the office (sorry
we did not include you) and we decided that this naming is the most
consistent. Would be happy to discuss any questions about it which you may
have.


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

@mary-poppins

This comment has been minimized.

Show comment
Hide comment
@mary-poppins

mary-poppins Oct 1, 2015

Merging PR #4435 on behalf of @vsavkin to branch presubmit-vsavkin-pr-4435.

Merging PR #4435 on behalf of @vsavkin to branch presubmit-vsavkin-pr-4435.

feat(core): renames Property into Input and Event into Output
BREACKING CHANGE:

Before: @directive({properties: ['one'], events: ['two']})
After: @directive({inputs: ['one'], outputs: ['two']})

Before: @component({properties: ['one'], events: ['two']})
After: @componet({inputs: ['one'], outputs: ['two']})

Before: class A {@Property() one; @event() two;}
After: class A {@input() one; @output() two;}
@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

Hmm, this is just my two cents and you might have thought about that for longer, but my whole office was just like WTF, when we looked at that PR... I really liked, that you were embracing that standard web syntax, with using DOM Properties and Events - that was, what the old syntax was all about. Input & Output to me, sound not intuitive for an usual webdeveloper at all... IMHO this change adds another layer of mental translation when talking about component interfaces...

Contributor

choeller commented Oct 1, 2015

Hmm, this is just my two cents and you might have thought about that for longer, but my whole office was just like WTF, when we looked at that PR... I really liked, that you were embracing that standard web syntax, with using DOM Properties and Events - that was, what the old syntax was all about. Input & Output to me, sound not intuitive for an usual webdeveloper at all... IMHO this change adds another layer of mental translation when talking about component interfaces...

@tapas4java

This comment has been minimized.

Show comment
Hide comment
@tapas4java

tapas4java Oct 1, 2015

Properties and Events are more contextual and better fit to web concepts
than Input/Output. What was wrong with them?
On 1 Oct 2015 13:25, "choeller" notifications@github.com wrote:

Hmm, this is just my two cents and you might have thought about that for
longer, but my whole office was just WTF, when we looked at that PR... I
really liked, that you were embracing that standard web syntax, with using
DOM Properties and Events - that was, what the old syntax was all about.
Input & Output to me, sound not intuitive for an usual webdeveloper at
all...


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

Properties and Events are more contextual and better fit to web concepts
than Input/Output. What was wrong with them?
On 1 Oct 2015 13:25, "choeller" notifications@github.com wrote:

Hmm, this is just my two cents and you might have thought about that for
longer, but my whole office was just WTF, when we looked at that PR... I
really liked, that you were embracing that standard web syntax, with using
DOM Properties and Events - that was, what the old syntax was all about.
Input & Output to me, sound not intuitive for an usual webdeveloper at
all...


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

@PascalPrecht

This comment has been minimized.

Show comment
Hide comment
@PascalPrecht

PascalPrecht Oct 1, 2015

Contributor

I think we should really wait for an offical statement here that explains
the reasoning behind this change. @mhevery properties/events where
consistent too, could you elaborate on this change?

What was the problem with the former ones?

On Thu, Oct 1, 2015, 8:14 AM Tapas Jena notifications@github.com wrote:

Properties and Events are more contextual and better fit to web concepts
than Input/Output. What was wrong with them?
On 1 Oct 2015 13:25, "choeller" notifications@github.com wrote:

Hmm, this is just my two cents and you might have thought about that for
longer, but my whole office was just WTF, when we looked at that PR... I
really liked, that you were embracing that standard web syntax, with
using
DOM Properties and Events - that was, what the old syntax was all about.
Input & Output to me, sound not intuitive for an usual webdeveloper at
all...


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


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

Contributor

PascalPrecht commented Oct 1, 2015

I think we should really wait for an offical statement here that explains
the reasoning behind this change. @mhevery properties/events where
consistent too, could you elaborate on this change?

What was the problem with the former ones?

On Thu, Oct 1, 2015, 8:14 AM Tapas Jena notifications@github.com wrote:

Properties and Events are more contextual and better fit to web concepts
than Input/Output. What was wrong with them?
On 1 Oct 2015 13:25, "choeller" notifications@github.com wrote:

Hmm, this is just my two cents and you might have thought about that for
longer, but my whole office was just WTF, when we looked at that PR... I
really liked, that you were embracing that standard web syntax, with
using
DOM Properties and Events - that was, what the old syntax was all about.
Input & Output to me, sound not intuitive for an usual webdeveloper at
all...


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


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

@TommyM

This comment has been minimized.

Show comment
Hide comment
@TommyM

TommyM Oct 1, 2015

I have to agree that this change might make things more confusing. Property and Event are very clear to anyone who has ever developed a web application.

TommyM commented Oct 1, 2015

I have to agree that this change might make things more confusing. Property and Event are very clear to anyone who has ever developed a web application.

@PascalPrecht

This comment has been minimized.

Show comment
Hide comment
@PascalPrecht

PascalPrecht Oct 1, 2015

Contributor

Again, please stop saying that things don't make sense unless we know what the actual reasoning behind this change is. I'm very sure that @vsavkin @mhevery etc. are very aware of the fact that this naming feels far away from what we would expect, but they surely don't introduce such a change without trying to make things better. Hold your horses.

Contributor

PascalPrecht commented Oct 1, 2015

Again, please stop saying that things don't make sense unless we know what the actual reasoning behind this change is. I'm very sure that @vsavkin @mhevery etc. are very aware of the fact that this naming feels far away from what we would expect, but they surely don't introduce such a change without trying to make things better. Hold your horses.

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

@PascalPrecht AFAIK this place and the gitter chat are the only chances to express our thoughts about changes. In this special case all we were saying, is that the new syntax seems to be counterintuitive to us not that the change did not make sense - so IMHO it's the right place and time to express that ;)

Contributor

choeller commented Oct 1, 2015

@PascalPrecht AFAIK this place and the gitter chat are the only chances to express our thoughts about changes. In this special case all we were saying, is that the new syntax seems to be counterintuitive to us not that the change did not make sense - so IMHO it's the right place and time to express that ;)

@PascalPrecht

This comment has been minimized.

Show comment
Hide comment
@PascalPrecht

PascalPrecht Oct 1, 2015

Contributor

I have to agree that this change does not make sense

^ @choeller

Anyways, let's see what the core team has to say about it. We probably don't think broad enough about it. A2 runs in WW environments and servers, maybe properties and events don't fit there anymore..

Contributor

PascalPrecht commented Oct 1, 2015

I have to agree that this change does not make sense

^ @choeller

Anyways, let's see what the core team has to say about it. We probably don't think broad enough about it. A2 runs in WW environments and servers, maybe properties and events don't fit there anymore..

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

@PascalPrecht eh, ok - I don't see that anywhere... so maybe it was edited or deleted...

Contributor

choeller commented Oct 1, 2015

@PascalPrecht eh, ok - I don't see that anywhere... so maybe it was edited or deleted...

@TommyM

This comment has been minimized.

Show comment
Hide comment
@TommyM

TommyM Oct 1, 2015

@PascalPrecht @choeller I did edit my post since I agree with @PascalPrecht that the wording I chose was not helpful and I did not want to add more noise to the thread... (Like I am doing now) "Does not make sense" is non-constructive so I changed it to "might make things more confusing". Should have made a note of that in the edited post...

Let's just wait and see what the reasoning behind the change is, and hold our horses till then ;)

TommyM commented Oct 1, 2015

@PascalPrecht @choeller I did edit my post since I agree with @PascalPrecht that the wording I chose was not helpful and I did not want to add more noise to the thread... (Like I am doing now) "Does not make sense" is non-constructive so I changed it to "might make things more confusing". Should have made a note of that in the edited post...

Let's just wait and see what the reasoning behind the change is, and hold our horses till then ;)

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

@PascalPrecht Yes for sure - I'm definetely also curious about the reasons.

Just let me explain whats lets me feel bad about this change. IMO it adds just another naming for the same UI Syntax/Concept. So when talking about build in HTML Elements we would still talk about property bindings and event bindings - as those are DOM properties and DOM events. Like:

<input type="text" #query (keyup)="search(query.value)" />

or

<img [src]="user.img"/>

Now when talking about a custom component build by the developer, we would do the UI-Binding exactly the same:

<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

Only in this case, we would now call it input-binding. or output-binding .I really feel that this is just not intuitive to the developer. But still I'm curious about the thoughts of @vsavkin and @mhevery

Contributor

choeller commented Oct 1, 2015

@PascalPrecht Yes for sure - I'm definetely also curious about the reasons.

Just let me explain whats lets me feel bad about this change. IMO it adds just another naming for the same UI Syntax/Concept. So when talking about build in HTML Elements we would still talk about property bindings and event bindings - as those are DOM properties and DOM events. Like:

<input type="text" #query (keyup)="search(query.value)" />

or

<img [src]="user.img"/>

Now when talking about a custom component build by the developer, we would do the UI-Binding exactly the same:

<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

Only in this case, we would now call it input-binding. or output-binding .I really feel that this is just not intuitive to the developer. But still I'm curious about the thoughts of @vsavkin and @mhevery

@endash

This comment has been minimized.

Show comment
Hide comment
@endash

endash Oct 1, 2015

From the perspective of a new Angular2 user: I believe this change is overly reductive and removes valuable semantics that help developers reason about their components, as well as place their behaviour within the broader context of their experience and history as programmers. A systems engineer might discuss the human digestive system using the words "input" and "output", and be correct for his/her purposes and uses, but from biologist on up to user those words are inappropriately reductive and confusing, given the lack of specificity; the broad, general nature of the terms; and—most of all—the ready availability of context-specific alternatives. I say the same applies, here. When "component inputs and outputs" could just as easily describe a stereo system as the core parts of your app, there's a semantics problem.

More concretely, the word "output" is just wrong, in this context: events, as used by the developer, describe the effects of a component, not an outputted value/entity/datum. One of the effects of a component is an event, which has some logic attached to it by the containing component. It's a category error akin to asking someone to "install some gasoline" into your car. Unless something else has changed, they really are not symmetric and do not comport with the common understanding of the meaning of the terms.

endash commented Oct 1, 2015

From the perspective of a new Angular2 user: I believe this change is overly reductive and removes valuable semantics that help developers reason about their components, as well as place their behaviour within the broader context of their experience and history as programmers. A systems engineer might discuss the human digestive system using the words "input" and "output", and be correct for his/her purposes and uses, but from biologist on up to user those words are inappropriately reductive and confusing, given the lack of specificity; the broad, general nature of the terms; and—most of all—the ready availability of context-specific alternatives. I say the same applies, here. When "component inputs and outputs" could just as easily describe a stereo system as the core parts of your app, there's a semantics problem.

More concretely, the word "output" is just wrong, in this context: events, as used by the developer, describe the effects of a component, not an outputted value/entity/datum. One of the effects of a component is an event, which has some logic attached to it by the containing component. It's a category error akin to asking someone to "install some gasoline" into your car. Unless something else has changed, they really are not symmetric and do not comport with the common understanding of the meaning of the terms.

Fank referenced this pull request Oct 1, 2015

feat(core): renames Property into Input and Event into Output
BREACKING CHANGE:

Before: @directive({properties: ['one'], events: ['two']})
After: @directive({inputs: ['one'], outputs: ['two']})

Before: @component({properties: ['one'], events: ['two']})
After: @componet({inputs: ['one'], outputs: ['two']})

Before: class A {@Property() one; @event() two;}
After: class A {@input() one; @output() two;}
@johnpapa

This comment has been minimized.

Show comment
Hide comment
@johnpapa

johnpapa Oct 1, 2015

Contributor

+1 for hearing details on why this was done, so we can all understand

Contributor

johnpapa commented Oct 1, 2015

+1 for hearing details on why this was done, so we can all understand

@NathanWalker

This comment has been minimized.

Show comment
Hide comment
@NathanWalker

NathanWalker Oct 1, 2015

Contributor

If this change goes in, then EventEmitter must be renamed to OutputEmitter :/

Contributor

NathanWalker commented Oct 1, 2015

If this change goes in, then EventEmitter must be renamed to OutputEmitter :/

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 1, 2015

Member

OK, let me take a crack of explaining the reasoning. :-)

The issue is that word @Property and @Event are two vague. Let's look at an example.

@Component({
  selector: 'pane'
  properties: ['title'],
  events: ['close']
})
@View({
  template: '<div class={{color}}>{{title}}</div>'
}) 
class Pane {
  @Property() title: string;
  color: string;
  @Event() close = new EventEmitter();
}

All title, color, and close are properties on the Pane class. So calling title as @Property is confusing, as from the OO perspective all three are properties or fields. We could call it a PropertyBinding but that would not be correct. Since we are declaring that a particular property can be bound to externally, not that there is a binding. (We can and do bind to color in our template) For example:

<pane title="My Pane">

Does not have any bindings. We simply initialize the title property with MyPane string literal. So it is not a binding.

A better thing would be to call title as @Public to say that it is part of the external API.

<pane title="My Pane" color="blue">

here title is to be bound to title property, but not color since the component treats color as an implementation detail. The issue with @Public is that in OO visibility has clear meaning on public, and all properties are public even color and close.

We could call it @Binding but that is not right, since we are not declaring a binding, only a location where value is stored. There may or may not be a binding but that is controlled by the template. Furthermore, it would make it seems as color did not have binding, but that is not true since the view does bind to color.

Ok, so now @Property, @Binding, @Public is out. What should we call it? Well if you step back, and go to our DAG goal, you realize that title is a place where data comes in from the outside world. It is what allows propagation of data from the root of the application down to the leafs. It is a property on a component which can accept external data. Not only it is where the data is accepted, it is clearly unidirectional. The words which come to bind are input or import. Import sounds like an action, so it is out. So we are left with input. If you think of component as a device in your HiFi stereo, then you are declaring where the information comes in hence the @Input Data shows up here. You don't control how it shows up, it just does.

Now if you think about @Event the issue is that it is not clear if you are asking to be notified of an event or if you will be firing an event. Furthermore you are not firing an event, rather you are pushing data into a stream. Again when you step back you realize that events are the only way to get the data out of the component, hence it is @Output.

When you have a DAG, inputs allow you to get data from the root component to the leafs, whereas outputs allow you to flow the data from the leafs to the root component.

Imagine you have an app such as this:

      -> Navigation   -> UserProfile
     /              /
App----> MainPane ----> DetailsView
     \
      -> Status

---> Input
<--- Output

This app is strictly DAG. So how is data supposed to get from DetailsView to Navigation for example? It gets there because outputs allow the data to flow in reverse directions. Outputs are not data-binding and so they don't break the DAG principle. So DetailsView would pass the data to MainPane which would pass it to App. App in turn would feed it intNavigation` using its input.

      -> Navigation   -> UserProfile
     /              /
App----> MainPane ----> DetailsView
   <----          <----

---> Input
<--- Output

Input by its very nature is async. You don't control when the data shows up. Output is sync, as in you decide when you push data into the output stream. Yes it is novel terminology, but it does fit rather well.

We understand that Input/Output seems like a term from nowhere, but it actually solves the issues associated with explaining how things work in Angular2. It may not be something which fits your pre-existing terminology, but it arguably fits better then Property/Event which is riddled with confusion and double meaning.

Member

mhevery commented Oct 1, 2015

OK, let me take a crack of explaining the reasoning. :-)

The issue is that word @Property and @Event are two vague. Let's look at an example.

@Component({
  selector: 'pane'
  properties: ['title'],
  events: ['close']
})
@View({
  template: '<div class={{color}}>{{title}}</div>'
}) 
class Pane {
  @Property() title: string;
  color: string;
  @Event() close = new EventEmitter();
}

All title, color, and close are properties on the Pane class. So calling title as @Property is confusing, as from the OO perspective all three are properties or fields. We could call it a PropertyBinding but that would not be correct. Since we are declaring that a particular property can be bound to externally, not that there is a binding. (We can and do bind to color in our template) For example:

<pane title="My Pane">

Does not have any bindings. We simply initialize the title property with MyPane string literal. So it is not a binding.

A better thing would be to call title as @Public to say that it is part of the external API.

<pane title="My Pane" color="blue">

here title is to be bound to title property, but not color since the component treats color as an implementation detail. The issue with @Public is that in OO visibility has clear meaning on public, and all properties are public even color and close.

We could call it @Binding but that is not right, since we are not declaring a binding, only a location where value is stored. There may or may not be a binding but that is controlled by the template. Furthermore, it would make it seems as color did not have binding, but that is not true since the view does bind to color.

Ok, so now @Property, @Binding, @Public is out. What should we call it? Well if you step back, and go to our DAG goal, you realize that title is a place where data comes in from the outside world. It is what allows propagation of data from the root of the application down to the leafs. It is a property on a component which can accept external data. Not only it is where the data is accepted, it is clearly unidirectional. The words which come to bind are input or import. Import sounds like an action, so it is out. So we are left with input. If you think of component as a device in your HiFi stereo, then you are declaring where the information comes in hence the @Input Data shows up here. You don't control how it shows up, it just does.

Now if you think about @Event the issue is that it is not clear if you are asking to be notified of an event or if you will be firing an event. Furthermore you are not firing an event, rather you are pushing data into a stream. Again when you step back you realize that events are the only way to get the data out of the component, hence it is @Output.

When you have a DAG, inputs allow you to get data from the root component to the leafs, whereas outputs allow you to flow the data from the leafs to the root component.

Imagine you have an app such as this:

      -> Navigation   -> UserProfile
     /              /
App----> MainPane ----> DetailsView
     \
      -> Status

---> Input
<--- Output

This app is strictly DAG. So how is data supposed to get from DetailsView to Navigation for example? It gets there because outputs allow the data to flow in reverse directions. Outputs are not data-binding and so they don't break the DAG principle. So DetailsView would pass the data to MainPane which would pass it to App. App in turn would feed it intNavigation` using its input.

      -> Navigation   -> UserProfile
     /              /
App----> MainPane ----> DetailsView
   <----          <----

---> Input
<--- Output

Input by its very nature is async. You don't control when the data shows up. Output is sync, as in you decide when you push data into the output stream. Yes it is novel terminology, but it does fit rather well.

We understand that Input/Output seems like a term from nowhere, but it actually solves the issues associated with explaining how things work in Angular2. It may not be something which fits your pre-existing terminology, but it arguably fits better then Property/Event which is riddled with confusion and double meaning.

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

@mhevery

First of all, thank you for your explanations, that gives a lot of insight on what you guys are dealing with ;)

Nevertheless I get the feeling that the terminology you came up with is driven by your (framework designers) POV. I can only speak for me, but I as a developer think that those two cases:

<img [src]="user.img"/>


<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

should be treated equally - also in terms of naming. From a webdevelopers POV I bind to a property in both cases. Thats just common terminolgy to me.

Your argument that @Property would be wrong, as color is also a property is true when looking at the component from the controller-classes object oriented meaning. But I have the feeling that the more natural way of looking at the topic (and the terminology) is from the (DOM-)Interface of the component. And looking at it from that point of view the Interface of the Component consists of properties and events.

Furthermore Input and Output in almost all other programming languages are used for File System Operations or Streaming Operations (e.g in Spring - http://docs.spring.io/spring-cloud-dataflow/docs/1.0.0.M1/reference/html/_introducing_spring_cloud_stream.html) I know one could argue that in A2 the 2 cases we are talking about are also kind of streams, but to me this really sounds kind of academic.

Don't get me wrong, I absolutely appreciate your work in finding good namings, it's just that I think that most people have another POV on this.

Contributor

choeller commented Oct 1, 2015

@mhevery

First of all, thank you for your explanations, that gives a lot of insight on what you guys are dealing with ;)

Nevertheless I get the feeling that the terminology you came up with is driven by your (framework designers) POV. I can only speak for me, but I as a developer think that those two cases:

<img [src]="user.img"/>


<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

should be treated equally - also in terms of naming. From a webdevelopers POV I bind to a property in both cases. Thats just common terminolgy to me.

Your argument that @Property would be wrong, as color is also a property is true when looking at the component from the controller-classes object oriented meaning. But I have the feeling that the more natural way of looking at the topic (and the terminology) is from the (DOM-)Interface of the component. And looking at it from that point of view the Interface of the Component consists of properties and events.

Furthermore Input and Output in almost all other programming languages are used for File System Operations or Streaming Operations (e.g in Spring - http://docs.spring.io/spring-cloud-dataflow/docs/1.0.0.M1/reference/html/_introducing_spring_cloud_stream.html) I know one could argue that in A2 the 2 cases we are talking about are also kind of streams, but to me this really sounds kind of academic.

Don't get me wrong, I absolutely appreciate your work in finding good namings, it's just that I think that most people have another POV on this.

@endash

This comment has been minimized.

Show comment
Hide comment
@endash

endash Oct 1, 2015

To add a tiny bit to the point @choeller makes: it feels like the public/external interface (in this case, the way we talk about/document using a component in a template) is being sacrificed because of confusion related to the implementation. Talking of setting properties and listening for events makes perfect sense from the perspective of actually using the component.

A practical consideration: Input/Output implies a symmetry that doesn't exist: Input is a property binding, but Output is not. In the post-two-way-binding world, that is a naming issue that can create confusion. I have a hunch that most explanations for the difference will involve the word "event."

endash commented Oct 1, 2015

To add a tiny bit to the point @choeller makes: it feels like the public/external interface (in this case, the way we talk about/document using a component in a template) is being sacrificed because of confusion related to the implementation. Talking of setting properties and listening for events makes perfect sense from the perspective of actually using the component.

A practical consideration: Input/Output implies a symmetry that doesn't exist: Input is a property binding, but Output is not. In the post-two-way-binding world, that is a naming issue that can create confusion. I have a hunch that most explanations for the difference will involve the word "event."

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 1, 2015

Member
<img [src]="user.img"/>

<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

Here as you point of from the host template point of view we are binding to properties, which is true. Now what do you call the property on the component which we can bind to? We think it should be called the @Input property to be differentiated from other properties which are not inputs.

We are not saying that you should stop thinking of them as properties, only that we need a qualifier what kind of property it is. @Property property is not useful, where as @Input property is.

So the mental model is that components have properties. All properties can be used for data binding in the view, but only @Input properties can be used for binding from the host template.

Similarly @Event EventEmitter property is not as clear as @Output EventEmitter property. (You could have other EventEmitters which are not part of your public API and are not used for @Output)

We feel that there is a symmetry between Input/Output. One gets data in, the other out.

Member

mhevery commented Oct 1, 2015

<img [src]="user.img"/>

<my-fancy-bar-chart [data]="data"></my-fancy-bar-chart>

Here as you point of from the host template point of view we are binding to properties, which is true. Now what do you call the property on the component which we can bind to? We think it should be called the @Input property to be differentiated from other properties which are not inputs.

We are not saying that you should stop thinking of them as properties, only that we need a qualifier what kind of property it is. @Property property is not useful, where as @Input property is.

So the mental model is that components have properties. All properties can be used for data binding in the view, but only @Input properties can be used for binding from the host template.

Similarly @Event EventEmitter property is not as clear as @Output EventEmitter property. (You could have other EventEmitters which are not part of your public API and are not used for @Output)

We feel that there is a symmetry between Input/Output. One gets data in, the other out.

@PascalPrecht

This comment has been minimized.

Show comment
Hide comment
@PascalPrecht

PascalPrecht Oct 1, 2015

Contributor

Is there still a chance to come up with an alternative naming? Fact is,
more ppl will have problems understanding this terminology as opposed to
before this change.

I totally get the reasoning behind it, but we also see that it takes a lot
of explanation of why this change as been made, whereas most of the users
were already fine with the current wording.

Maybe it helps if we could at least come up with yet another alternative?
We should pull in as many community members as possible to collect good
proposals.

If we don't find anything better we can still stick with input/ouput.

On Thu, Oct 1, 2015, 10:23 PM Miško Hevery notifications@github.com wrote:

<img [src]="user.img"/>

<my-fancy-bar-chart [data]="data">

Here as you point of from the host template point of view we are binding
to properties, which is true. Now what do you call the property on the
component which we can bind to? We think it should be called the @input
property to be differentiated from other properties which are not inputs.

We are not saying that you should stop thinking of them as properties,
only that we need a qualifier what kind of property it is. @Property
property is not useful, where as @input property is.

So the mental model is that components have properties. All properties can
be used for data binding in the view, but only @input properties can be
used for binding from the host template.

Similarly @event EventEmitter property is not as clear as @output
EventEmitter property.

We feel that there is a symmetry between Input/Output. One gets data in,
the other out.


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

Contributor

PascalPrecht commented Oct 1, 2015

Is there still a chance to come up with an alternative naming? Fact is,
more ppl will have problems understanding this terminology as opposed to
before this change.

I totally get the reasoning behind it, but we also see that it takes a lot
of explanation of why this change as been made, whereas most of the users
were already fine with the current wording.

Maybe it helps if we could at least come up with yet another alternative?
We should pull in as many community members as possible to collect good
proposals.

If we don't find anything better we can still stick with input/ouput.

On Thu, Oct 1, 2015, 10:23 PM Miško Hevery notifications@github.com wrote:

<img [src]="user.img"/>

<my-fancy-bar-chart [data]="data">

Here as you point of from the host template point of view we are binding
to properties, which is true. Now what do you call the property on the
component which we can bind to? We think it should be called the @input
property to be differentiated from other properties which are not inputs.

We are not saying that you should stop thinking of them as properties,
only that we need a qualifier what kind of property it is. @Property
property is not useful, where as @input property is.

So the mental model is that components have properties. All properties can
be used for data binding in the view, but only @input properties can be
used for binding from the host template.

Similarly @event EventEmitter property is not as clear as @output
EventEmitter property.

We feel that there is a symmetry between Input/Output. One gets data in,
the other out.


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

@endash

This comment has been minimized.

Show comment
Hide comment
@endash

endash Oct 1, 2015

@mhevery

We feel that there is a symmetry between Input/Output. One gets data in, the other out.

Again... overly reductive. When you're claiming the high ground of clarity and precision it doesn't do to rely on so great a stretch. Only by resorting to such broad generalities does any symmetry obtain.

endash commented Oct 1, 2015

@mhevery

We feel that there is a symmetry between Input/Output. One gets data in, the other out.

Again... overly reductive. When you're claiming the high ground of clarity and precision it doesn't do to rely on so great a stretch. Only by resorting to such broad generalities does any symmetry obtain.

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

@mhevery I think the most important point is, that you are primarily talking about how to distinguish the different properties within the implementation of the controller, whereas @endash and me are looking at this from the "interface of the component" POV.

Looking at how the @component annotation would look in a concrete case to me shows, that this naming is not intuitive at all:

    @Component({inputs: ['data'], outputs: ['item-selected']})

outputs: ['property-selected'] to me really means nothing, whereas events would perfectly describe the interface of the component...

Contributor

choeller commented Oct 1, 2015

@mhevery I think the most important point is, that you are primarily talking about how to distinguish the different properties within the implementation of the controller, whereas @endash and me are looking at this from the "interface of the component" POV.

Looking at how the @component annotation would look in a concrete case to me shows, that this naming is not intuitive at all:

    @Component({inputs: ['data'], outputs: ['item-selected']})

outputs: ['property-selected'] to me really means nothing, whereas events would perfectly describe the interface of the component...

@gdi2290

This comment has been minimized.

Show comment
Hide comment
@gdi2290

gdi2290 Oct 1, 2015

Member
tldr;

If [] are considered inputs then something like [attr.value] seems reasonable now. When working with components I would say it's easier to quickly reason about what matters (inputs/outputs) for each component allowing us to better understand the data flow (most important part). Sticking with these naming conventions (Input/Output) forces users to think of their data in the correct way when building apps rather than the correct term (different goals). Even though properties/events are correct terms it doesn't help us when dealing with what really matters most (better understanding of our code in relation to our application data flow).



reasoning makes sense.

If I'm not mistaken we should probably correct some terms here just to ensure we're all on the same page. In the example <input value="My Value"> value is an attribute which is a serialized property. The element tag may ensure the property is serialized when we change the property and vice versa but that's an implementation detail for <input> element tag.

Let's step back and look at the big picture to remember how complex Web Development.

Remember that we don't think of all the moving parts when developing our apps.

Human Output
↓
Client Input
→ url (serialized website)
↓
Server Input
→ Server Router
→ Server Render javascript/html/css (serialized ngApp)
Server Output
↓
Browser Input 
→ index.html (serialized render tree)
→ Browser parser html/js/css
→ DOM (render tree as properties)
→ JavaScript (serialized ngApp)
→ Angular compiler html/(pending css compiler?)
→ ProtoView (Angular render tree aka component tree as properties) 
// this is where our app runs with our component tree
→ Angular Render
↓
→ Browser render tree (DOM) changed
→ Browser render
Browser Output
↓
Client Output
↓
Input Human

Everything is an Input/Output. We only view html when we open our web inspector where it shows the serialized render tree. Let's interact with simplified version of the render tree with one element.

class Element {
  private _currentText: string;
  constructor(public name: string) {

  }

  setText(class: string) {
    this._currentText = class;  
  }
  toString(): string {
    return `< ${ this.name}>${ this._currentText }</${ this.name }>`;
  }
}

var el = new Element('div')
el.setText('yolo') // toString() => '<div>yolo</div>'
// any time we can serialized the element
el.setText('somethingElse') // toString() => '<div>somethingElse</div>'

setTimeout(() => {
  el.addText('futureClass') // toString() => '<div>futureClass</div>'
}, nextYear)

el.toString() // => '<div>somethingElse</div>';

So when we create an .html document we are working with the serialized version of the DOM which allows us to reason about the render tree that we never think about. When we open the web inspector we are again presented with the serialized version of the DOM as HTML.

When writing Angular Templates we're reasoning with our application declaratively in order to compose a certain behavior. If we look at the big picture we will notice the arrows going down the stack are actions that change the application state in some way. We create a behavior to happen once an action is invoked. The browser supports this as <button onclick="action()"> for an element and we have the same thing for Angular 2 as <button (click)="action()"> or <button on-click="action()">.

let's look at a simplified synchronous version of Angular 2

class App {
static selector: string = 'app';
static template: string = '

{{ value }} </div';
value: = 'myText';
action() {
log('action was made')
}
}

var html = render(cd(compiler(di(App))));

bootstrap(html);

It's easier to see that our App is simply an Input for Angular to Output into the browser. When a user clicks on our view that is an action.

Let's look at how the browser handles actions with forms without a framework in order for us to have a certain behavior (in this case console.log our input value)

<form onsubmit="action()">
  <input id="myInput" name="patrickjs" value="">
  <button>Submit</button>
</form>
<script>
window.action = function() {
  var $input = document.getElementById('myInput');
  var attrValue = $input.getAttribute('value'); // we don't care about the attribute
  var propValue = $input.value;
  console.log('behavior', propValue);
}
</script>

The <form> element tag registers a listener for the element waiting for the submit event. When the user clicks on the <button> element tag an event is created that is bubbled up. Our <form> element tag captures the event and invokes action() for our behavior to happen. Now let's recreate the <button> element tag in Angular 2 given this example

remember that [value] is binding to properties while [attr.value] binds to attribute.

// text = 'Submit';
<button [value]="text"></button>
@Component({
  selector: 'button'
})
@View({
  styles: [/*button styles */]
  template: '<span (click)="onClick($event)">{{ value }}</span>'
})
class Button {
  @Input() value: string;
  @Output() submit = new EventEmitter();

  onClick(event) {
    this.submit.next(event);
  }
}

When the user clicks on the <button> component it's up to the author of the component to figure out what behavior we want do with the event. Everything outside of the component does not need to know what happens inside of <button> but can rely on the interface of input/outputs. This blackboxing, or encapsulation, allows the developer to maintain only a minimal amount of logic at a time without having to think about the whole application.

If [] are considered inputs then something like [attr.value] seems reasonable now. When working with components I would say it's easier to quickly reason about what matters (inputs/outputs) for each component allowing us to better understand the data flow (most important part). Sticking with these naming conventions (Input/Output) forces users to think of their data in the correct way when building apps rather than the correct term (different goals). Even though properties/events are correct terms it doesn't help us when dealing with what really matters most (better understanding of our code in relation to our application data flow).

Tipe CMS

Member

gdi2290 commented Oct 1, 2015

tldr;

If [] are considered inputs then something like [attr.value] seems reasonable now. When working with components I would say it's easier to quickly reason about what matters (inputs/outputs) for each component allowing us to better understand the data flow (most important part). Sticking with these naming conventions (Input/Output) forces users to think of their data in the correct way when building apps rather than the correct term (different goals). Even though properties/events are correct terms it doesn't help us when dealing with what really matters most (better understanding of our code in relation to our application data flow).



reasoning makes sense.

If I'm not mistaken we should probably correct some terms here just to ensure we're all on the same page. In the example <input value="My Value"> value is an attribute which is a serialized property. The element tag may ensure the property is serialized when we change the property and vice versa but that's an implementation detail for <input> element tag.

Let's step back and look at the big picture to remember how complex Web Development.

Remember that we don't think of all the moving parts when developing our apps.

Human Output
↓
Client Input
→ url (serialized website)
↓
Server Input
→ Server Router
→ Server Render javascript/html/css (serialized ngApp)
Server Output
↓
Browser Input 
→ index.html (serialized render tree)
→ Browser parser html/js/css
→ DOM (render tree as properties)
→ JavaScript (serialized ngApp)
→ Angular compiler html/(pending css compiler?)
→ ProtoView (Angular render tree aka component tree as properties) 
// this is where our app runs with our component tree
→ Angular Render
↓
→ Browser render tree (DOM) changed
→ Browser render
Browser Output
↓
Client Output
↓
Input Human

Everything is an Input/Output. We only view html when we open our web inspector where it shows the serialized render tree. Let's interact with simplified version of the render tree with one element.

class Element {
  private _currentText: string;
  constructor(public name: string) {

  }

  setText(class: string) {
    this._currentText = class;  
  }
  toString(): string {
    return `< ${ this.name}>${ this._currentText }</${ this.name }>`;
  }
}

var el = new Element('div')
el.setText('yolo') // toString() => '<div>yolo</div>'
// any time we can serialized the element
el.setText('somethingElse') // toString() => '<div>somethingElse</div>'

setTimeout(() => {
  el.addText('futureClass') // toString() => '<div>futureClass</div>'
}, nextYear)

el.toString() // => '<div>somethingElse</div>';

So when we create an .html document we are working with the serialized version of the DOM which allows us to reason about the render tree that we never think about. When we open the web inspector we are again presented with the serialized version of the DOM as HTML.

When writing Angular Templates we're reasoning with our application declaratively in order to compose a certain behavior. If we look at the big picture we will notice the arrows going down the stack are actions that change the application state in some way. We create a behavior to happen once an action is invoked. The browser supports this as <button onclick="action()"> for an element and we have the same thing for Angular 2 as <button (click)="action()"> or <button on-click="action()">.

let's look at a simplified synchronous version of Angular 2

class App {
static selector: string = 'app';
static template: string = '

{{ value }} </div';
value: = 'myText';
action() {
log('action was made')
}
}

var html = render(cd(compiler(di(App))));

bootstrap(html);

It's easier to see that our App is simply an Input for Angular to Output into the browser. When a user clicks on our view that is an action.

Let's look at how the browser handles actions with forms without a framework in order for us to have a certain behavior (in this case console.log our input value)

<form onsubmit="action()">
  <input id="myInput" name="patrickjs" value="">
  <button>Submit</button>
</form>
<script>
window.action = function() {
  var $input = document.getElementById('myInput');
  var attrValue = $input.getAttribute('value'); // we don't care about the attribute
  var propValue = $input.value;
  console.log('behavior', propValue);
}
</script>

The <form> element tag registers a listener for the element waiting for the submit event. When the user clicks on the <button> element tag an event is created that is bubbled up. Our <form> element tag captures the event and invokes action() for our behavior to happen. Now let's recreate the <button> element tag in Angular 2 given this example

remember that [value] is binding to properties while [attr.value] binds to attribute.

// text = 'Submit';
<button [value]="text"></button>
@Component({
  selector: 'button'
})
@View({
  styles: [/*button styles */]
  template: '<span (click)="onClick($event)">{{ value }}</span>'
})
class Button {
  @Input() value: string;
  @Output() submit = new EventEmitter();

  onClick(event) {
    this.submit.next(event);
  }
}

When the user clicks on the <button> component it's up to the author of the component to figure out what behavior we want do with the event. Everything outside of the component does not need to know what happens inside of <button> but can rely on the interface of input/outputs. This blackboxing, or encapsulation, allows the developer to maintain only a minimal amount of logic at a time without having to think about the whole application.

If [] are considered inputs then something like [attr.value] seems reasonable now. When working with components I would say it's easier to quickly reason about what matters (inputs/outputs) for each component allowing us to better understand the data flow (most important part). Sticking with these naming conventions (Input/Output) forces users to think of their data in the correct way when building apps rather than the correct term (different goals). Even though properties/events are correct terms it doesn't help us when dealing with what really matters most (better understanding of our code in relation to our application data flow).

Tipe CMS

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 1, 2015

Contributor

Ok, to be honest I read this post 4 times and I still don't understand it... This leads me to the conclusion that (at least for me) this does not lead to any better understanding.

Just to make my point one last time - I'm pretty sure that at least 99% of the people that are going to use Angular2 in their everyday work are not going to reason about what will "be serialized version of an action", but are going to think about what is the interface of my component... Maybe I'm too dumb for that, but I really think I'm the majority :-P

Contributor

choeller commented Oct 1, 2015

Ok, to be honest I read this post 4 times and I still don't understand it... This leads me to the conclusion that (at least for me) this does not lead to any better understanding.

Just to make my point one last time - I'm pretty sure that at least 99% of the people that are going to use Angular2 in their everyday work are not going to reason about what will "be serialized version of an action", but are going to think about what is the interface of my component... Maybe I'm too dumb for that, but I really think I'm the majority :-P

@kasperpeulen

This comment has been minimized.

Show comment
Hide comment
@kasperpeulen

kasperpeulen Oct 1, 2015

I like the notation, and it makes sense. Data flows in to the component via property bindings and out of the component through event bindings. I don't think this notation is here to suddenly call property bindings, "input" bindings and event bindings, "output" bindings. It still are properties, and events, but special properties and events, that are part of the public api of the component.

I don't fully understand the argument, that this notation only makes sense inside the controller and not from the "interface of the component" POV. Because, you only use this notation "inside" the controller, right? And there this notation makes sense. You don't have to write something like

<my-fancy-bar-chart @Input[data]="data">

You can just see [data] as a property binding, where data is a property inside the controller that is annotated with the @Input notation so that you are really allowed to let data flow in to the component using such a property binding.

I like the notation, and it makes sense. Data flows in to the component via property bindings and out of the component through event bindings. I don't think this notation is here to suddenly call property bindings, "input" bindings and event bindings, "output" bindings. It still are properties, and events, but special properties and events, that are part of the public api of the component.

I don't fully understand the argument, that this notation only makes sense inside the controller and not from the "interface of the component" POV. Because, you only use this notation "inside" the controller, right? And there this notation makes sense. You don't have to write something like

<my-fancy-bar-chart @Input[data]="data">

You can just see [data] as a property binding, where data is a property inside the controller that is annotated with the @Input notation so that you are really allowed to let data flow in to the component using such a property binding.

@ericmartinezr

This comment has been minimized.

Show comment
Hide comment
@ericmartinezr

ericmartinezr Oct 1, 2015

Contributor

I think you guys are trying to solve a problem that is not up to you to solve. One thing is javascript classes and its properties and ng2 data binding. As far as I know javascript itself doesn't have annotations to mark what is a property inside a class, so what is really the confusing part?

When you say @Property is for binding you are already out of OO paradigm, because you are not talking about a class property, you are talking about property annotation which has another purpose that the user will understand easily and it is a framework-specific-feature. So basically you take user's hand and move him from Javascript OOP (or just OOP to be more generic) to ng2 so the user can clearly differentiate between both (assuming the user really gets confused in this case, because personally I would never think of @Property as for defining classes properties).

Regarding to @Event I'll quote this

Now if you think about @event the issue is that it is not clear if you are asking to be notified of an event or if you will be firing an event

If it is so confusing, why not change the current one to @EventListener and add another one called @EventRegister or just keep @Event and make the user/developer to care about if it will receive or it will emit.

The problem I have with these new names is that I can only think of reading/writing. You are totally out of ng2 when you say I/O. As @gdi2290 mentioned I/O is present everywhere, but that's not ng2 business. When we say @Property and @Events (and someone who comes from a different framework can easily understand at least one of them, if not both) we know we are talking about ng2 features, but when we say I/O what are we talking about? Hardware? Software? Reading/Writing? And in the latter case, reading/writing what, from where, to where? I think these two names are making this framework to go way low level conceptually speaking, which is not its purpose.

Probably I'm the less experienced user/developer in here, and I can tell you that this will make more harm than good (maybe I'm being toooo dramatic, but I can't think of any good about this).

Contributor

ericmartinezr commented Oct 1, 2015

I think you guys are trying to solve a problem that is not up to you to solve. One thing is javascript classes and its properties and ng2 data binding. As far as I know javascript itself doesn't have annotations to mark what is a property inside a class, so what is really the confusing part?

When you say @Property is for binding you are already out of OO paradigm, because you are not talking about a class property, you are talking about property annotation which has another purpose that the user will understand easily and it is a framework-specific-feature. So basically you take user's hand and move him from Javascript OOP (or just OOP to be more generic) to ng2 so the user can clearly differentiate between both (assuming the user really gets confused in this case, because personally I would never think of @Property as for defining classes properties).

Regarding to @Event I'll quote this

Now if you think about @event the issue is that it is not clear if you are asking to be notified of an event or if you will be firing an event

If it is so confusing, why not change the current one to @EventListener and add another one called @EventRegister or just keep @Event and make the user/developer to care about if it will receive or it will emit.

The problem I have with these new names is that I can only think of reading/writing. You are totally out of ng2 when you say I/O. As @gdi2290 mentioned I/O is present everywhere, but that's not ng2 business. When we say @Property and @Events (and someone who comes from a different framework can easily understand at least one of them, if not both) we know we are talking about ng2 features, but when we say I/O what are we talking about? Hardware? Software? Reading/Writing? And in the latter case, reading/writing what, from where, to where? I think these two names are making this framework to go way low level conceptually speaking, which is not its purpose.

Probably I'm the less experienced user/developer in here, and I can tell you that this will make more harm than good (maybe I'm being toooo dramatic, but I can't think of any good about this).

@vicb

This comment has been minimized.

Show comment
Hide comment
@vicb

vicb Oct 4, 2015

Member

@alexpods @choeller nope :(

Think simple & HTML what are "title" and "class" to a div ?

Member

vicb commented Oct 4, 2015

@alexpods @choeller nope :(

Think simple & HTML what are "title" and "class" to a div ?

@ericmartinezr

This comment has been minimized.

Show comment
Hide comment
@ericmartinezr

ericmartinezr Oct 4, 2015

Contributor

@vicb I've been thinking in something like @MapTo() where you can specify if it is a property or an event, like

@MapTo({property:'XXX'})
@MapTo({attribute:'XXX'})
@MapTo({event:'XXX'})

Although it's too generic it may solve the problem of confusing anything with anything...

Contributor

ericmartinezr commented Oct 4, 2015

@vicb I've been thinking in something like @MapTo() where you can specify if it is a property or an event, like

@MapTo({property:'XXX'})
@MapTo({attribute:'XXX'})
@MapTo({event:'XXX'})

Although it's too generic it may solve the problem of confusing anything with anything...

@alexpods

This comment has been minimized.

Show comment
Hide comment
@alexpods

alexpods Oct 4, 2015

@vicb For this moment I've thought that there are properties (or attributes) of a div:)
Maybe @Asset, no?
Or maybe @Attribute? Then feature of binding to attributes ([attr.name]) must be removed.

alexpods commented Oct 4, 2015

@vicb For this moment I've thought that there are properties (or attributes) of a div:)
Maybe @Asset, no?
Or maybe @Attribute? Then feature of binding to attributes ([attr.name]) must be removed.

@ericmartinezr

This comment has been minimized.

Show comment
Hide comment
@ericmartinezr

ericmartinezr Oct 4, 2015

Contributor

@alexpods @Attribute already exists

Contributor

ericmartinezr commented Oct 4, 2015

@alexpods @Attribute already exists

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 5, 2015

Member

Imagine you have <pane [title]="userName" (click)="onClick()">. Let's pretend we are writing documentation and try to explain all of the parts.

  • [title] is a property binding. What does it do? It binds to a title property of the underlying object.
  • (click) is an event listener. What does it do? It registers a listener (for events) on the underlying object.

I think we all agree with the above.

Now let's implement pane (I am going to omit the annotations)

@Component({selector: 'pane'})
@View({
  template: `<div>{{salutation}} {{title}}</div>`
})
class Pane {
  title: string;
  salutation: string;
  click: EventEmitter;
}
  • {{salutation}} {{title}}. Here both salutation and title both bind to the salutation and title property of the Pane class. Why property? Well that is what the ES6 OO calls them. This is a well established vocabulary of the developers. So calling something @Property but mean something else, is a bit confusing. It is reusing the term and giving it a different meaning. You would say salutation is the property you want to bind to. But you don't want to say that the title is the property property you are binding too. Notice also that all salutation, title and click are all properties. What we need is an adjective which can differentiate between the usage point of view and the implementation point of view. That way you can say that:
    • All properties on the component can be bound to from the component's view (implementation). {{salutation}} {{title}}
    • Only input/public/???? properties can be bound to from the content view (usage) [title]="expr"
    • click is a emitter/output/??? property which contains the EventEmitter which allows the components to fire events. (click)="action()"
  • @Property is out because it makes it hard to write documentation and communicate with your co-works. The word property could mean a property on a class, or it could mean the the special publicly visible property which we could bind to from the outside. You don't want to say: Bind 'userName' property to create a binding to the Pane's title property property. We have to make sure that these terms can be used naturally in a sentence without ambiguity. (Bind 'userName' property to create a binding to the Pane's title input property.) We don't have to use Input, but so far I have not seen a recommendation which could be used.
  • @Binding is out because it is not a binding. Again imagine the sentence: Bind 'userName' property to create a binding to the Pane's title binding property. [title]="userName" creates the binding. The property is the recipient of the binding, it is not the binding.
  • @Event is out for two reasons:
    1. it creates a name collision with with the actual Event from the eventListener.
    2. What you are declaring is a place where events are generated, not the event itself. If click was an event, then we would write click = new Event() but we write click = new EventEmitter(). Saying @Event click = new EventEmitter() is confusing, because it looks like click is both the event and event-emitter. This may look obvious to you, but imagine having to explain to a novice.

Going forward:

  1. We apologize for not giving you more notice. Please understand that this is alpha software, and we are still learning what is best.
  2. We hear you load and clear that some of you are not fans of input/output.
  3. We welcome your constructive input on how to make it better. Please don't make it in the from of we like the old one better, since we have already explained why the old model is broken and why we are trying something new.
  • Single words are preferable. Please don't suggest as an example @BindingValue since it is two words, it is not a binding, and everything is a value. We don't name things PaneClass since everything is a class.
  • Please explain how these terms could be documented or could be used in a sentence in a way which does not create ambiguity.
Member

mhevery commented Oct 5, 2015

Imagine you have <pane [title]="userName" (click)="onClick()">. Let's pretend we are writing documentation and try to explain all of the parts.

  • [title] is a property binding. What does it do? It binds to a title property of the underlying object.
  • (click) is an event listener. What does it do? It registers a listener (for events) on the underlying object.

I think we all agree with the above.

Now let's implement pane (I am going to omit the annotations)

@Component({selector: 'pane'})
@View({
  template: `<div>{{salutation}} {{title}}</div>`
})
class Pane {
  title: string;
  salutation: string;
  click: EventEmitter;
}
  • {{salutation}} {{title}}. Here both salutation and title both bind to the salutation and title property of the Pane class. Why property? Well that is what the ES6 OO calls them. This is a well established vocabulary of the developers. So calling something @Property but mean something else, is a bit confusing. It is reusing the term and giving it a different meaning. You would say salutation is the property you want to bind to. But you don't want to say that the title is the property property you are binding too. Notice also that all salutation, title and click are all properties. What we need is an adjective which can differentiate between the usage point of view and the implementation point of view. That way you can say that:
    • All properties on the component can be bound to from the component's view (implementation). {{salutation}} {{title}}
    • Only input/public/???? properties can be bound to from the content view (usage) [title]="expr"
    • click is a emitter/output/??? property which contains the EventEmitter which allows the components to fire events. (click)="action()"
  • @Property is out because it makes it hard to write documentation and communicate with your co-works. The word property could mean a property on a class, or it could mean the the special publicly visible property which we could bind to from the outside. You don't want to say: Bind 'userName' property to create a binding to the Pane's title property property. We have to make sure that these terms can be used naturally in a sentence without ambiguity. (Bind 'userName' property to create a binding to the Pane's title input property.) We don't have to use Input, but so far I have not seen a recommendation which could be used.
  • @Binding is out because it is not a binding. Again imagine the sentence: Bind 'userName' property to create a binding to the Pane's title binding property. [title]="userName" creates the binding. The property is the recipient of the binding, it is not the binding.
  • @Event is out for two reasons:
    1. it creates a name collision with with the actual Event from the eventListener.
    2. What you are declaring is a place where events are generated, not the event itself. If click was an event, then we would write click = new Event() but we write click = new EventEmitter(). Saying @Event click = new EventEmitter() is confusing, because it looks like click is both the event and event-emitter. This may look obvious to you, but imagine having to explain to a novice.

Going forward:

  1. We apologize for not giving you more notice. Please understand that this is alpha software, and we are still learning what is best.
  2. We hear you load and clear that some of you are not fans of input/output.
  3. We welcome your constructive input on how to make it better. Please don't make it in the from of we like the old one better, since we have already explained why the old model is broken and why we are trying something new.
  • Single words are preferable. Please don't suggest as an example @BindingValue since it is two words, it is not a binding, and everything is a value. We don't name things PaneClass since everything is a class.
  • Please explain how these terms could be documented or could be used in a sentence in a way which does not create ambiguity.
@todoubaba

This comment has been minimized.

Show comment
Hide comment
@todoubaba

todoubaba Oct 5, 2015

Contributor

@mhevery What about @Visible?
It can describe both title and click, it means the property of component class is visible to the content view.
We can say: Bind SomeContainer's userName property to the Pane's title property, only if the title propery is visible, same to click.

@Component({selector: 'pane'})
@View({
  template: `<div>{{salutation}} {{title}}</div>`
})
class Pane {
  @Visible() title: string;
  salutation: string;
  @Visible() click: EventEmitter;
}
Contributor

todoubaba commented Oct 5, 2015

@mhevery What about @Visible?
It can describe both title and click, it means the property of component class is visible to the content view.
We can say: Bind SomeContainer's userName property to the Pane's title property, only if the title propery is visible, same to click.

@Component({selector: 'pane'})
@View({
  template: `<div>{{salutation}} {{title}}</div>`
})
class Pane {
  @Visible() title: string;
  salutation: string;
  @Visible() click: EventEmitter;
}
@pkozlowski-opensource

This comment has been minimized.

Show comment
Hide comment
@pkozlowski-opensource

pkozlowski-opensource Oct 5, 2015

Member

@vicb were you going after @Attribute? This would make things close to HTML but imo this is not the same concept. On top of this it could very easily confuse people (I'm binding to DOM properties but to directive attributes).

@vicb were you going after @Attribute? This would make things close to HTML but imo this is not the same concept. On top of this it could very easily confuse people (I'm binding to DOM properties but to directive attributes).

@TommyM

This comment has been minimized.

Show comment
Hide comment
@TommyM

TommyM Oct 5, 2015

Although I'm not entirely convinced myself that any of the following suggestions are perfect, I do feel they have some merits to them and so I wanted to throw them out here.

class Pane {
  @External() title: string;
  @Incoming() title: string;
}

Both are slightly less ambiguous than @Input(), both suggest that the property is coming from the outside into the component and thus should be easy to explain/document, and both can't be confused with either an <input> tag nor user input.

class Pane {
  @Publisher() click: EventEmitter;
  @Emitter() click: EventEmitter;
  @Observable() click: EventEmitter;
}

These names are slightly less ambiguous than @Output(), they suggest that the component property is something that you can subscribe/listen to from outside the component and that the property is not an event itself. Though Observable might not be option since it could cause a collision with Rx.Observable.

They are also all single words, which is actually the hardest condition when naming these things!

TommyM commented Oct 5, 2015

Although I'm not entirely convinced myself that any of the following suggestions are perfect, I do feel they have some merits to them and so I wanted to throw them out here.

class Pane {
  @External() title: string;
  @Incoming() title: string;
}

Both are slightly less ambiguous than @Input(), both suggest that the property is coming from the outside into the component and thus should be easy to explain/document, and both can't be confused with either an <input> tag nor user input.

class Pane {
  @Publisher() click: EventEmitter;
  @Emitter() click: EventEmitter;
  @Observable() click: EventEmitter;
}

These names are slightly less ambiguous than @Output(), they suggest that the component property is something that you can subscribe/listen to from outside the component and that the property is not an event itself. Though Observable might not be option since it could cause a collision with Rx.Observable.

They are also all single words, which is actually the hardest condition when naming these things!

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 5, 2015

Contributor

@mhevery

First of all: Good to see, that you are taking care of our critics.

Please don't make it in the from of we like the old one better, since we have already explained why the old model is broken and why we are trying something new

If this is set, then my vote goes to Input & Output. My initial problem with the new Syntax was (and somehow still is) that I think that

@Component(
    something: [data],
    someThingElse:[element-selected]
)

should describe the interface of the component from the outer point of view (looking at how the component is used). In this context I still feel, that it's not intuitive to make a difference from what you call it, when describing the usage ("It registers a listener (for (click) events)") from what you call it, when describing the interface (outputs:[click]?).

But for me that would be the case for anything but events and properties - so if those are out Input & Output are the ones that I dislike the least 😜

Contributor

choeller commented Oct 5, 2015

@mhevery

First of all: Good to see, that you are taking care of our critics.

Please don't make it in the from of we like the old one better, since we have already explained why the old model is broken and why we are trying something new

If this is set, then my vote goes to Input & Output. My initial problem with the new Syntax was (and somehow still is) that I think that

@Component(
    something: [data],
    someThingElse:[element-selected]
)

should describe the interface of the component from the outer point of view (looking at how the component is used). In this context I still feel, that it's not intuitive to make a difference from what you call it, when describing the usage ("It registers a listener (for (click) events)") from what you call it, when describing the interface (outputs:[click]?).

But for me that would be the case for anything but events and properties - so if those are out Input & Output are the ones that I dislike the least 😜

@jimthedev

This comment has been minimized.

Show comment
Hide comment
@jimthedev

jimthedev Oct 5, 2015

Thinking of automobile components or HVAC you'll have very valves clearly marked intake and exhaust. The same is true for the human body's cardiovascular system. A given part (component) must always have intake and exhaust. The exhaust must go into the intake of the next component/part. I feel like input and output probably covers the same ground but it seemed worth at least worth bringing up these alternatives.

Thinking of automobile components or HVAC you'll have very valves clearly marked intake and exhaust. The same is true for the human body's cardiovascular system. A given part (component) must always have intake and exhaust. The exhaust must go into the intake of the next component/part. I feel like input and output probably covers the same ground but it seemed worth at least worth bringing up these alternatives.

@vicb

This comment has been minimized.

Show comment
Hide comment
@vicb

vicb Oct 5, 2015

Member

@alexpods @pkozlowski-opensource I was indeed thinking of @Attribute('my-attribute') myProp;

Member

vicb commented Oct 5, 2015

@alexpods @pkozlowski-opensource I was indeed thinking of @Attribute('my-attribute') myProp;

@gkalpak

This comment has been minimized.

Show comment
Hide comment
@gkalpak

gkalpak Oct 6, 2015

Member

I can't think about anything really appropriate (naming stuff is not my thing), but I can't help thinking that if the only difference (from normal instance properties) is that they can receive their value from the view, I would expect something more explicit (e.g. @FromView or something).

And while I can't really propose anything better, @Input is still too vague imo (e.g. a component can "receive input" on it's other public properties, just not from the view). "View" should be in the name if it's the differentiating factor.

FWIW, I would reconsider whether properties/inputs and events/outputs are really necessary. I am not convinced that they offer real benefit/solve a real problem (but it might be my luck of ng2 knowledge talking 😄).

Member

gkalpak commented Oct 6, 2015

I can't think about anything really appropriate (naming stuff is not my thing), but I can't help thinking that if the only difference (from normal instance properties) is that they can receive their value from the view, I would expect something more explicit (e.g. @FromView or something).

And while I can't really propose anything better, @Input is still too vague imo (e.g. a component can "receive input" on it's other public properties, just not from the view). "View" should be in the name if it's the differentiating factor.

FWIW, I would reconsider whether properties/inputs and events/outputs are really necessary. I am not convinced that they offer real benefit/solve a real problem (but it might be my luck of ng2 knowledge talking 😄).

@hsakkout

This comment has been minimized.

Show comment
Hide comment
@hsakkout

hsakkout Oct 9, 2015

First, I respect the intelligence of everyone on this discussion. However the input and output terminology is not semantically clean, and if angular is to be as successful as the first iteration, it has to be up to scratch.

There is a big difference between data (input OR output property) and a process communication step trigger like an event. Coercing these into input/output terminology is very unnatural.

This is not the first time people attempt to handle such concepts, of course. Take a look at all the literature on Communicating Sequential Processes (CSP) and Communicating Concurrent Systems (CCS) for ways to term communicating processes and the information they exchange in a data-driven way. In all such literature, it boils down to this: A process operates on state/properties/data, and its behavior is controlled by external events communicated via the configured channels.

I would suggest you really need Input Events, Output Events and State=Properties=data. That would allow an event such as "reset" to be communicated to all objects. The current proposal is confusing and limited.

hsakkout commented Oct 9, 2015

First, I respect the intelligence of everyone on this discussion. However the input and output terminology is not semantically clean, and if angular is to be as successful as the first iteration, it has to be up to scratch.

There is a big difference between data (input OR output property) and a process communication step trigger like an event. Coercing these into input/output terminology is very unnatural.

This is not the first time people attempt to handle such concepts, of course. Take a look at all the literature on Communicating Sequential Processes (CSP) and Communicating Concurrent Systems (CCS) for ways to term communicating processes and the information they exchange in a data-driven way. In all such literature, it boils down to this: A process operates on state/properties/data, and its behavior is controlled by external events communicated via the configured channels.

I would suggest you really need Input Events, Output Events and State=Properties=data. That would allow an event such as "reset" to be communicated to all objects. The current proposal is confusing and limited.

@webteckie

This comment has been minimized.

Show comment
Hide comment
@webteckie

webteckie Oct 9, 2015

If @Input and @Output are ambiguous why not disambiguate them:

class Pane {
  @ViewInput() title: string;
  @ViewOutput() click: string;
}

or

class Pane {
  @PropertyInput() title: string;
  @EventOutput() click: string;
}

If @Input and @Output are ambiguous why not disambiguate them:

class Pane {
  @ViewInput() title: string;
  @ViewOutput() click: string;
}

or

class Pane {
  @PropertyInput() title: string;
  @EventOutput() click: string;
}
@timkindberg

This comment has been minimized.

Show comment
Hide comment
@timkindberg

timkindberg Oct 10, 2015

As I was reading this long thread I kept thinking "what differentiates an input and output from a normal property?"

The view! Why is no one seeing this?!

Finally a sane person—@gkalpak—stumbles onto this thought as well. I agree with his suggestion to tie the name to the view (or dom/host/element) in some way.

As I was reading this long thread I kept thinking "what differentiates an input and output from a normal property?"

The view! Why is no one seeing this?!

Finally a sane person—@gkalpak—stumbles onto this thought as well. I agree with his suggestion to tie the name to the view (or dom/host/element) in some way.

@blackxored

This comment has been minimized.

Show comment
Hide comment
@blackxored

blackxored Oct 10, 2015

For one, I don't want my ES6 classes polluted with either @Property or @input or what have you, but that seems to be an issue we're not going back from. :'(

So, for me, Input/Output is even more generic and confusing that Property/Event as both component author and consumer.

For one, I don't want my ES6 classes polluted with either @Property or @input or what have you, but that seems to be an issue we're not going back from. :'(

So, for me, Input/Output is even more generic and confusing that Property/Event as both component author and consumer.

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 10, 2015

Member

@timkindberg

The view! Why is no one seeing this?!

A View is what the component has. From View you can bind to any property on the component and so there is no need for an annotation. In Angular terminology what we are referring to is <component [property]="exp"> and we call that Host. So it is not a ViewProperty but a HostProperty, but as I said before the word Property is unnecessary since all fields are properties. This creates further confusion with HostBinding.

Member

mhevery commented Oct 10, 2015

@timkindberg

The view! Why is no one seeing this?!

A View is what the component has. From View you can bind to any property on the component and so there is no need for an annotation. In Angular terminology what we are referring to is <component [property]="exp"> and we call that Host. So it is not a ViewProperty but a HostProperty, but as I said before the word Property is unnecessary since all fields are properties. This creates further confusion with HostBinding.

@timkindberg

This comment has been minimized.

Show comment
Hide comment
@timkindberg

timkindberg Oct 11, 2015

@mhevery hmmm yeah. How about @HostAttr.

Others: @hostinput @HostOutput.

I also kind of liked @visible.

@mhevery hmmm yeah. How about @HostAttr.

Others: @hostinput @HostOutput.

I also kind of liked @visible.

@BlackHC

This comment has been minimized.

Show comment
Hide comment
@BlackHC

BlackHC Oct 11, 2015

After skimming the discussion, the point that resonates best with me is that this is very much an implementation-based change and does not help the interface that much.

The concepts I'm thinking of when I'm using components in my markup is [properties] and (events) and that is the connection to the DOM. Input and output might make more sense for someone who is new to web programming, but it feels like the old naming was closer to the level of abstraction of web programmers.

Also, when you perform such changes, please remember that there is a ton of code already depending on this alpha and unnecessary renaming just costs cycles for everyone :)

BlackHC commented Oct 11, 2015

After skimming the discussion, the point that resonates best with me is that this is very much an implementation-based change and does not help the interface that much.

The concepts I'm thinking of when I'm using components in my markup is [properties] and (events) and that is the connection to the DOM. Input and output might make more sense for someone who is new to web programming, but it feels like the old naming was closer to the level of abstraction of web programmers.

Also, when you perform such changes, please remember that there is a ton of code already depending on this alpha and unnecessary renaming just costs cycles for everyone :)

@PascalPrecht

This comment has been minimized.

Show comment
Hide comment
@PascalPrecht

PascalPrecht Oct 11, 2015

Contributor

@mhevery hmmm yeah. How about @HostAttr.

One condition was that the decorator name is a single word.

Also, when you perform such changes, please remember that there is a ton of code already depending on this alpha and unnecessary renaming just costs cycles for everyone :)

That's the risk you take when depending on alpha code.

Contributor

PascalPrecht commented Oct 11, 2015

@mhevery hmmm yeah. How about @HostAttr.

One condition was that the decorator name is a single word.

Also, when you perform such changes, please remember that there is a ton of code already depending on this alpha and unnecessary renaming just costs cycles for everyone :)

That's the risk you take when depending on alpha code.

@montoyland

This comment has been minimized.

Show comment
Hide comment
@montoyland

montoyland Oct 11, 2015

@mhevery

Personally, I'm not at all bothered by this change as it borrows from terminology that is often used when thinking about finite state machines. In this conceptual model, each machine responds to input according to the state it happens to be in and outputs a response that is most appropriate for its current state. I don't find this too far afield from the problems angular is attempting to solve.

I wonder if the detractors of this semantic change might be more receptive to if rather than risk conflating terms that already have solidified meanings in other contexts (e.g. "input" in the context of HTML forms), we addressed the directionality of the flow of information instead of attempting to define it with a noun. Therefore what is now called "Input" would simply be "Inbound" and "Output" would be "Outbound". It's a subtle change, but one that I think strays from well understood connotations of those words and shifts the focus to directionality and the flow of data, which is really what we should be thinking about anyway.

I therefore propose:

@Inboud @outbound

@mhevery

Personally, I'm not at all bothered by this change as it borrows from terminology that is often used when thinking about finite state machines. In this conceptual model, each machine responds to input according to the state it happens to be in and outputs a response that is most appropriate for its current state. I don't find this too far afield from the problems angular is attempting to solve.

I wonder if the detractors of this semantic change might be more receptive to if rather than risk conflating terms that already have solidified meanings in other contexts (e.g. "input" in the context of HTML forms), we addressed the directionality of the flow of information instead of attempting to define it with a noun. Therefore what is now called "Input" would simply be "Inbound" and "Output" would be "Outbound". It's a subtle change, but one that I think strays from well understood connotations of those words and shifts the focus to directionality and the flow of data, which is really what we should be thinking about anyway.

I therefore propose:

@Inboud @outbound

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 11, 2015

Member

@Inbound / @Outbound seem like a reasonable proposals. Will flout it with the team to see what their thoughts are.

Member

mhevery commented Oct 11, 2015

@Inbound / @Outbound seem like a reasonable proposals. Will flout it with the team to see what their thoughts are.

@todoubaba

This comment has been minimized.

Show comment
Hide comment
@todoubaba

todoubaba Oct 12, 2015

Contributor

Why two words? Does @Outbound property and @Inbound event make sense?

Contributor

todoubaba commented Oct 12, 2015

Why two words? Does @Outbound property and @Inbound event make sense?

@alexpods

This comment has been minimized.

Show comment
Hide comment
@alexpods

alexpods Oct 12, 2015

My humble prediction: people will hate inbound/outbound even more than input/output...

My humble prediction: people will hate inbound/outbound even more than input/output...

@BlackHC

This comment has been minimized.

Show comment
Hide comment
@BlackHC

BlackHC Oct 12, 2015

Tbh, do you think that more renaming actually provides any benefit? I only
see marginal benefits from this compared to spending one's time on actual
feature work or real cleanups
On Sun 11 Oct 2015 at 17:40 Aleksey Podskrebyshev notifications@github.com
wrote:

My humble prediction: people will hate inbound/outbound even more than
input/output...


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

BlackHC commented Oct 12, 2015

Tbh, do you think that more renaming actually provides any benefit? I only
see marginal benefits from this compared to spending one's time on actual
feature work or real cleanups
On Sun 11 Oct 2015 at 17:40 Aleksey Podskrebyshev notifications@github.com
wrote:

My humble prediction: people will hate inbound/outbound even more than
input/output...


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

@jimthedev

This comment has been minimized.

Show comment
Hide comment
@jimthedev

jimthedev Oct 12, 2015

I disagree. Inbound and Outbound are superior because they indicate a flow
across a medium. Input and Output as properties seem more coupled to the UI
and an end user's interaction with that UI. Perhaps this is because of the
HTML input field. Inbound and outbound make it clear that a contextual
border is being crossed by something.
On Sun, Oct 11, 2015 at 7:40 PM Aleksey Podskrebyshev <
notifications@github.com> wrote:

My humble prediction: people will hate inbound/outbound even more than
input/output...


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

I disagree. Inbound and Outbound are superior because they indicate a flow
across a medium. Input and Output as properties seem more coupled to the UI
and an end user's interaction with that UI. Perhaps this is because of the
HTML input field. Inbound and outbound make it clear that a contextual
border is being crossed by something.
On Sun, Oct 11, 2015 at 7:40 PM Aleksey Podskrebyshev <
notifications@github.com> wrote:

My humble prediction: people will hate inbound/outbound even more than
input/output...


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

@alexpods

This comment has been minimized.

Show comment
Hide comment
@alexpods

alexpods Oct 12, 2015

@BlackHC I completely agree with you. Personally, I can perfectly live with property/event, attribute/event, input/output, inbound/outbound, thisName/thatName, foo/bar, whatever/whenever, and so on...
@jimthedev I didn't say that inbound/outbound are worse. I just expect another outbreak of anger. But I can be wrong.

@BlackHC I completely agree with you. Personally, I can perfectly live with property/event, attribute/event, input/output, inbound/outbound, thisName/thatName, foo/bar, whatever/whenever, and so on...
@jimthedev I didn't say that inbound/outbound are worse. I just expect another outbreak of anger. But I can be wrong.

@hsakkout

This comment has been minimized.

Show comment
Hide comment
@hsakkout

hsakkout Oct 12, 2015

Wittgenstein: "the meaning of a word is its use in the language"

Input and Output on a UI especially is commonly used differently to the
way it is being used here. That is not a cosmetic point.

Other terms that are not in conflict with standard UI terms do not have
this problem: @inbound/@outbound, @property/@event, @in/@out

It is wrong to say that people making this simple point are going to reject
terms with no prior misleading semantics. The only people left discussing
the issue once you've addressed this problem will be people who are
subjectively interested in Angular's style and taste (i.e. not 95% of the
people wasting their busy time here).

On Sun, Oct 11, 2015 at 9:45 PM, Aleksey Podskrebyshev <
notifications@github.com> wrote:

@BlackHC https://github.com/BlackHC I completely agree with you.
Personally, I can perfectly live with property/event, attribute/event,
input/output, inbound/outbound, thisName/thatName, foo/bar,
whatever/whenever, and so on...
@jimthedev https://github.com/jimthedev I didn't say that
inbound/outbound are worse. I just expect another outbreak of anger. But
I can be wrong.


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


Hani El-Sakkout
Chief Development Officer
Tradelegs LLC
(m) +1.617.852.7712 / (o) +1.347.878.7910
(AIM,Google Chat) hani@tradelegs.com (Zoom) https://zoom.us/j/6178527712,
audio +1-415-762-9988 Id: 617-852-7712

This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message. If you are the intended recipient, please be
advised that the content of this message is subject to access, review and
disclosure by the sender's Email System Administrator.

Wittgenstein: "the meaning of a word is its use in the language"

Input and Output on a UI especially is commonly used differently to the
way it is being used here. That is not a cosmetic point.

Other terms that are not in conflict with standard UI terms do not have
this problem: @inbound/@outbound, @property/@event, @in/@out

It is wrong to say that people making this simple point are going to reject
terms with no prior misleading semantics. The only people left discussing
the issue once you've addressed this problem will be people who are
subjectively interested in Angular's style and taste (i.e. not 95% of the
people wasting their busy time here).

On Sun, Oct 11, 2015 at 9:45 PM, Aleksey Podskrebyshev <
notifications@github.com> wrote:

@BlackHC https://github.com/BlackHC I completely agree with you.
Personally, I can perfectly live with property/event, attribute/event,
input/output, inbound/outbound, thisName/thatName, foo/bar,
whatever/whenever, and so on...
@jimthedev https://github.com/jimthedev I didn't say that
inbound/outbound are worse. I just expect another outbreak of anger. But
I can be wrong.


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


Hani El-Sakkout
Chief Development Officer
Tradelegs LLC
(m) +1.617.852.7712 / (o) +1.347.878.7910
(AIM,Google Chat) hani@tradelegs.com (Zoom) https://zoom.us/j/6178527712,
audio +1-415-762-9988 Id: 617-852-7712

This email message is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. Any unauthorized review,
use, disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all copies
of the original message. If you are the intended recipient, please be
advised that the content of this message is subject to access, review and
disclosure by the sender's Email System Administrator.

@montoyland

This comment has been minimized.

Show comment
Hide comment
@montoyland

montoyland Oct 12, 2015

@alexpods @BlackHC @hsakkout @mhevery

I think it's important to note that the people "wasting" their time on here belaboring what, in the larger scheme, appears to be such a trivial point, are not doing it out of some perverse need to be punctilious for its own sake, but because they care deeply about the tools they use in their daily work. For many, tools such as Angular will define how we will spend the better part of our day and we care deeply about this experience. We are all here because Angular established a new paradigm in a space formerly occupied with kludgy solutions.

I like to think of Angular as high performance sports car that is designed around a very specific goal. Angular is like a Ferrari in the sense that every design decision from the engine to the body is purposeful and informed by the problem it is attempting to solve. This is in contrast to something like a Yugo, that was manufactured to simply get one from point A to B in the most economic means possible. Coding may not be a glamorous endeavor, but the tools we use define our experience, and those of us who care about these details, do so because we feel that they may enhance our experience to the extent that coding may provide some thrills.

If there is one thing I appreciate about the Angular team is that they are never content with a solution that simply works. They are forward-thinking and want the best possible solution. They are not precious about whatever has come before and are willing to kill their own babies if it will lead to an improved solution. This mindset is what brought us Angular2 despite the already very capable solution they had previously released. Having kicked in the tires, I can say that the changes they made are not at all gratuitous, but arise from the overarching design goal to have a tool that is the best in its class. I think we all desire this and I don't think any of us would be developers if we weren't comfortable with the constant renewal that comes with the territory. I don't think there is single day where I am not learning something new. This is precisely what keeps it interesting and fresh, so lets not fear change, rather embrace it and the new possibilities it brings!

But back to the issue at hand: What I like about @inbound and @outbound is that gets away from defining what it is and shifts the focus to what it does. This is more in line with the way of thinking about the next generation of apps that eschew the traditional strict MVC approach in favor of a more dynamic model that relates to reactive programming. This paradigm has everything to do with data flows and propagation of change, and in this context, I find @inbound and @outbound to be more appropriate and to offer a more precise conceptual model that will be helpful in shaping the kind of problem solving required of programmers coming to Angular for the first time.

What is nice about this terminology is that it gets away from any potential impedance mismatch between the thing we are building, which may be impossible to define at the outset (it may or may not truly have inputs and outputs) and in a very unopinionated and non-prescriptive way, allows us to think of the flow of information, which will, predictively, always be part of the problem domain. By way of example, whether we are talking about salmon, traffic or enemy fire, if I apply the term "inbound" to any of these, it is quite clear what is meant, what the context is, and to make predictions about the outcome. While we can't say with confidence what people will be building with Angular, we can be sure that data propagation whether from the user, a robot or a web service, will change the state of the UI and these events will propagate in precise directions that need to be defined and captured by our app.

Try thinking about very different problems you've had to solve in the UI before and see if this usage applies... I think you'll find that it works and it's hard to find edge cases where it breaks down.

@alexpods @BlackHC @hsakkout @mhevery

I think it's important to note that the people "wasting" their time on here belaboring what, in the larger scheme, appears to be such a trivial point, are not doing it out of some perverse need to be punctilious for its own sake, but because they care deeply about the tools they use in their daily work. For many, tools such as Angular will define how we will spend the better part of our day and we care deeply about this experience. We are all here because Angular established a new paradigm in a space formerly occupied with kludgy solutions.

I like to think of Angular as high performance sports car that is designed around a very specific goal. Angular is like a Ferrari in the sense that every design decision from the engine to the body is purposeful and informed by the problem it is attempting to solve. This is in contrast to something like a Yugo, that was manufactured to simply get one from point A to B in the most economic means possible. Coding may not be a glamorous endeavor, but the tools we use define our experience, and those of us who care about these details, do so because we feel that they may enhance our experience to the extent that coding may provide some thrills.

If there is one thing I appreciate about the Angular team is that they are never content with a solution that simply works. They are forward-thinking and want the best possible solution. They are not precious about whatever has come before and are willing to kill their own babies if it will lead to an improved solution. This mindset is what brought us Angular2 despite the already very capable solution they had previously released. Having kicked in the tires, I can say that the changes they made are not at all gratuitous, but arise from the overarching design goal to have a tool that is the best in its class. I think we all desire this and I don't think any of us would be developers if we weren't comfortable with the constant renewal that comes with the territory. I don't think there is single day where I am not learning something new. This is precisely what keeps it interesting and fresh, so lets not fear change, rather embrace it and the new possibilities it brings!

But back to the issue at hand: What I like about @inbound and @outbound is that gets away from defining what it is and shifts the focus to what it does. This is more in line with the way of thinking about the next generation of apps that eschew the traditional strict MVC approach in favor of a more dynamic model that relates to reactive programming. This paradigm has everything to do with data flows and propagation of change, and in this context, I find @inbound and @outbound to be more appropriate and to offer a more precise conceptual model that will be helpful in shaping the kind of problem solving required of programmers coming to Angular for the first time.

What is nice about this terminology is that it gets away from any potential impedance mismatch between the thing we are building, which may be impossible to define at the outset (it may or may not truly have inputs and outputs) and in a very unopinionated and non-prescriptive way, allows us to think of the flow of information, which will, predictively, always be part of the problem domain. By way of example, whether we are talking about salmon, traffic or enemy fire, if I apply the term "inbound" to any of these, it is quite clear what is meant, what the context is, and to make predictions about the outcome. While we can't say with confidence what people will be building with Angular, we can be sure that data propagation whether from the user, a robot or a web service, will change the state of the UI and these events will propagate in precise directions that need to be defined and captured by our app.

Try thinking about very different problems you've had to solve in the UI before and see if this usage applies... I think you'll find that it works and it's hard to find edge cases where it breaks down.

@choeller

This comment has been minimized.

Show comment
Hide comment
@choeller

choeller Oct 12, 2015

Contributor

@montoyland @hsakkout

I'm not sure if this is just a personal issue of me, but I think it's still worth mentioning:

As a non native speaker the words @inbound & @outbound are not very clear too me - maybe as they are just not familiar and not part of my daily (technical) usage of english. Nevertheless I agree the solve the issue of not being connected with something like fields.

I personally pretty much like the suggestion of @hsakkout just naming it @in & @out

For me this would describe the interface-nature of the terms, would not collide with other terms and would be easily understood by non-native speakers.

@montoyland: +1 for your statement about why this discussion is worth spending our time here

Contributor

choeller commented Oct 12, 2015

@montoyland @hsakkout

I'm not sure if this is just a personal issue of me, but I think it's still worth mentioning:

As a non native speaker the words @inbound & @outbound are not very clear too me - maybe as they are just not familiar and not part of my daily (technical) usage of english. Nevertheless I agree the solve the issue of not being connected with something like fields.

I personally pretty much like the suggestion of @hsakkout just naming it @in & @out

For me this would describe the interface-nature of the terms, would not collide with other terms and would be easily understood by non-native speakers.

@montoyland: +1 for your statement about why this discussion is worth spending our time here

@montoyland

This comment has been minimized.

Show comment
Hide comment
@montoyland

montoyland Oct 12, 2015

@choeller @hsakkout @mhevery @BlackHC @alexpods

The difference is subtle - the English language can indeed be quite nuanced, so here is a practical example of why @in/out may not get us all the way there: Imagine you go a doctor's office. You are confronted with two doors. One is labelled "In", the other "Out". Imagine your confusion when you enter through the "In" door only to be chastised by the nurse for barging in without being called... "But, the sign..." you protest. When the patient who was being attended by the doctor when you interrupted, leaves through the "In" door, you suddenly realize that the sign had nothing to do with the semantic meaning you had assumed: that one should enter through one door and exit through the other. This wasn't a single office with two doors, but two separate doctor's offices and the sign merely indicated that one doctor was "in" while the other was "out" on leave. Doh!

Here is another example: You go to your favorite newsstand. There are two piles of newspapers, one is labelled "in" the other "out". What can you conclude about this? At first, (especially after the previous experience at the doctor's office) you might be inclined to believe that "in" means that the sign indicates that there are still copies of that newspaper available. However, if that were the case, you would expect "out" to be empty, and yet, it also has copies. When you inquire, the owner tells you that "out" is for placing copies of your old papers so that they may be properly recycled by the distributor.

It is not clear from these terms whether they are indicating a state (office is empty - i.e. property has a value) or a direction (come in through here). Inbound clears up this question because it is specific to flow and directionality and can't be confused with a state. I can envision many other usecases for this annotation: "in" may indicate that you wish a property to be included, or visible to the UI and "out" could mean it should be considered, but not included (like the difference between "hidden" and "visible" in CSS). Perhaps, in the context of the DOM, we may have several nested elements and we wish for something to be handled by the outermost parent... In sum, its reading is overly broad and can therefore be ambiguous, but "inbound" and "outbound" posses a unique specificity to the problem domain.

To drive home my point, imagine you are trying to hook up a patient to a dialysis machine. There is a tangle of tubes and you're unable to figure out what is what. Finally you identify labels that read "inbound" and "outbound". Based on this information alone, you'd likely be able to infer the right way to hook things up even if you had never encountered such a device before. But if you had found the labels "in" and "out" you may not be so sure. "In" where? His arm? The dialysis machine? Oops, your mistake just caused the patient his life! Game over, go straight to jail, do not pass go...

This works because the terminology inflects a context in the problem domain we are seeking to solve. The context above is that we have blood that needs to be purified by going into a machine and back out to the patient. It is therefore inbound to our machine (in essence, the UI, or business-end of our logic) and outbound back to the patient. You may argue that it could equally be interpreted as "outbound" from the patient and "inbound" back into his body (after all, the patient is king here, and should be given priority), but I would wager that this would not occur to most because the tubes belong to the machine. They are extrinsic to the patient and therefore, any reading would have to be construed in the context of the machine we are attempting to put together, of which the tubing are an integral part.

@choeller @hsakkout @mhevery @BlackHC @alexpods

The difference is subtle - the English language can indeed be quite nuanced, so here is a practical example of why @in/out may not get us all the way there: Imagine you go a doctor's office. You are confronted with two doors. One is labelled "In", the other "Out". Imagine your confusion when you enter through the "In" door only to be chastised by the nurse for barging in without being called... "But, the sign..." you protest. When the patient who was being attended by the doctor when you interrupted, leaves through the "In" door, you suddenly realize that the sign had nothing to do with the semantic meaning you had assumed: that one should enter through one door and exit through the other. This wasn't a single office with two doors, but two separate doctor's offices and the sign merely indicated that one doctor was "in" while the other was "out" on leave. Doh!

Here is another example: You go to your favorite newsstand. There are two piles of newspapers, one is labelled "in" the other "out". What can you conclude about this? At first, (especially after the previous experience at the doctor's office) you might be inclined to believe that "in" means that the sign indicates that there are still copies of that newspaper available. However, if that were the case, you would expect "out" to be empty, and yet, it also has copies. When you inquire, the owner tells you that "out" is for placing copies of your old papers so that they may be properly recycled by the distributor.

It is not clear from these terms whether they are indicating a state (office is empty - i.e. property has a value) or a direction (come in through here). Inbound clears up this question because it is specific to flow and directionality and can't be confused with a state. I can envision many other usecases for this annotation: "in" may indicate that you wish a property to be included, or visible to the UI and "out" could mean it should be considered, but not included (like the difference between "hidden" and "visible" in CSS). Perhaps, in the context of the DOM, we may have several nested elements and we wish for something to be handled by the outermost parent... In sum, its reading is overly broad and can therefore be ambiguous, but "inbound" and "outbound" posses a unique specificity to the problem domain.

To drive home my point, imagine you are trying to hook up a patient to a dialysis machine. There is a tangle of tubes and you're unable to figure out what is what. Finally you identify labels that read "inbound" and "outbound". Based on this information alone, you'd likely be able to infer the right way to hook things up even if you had never encountered such a device before. But if you had found the labels "in" and "out" you may not be so sure. "In" where? His arm? The dialysis machine? Oops, your mistake just caused the patient his life! Game over, go straight to jail, do not pass go...

This works because the terminology inflects a context in the problem domain we are seeking to solve. The context above is that we have blood that needs to be purified by going into a machine and back out to the patient. It is therefore inbound to our machine (in essence, the UI, or business-end of our logic) and outbound back to the patient. You may argue that it could equally be interpreted as "outbound" from the patient and "inbound" back into his body (after all, the patient is king here, and should be given priority), but I would wager that this would not occur to most because the tubes belong to the machine. They are extrinsic to the patient and therefore, any reading would have to be construed in the context of the machine we are attempting to put together, of which the tubing are an integral part.

@mhevery

This comment has been minimized.

Show comment
Hide comment
@mhevery

mhevery Oct 13, 2015

Member

We thought about inbound/outbound, but we ran into an issue:

@Component({
  inbounds: [...] // That sounds weird
  outbounds: [...] // That sounds weird

  // whereas

  inputs: [...] // sound reasonable in plural form. 
  outputs: [...]
})

So it looks like we are stuck with nouns.

Member

mhevery commented Oct 13, 2015

We thought about inbound/outbound, but we ran into an issue:

@Component({
  inbounds: [...] // That sounds weird
  outbounds: [...] // That sounds weird

  // whereas

  inputs: [...] // sound reasonable in plural form. 
  outputs: [...]
})

So it looks like we are stuck with nouns.

@johnpapa

This comment has been minimized.

Show comment
Hide comment
@johnpapa

johnpapa Oct 13, 2015

Contributor

People will get used to whatever name you call this. inputs and outputs are as good as any and can be explained.

Better to spend cycles on bigger problems :)

I saw we close this and move on.

Contributor

johnpapa commented Oct 13, 2015

People will get used to whatever name you call this. inputs and outputs are as good as any and can be explained.

Better to spend cycles on bigger problems :)

I saw we close this and move on.

@montoyland

This comment has been minimized.

Show comment
Hide comment
@montoyland

montoyland Oct 13, 2015

@mhevery

Yup, that is indeed awkward. Thank for your considering the possibility. I second @johnpapa 's motion to call it a day and move on...

Thanks for all the hard work!

@mhevery

Yup, that is indeed awkward. Thank for your considering the possibility. I second @johnpapa 's motion to call it a day and move on...

Thanks for all the hard work!

@jimthedev

This comment has been minimized.

Show comment
Hide comment
@jimthedev

jimthedev Oct 14, 2015

I'm cool with leaving it as input/outputs. One last thing I thought of last night: inflows / outflows. Still sounds a bit weird, but would disambiguate.

I'm cool with leaving it as input/outputs. One last thing I thought of last night: inflows / outflows. Still sounds a bit weird, but would disambiguate.

petebacondarwin added a commit to petebacondarwin/ng-forward that referenced this pull request Oct 15, 2015

petebacondarwin added a commit to petebacondarwin/ng-forward that referenced this pull request Oct 15, 2015

@aikeru

This comment has been minimized.

Show comment
Hide comment
@aikeru

aikeru Nov 11, 2015

Was this not driven in some part by Dart's Event type conflict?
#4322

Certainly seems like that conclusion could be drawn, given the timeline, comments and everything. I'm surprised Dart wasn't mentioned at all in this entire discussion.

aikeru commented Nov 11, 2015

Was this not driven in some part by Dart's Event type conflict?
#4322

Certainly seems like that conclusion could be drawn, given the timeline, comments and everything. I'm surprised Dart wasn't mentioned at all in this entire discussion.

@diwu1989

This comment has been minimized.

Show comment
Hide comment
@diwu1989

diwu1989 Sep 17, 2016

I'm learning Angular2 for the first time (having been a angular1 user).

I think naming these as explicitly @input and @output make teaching how to think about good component architecture really easy because people learning about component design for the first time can adjust to thinking in terms of in/out readily.

Thanks!

I'm learning Angular2 for the first time (having been a angular1 user).

I think naming these as explicitly @input and @output make teaching how to think about good component architecture really easy because people learning about component design for the first time can adjust to thinking in terms of in/out readily.

Thanks!

@Vips120

This comment has been minimized.

Show comment
Hide comment
@Vips120

Vips120 Nov 24, 2016

Vips120 commented Nov 24, 2016

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