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

[vsavkin]

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]

@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]

@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.

[tbosch]

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 https://github.com/angular/angular/pull/4435#issuecomment-144567021.

[mary-poppins]

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

[choeller]

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]

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 https://github.com/angular/angular/pull/4435#issuecomment-144622404.

[0x-r4bbit]

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 https://github.com/angular/angular/pull/4435#issuecomment-144622404.

— Reply to this email directly or view it on GitHub https://github.com/angular/angular/pull/4435#issuecomment-144631430.

[tommyminds]

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.

[0x-r4bbit]

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]

@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 ;)

[0x-r4bbit]

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]

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

[tommyminds]

@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]

@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]

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.

[johnpapa]

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

[NathanWalker]

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

[mhevery]

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]

@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]

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]

<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.

[0x-r4bbit]

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 https://github.com/angular/angular/pull/4435#issuecomment-144837436.

[endash]

@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]

@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...

[PatrickJS]

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).

[choeller]

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]

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]

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).

[kasperpeulen]

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?

We are annotating some properties with @Input, so we are talking about a subset of all the properties, the properties that are allowed to let data flow into the component

[ericmartinezr]

We are annotating some properties with @Input, so we are talking about a subset of all the properties, the properties that are allowed to let data flow into the component

A good but unnecessary explanation that is implicit in @Property. I would totally add that to the documentation.

[kasperpeulen]

I don't think so. In itself, the @Property annotation is strange, because without this annotation, a property is still a property, if you see what I mean.

What you want to say, is not that this property is a property, you want to say it is a special property, a property that is part of the public api of the component.

An other way of saying that, is that this property allows data to flow into the component. Which is why I think this naming is intuitive.

[yjbanov]

Blocked by #3605

[vicb]

Blocked ? This has already been merged yesterday. We should probably close this PR ?

[mhevery]

adbfd29fd761135d51985564edcb4db7f8b6a26a

[choeller]

Wow, so this is really disappointing...

Just to recap the history of this thread:

@pkozlowski-opensource: ... Imo the previous naming was much more intuitive, so kind of sad that we havent had this discussion on gh...

@PascalPrecht: ...Please reconsider this change.

@johnpapa: ...input/output feels awkward to me while prop/event feels more natural.

a lot of other guys including me: the new syntax is not intuitive / too generic to us

@mhevery: we did it, because we think it explains how things work in Angular 2

@PascalPrecht: ...Is there still a chance to come up with an alternative naming? ... We should pull in as many community members as possible to collect good proposals

... some ongoing discussion ...

@mhevery: merged PR...

I don't say that my understanding is better than anyone others, but just the fact, that there was so much noise around this PR showed, that there should be room for further discussions - now just merging the PR IMO is a hit in communities face... When this is the idea of "community driven" and "let the community take part in the design process" I'm out... I don't really see the value of trying to contribute to these discussions

[jimthedev]

Community anecdote here in favor of the change. I gave a practice talk yesterday and got a question about events vs props from someone who had never worked with Angular 1, Angular 2, or React.

After I explained the difference, this person suggested that I refer to events and properties in my talk as Input and Output. I give the final version of the talk tomorrow but then can release the video showing how I explained it (in a perhaps poor manor) and how that lead to this person giving me this feedback. I'm considering whether or not to include the new language in my talk. Would like input on how likely it is that this will be in .38 so that I can make sure not to put anything anecdotal into the wild.

[NathanWalker]

After reading @mhevery explanation and thinking more about building components with that terminology in mind, I like the change now. Simple and easy to reason about to me.

[choeller]

@jimthedev I would definitely be interested in the way you explained the difference, as I'm still having a hard time fitting the terms in the context. Too me this still feels like it's not fitting the nature of a (web)component, but maybe I'm just too opinionated. So hearing about the POV of someone who never worked with Angular seems interesting though...

[mhevery]

@mhevery: merged PR... (https://github.com/angular/angular/pull/4435#issuecomment-144974290)

I was updating the reality of the situation. As you can see the merge adbfd29fd761135d51985564edcb4db7f8b6a26a was already in when the discussion was going on, it just was not reflected in the github.

So it is not like we have merged it in despite the difference in opinion. We merged it in, and then the discussion happened. Keep in mind that we merge many of such changes in all the time, an no on comments.

I understand that people have different opinions, and yes, we can have discussions about them, and if people make better suggestion we are happy to change. That is what Alpha is all about, try different things and learn from it. Yes, we can still change this if we have a workable alternative. Such alternative has not been presented which is self consistent with all existing issue we pointed out.

1. Word Property is overloaded. In ES6 property refers to property on a class. It is really confusing to annotate a class property with a @Property. Imagine having a discussion with your coworker and you say your class needs a property. Do you mean class property, or do you mean property property?
2. Word Public can not be used because it has different meaning in TypeScript. There are public properties in TypeScript which are different from the concept we are trying to convey.
3. Word Binding can not be used because all properties are bondable. In addition you don't have to have one (it could be a constant) and what the property refers to is not a binding but the value of the binding.
4. We need an adjective/word which says this property is special because it can accept data from the outside.

Naming is hard!

[vicb]

Word Property is overloaded

Not sure if this is a very strong argument. Input is also overloaded, it could refer to i.e. a form input. Also can I "output" (meaning display here) an "@Input" in a template ?

ATM I understand the arguments for both Input and Property but I tend to think that Property would be more easily understood by our end-users.

[todoubaba]

@vicb It means an inputable property of the Component class, so we can use [prop]="expr" to provide a value for the property.

[webteckie]

If there's such a split about this why not support both? Keep supporting @Property for backwards compatibility with developer sentiment. People can then have it both ways. Those who feel more comfortable with @Property can keep using that and those whole feel better about using the new terms can have at it! Is keeping both a hard problem to solve?

[otodockal]

@webteckie The worst is to support both! Developers should have consistent experience from the framework. Your proposal forces developers to learn more concepts how to do the same things.

[webteckie]

I am fine with the new. But there seems to be very strong opinions here for both sides and how do you deal with that?

[m1ch4ls]

I can't help it, but this reminds me: http://blue.bikeshed.org/

[endash]

Not every debate over an issue that is superficially trivial is bikeshedding. The flip side of "naming is hard" is that "naming is important."

[choeller]

@mhevery

So it is not like we have merged it in despite the difference in opinion. We merged it in, and then the discussion happened.

Ok - to be honest I didn't get that - to me it looked like there was a (mostly) objective and lively discussion going on, and you just merged no matter what. So sorry for misinterpreting.

Nevertheless I still have the feeling that quite a lot of people are not happy with the change and IMO especially the definition of the components interface is one of the most important topics when talking about developer ergonomics. So I think it would have been way better to discuss such a topic in public instead of just talking about it "in the office".

Keep in mind that we merge many of such changes in all the time, an no on comments.

Ok - but what does the mean in the end - to me it shows, that people are overall happy with the decisions, but really feel bad about this one... So IMO the solution should not be to just stay with it, but to think about why people are "going mad" at this one

Yes, we can still change this if we have a workable alternative.

So just to make that concrete - when releasing the change with the next alpha NONE of the existing examples would work any longer - when reverting it with the one afterwards people would also change all their examples again- I understand that alpha is about "trying out" things, but I don't understand why one would just do that by a personal feeling when there is a bunch of people that are now already affected by that...

Such alternative has not been presented which is self consistent with all existing issue we pointed out.

This argument is just not fair. People didn't even got a chance to participate in the process, and obviously a lot of people just liked "the old" syntax. So when the only possibility is "eat the new one or have another idea" thats just not an open discussion.

[alexpods]

@choeller

I still have the feeling that quite a lot of people are not happy with the change

But also there are some people who quite satisfied with the renaming. I'm also part of the community and I think input and output are more appropriate terms (Although I absolutely can live with property and event. For me the entire topic is bikeshedding).

when releasing the change with the next alpha NONE of the existing examples would work

Many of the existing examples are becoming obsolete with every alpha release. It's absolutely normal as Angular2 is in the pretty active development right now. It's much better to experiment around API and then choose the best one than to be stick to the very first invented API.

Consensus can be found only if both sides are seeking it. So maybe we all together will live for a while with the new terminology, gather all pros and cons for both sides and than choose the best one?

@mhevery For native elements "input" and "output" don't fit very well. For example

<div [title]="expr" (click)="expr"></div>

Every good web developer knows that <div> is the object of HTMLDivElement which has title property (not "input") and can dispatch click event (not "output").

[jimthedev]

Err I think you have those reversed. (click) is user input and bubbles up the tree, title is a data chunk that is flowing down the tree and eventually will be delivered to the user as visual output. On Sat, Oct 3, 2015 at 6:13 PM Aleksey Podskrebyshev < notifications@github.com> wrote:

@choeller https://github.com/choeller

I still have the feeling that quite a lot of people are not happy with the change

But also there are some people who quite satisfied with the renaming. I'm also part of the community and I think input and output are more appropriate terms (Although I absolutely can live with property and event. For me the entire topic is bikeshedding).

when releasing the change with the next alpha NONE of the existing examples would work

Many of the existing examples are becoming obsolete with every alpha release. It's absolutely normal as Angular2 is in the pretty active development right now. It's much better to experiment around API and then choose the best one than to be stick to the very first invented API.

Consensus can be found only if both sides are seeking it. So maybe we all together will live for a while with the new terminology, gather all pros and cons for both sides and than choose the best one?

@mhevery https://github.com/mhevery For native elements "input" and "output" don't fit very well. For example

<div [title]="expr" (click)="expr">

[alexpods]

@jimthedev No, (click) is output of the element. It's what you're getting from (out of) the element. $event variable (one more thing that must be renamed) have data of this output. Click is the end-user input, but you must think about data flow in you application, not end-user interaction.

[title] is the input. It's what you are passing to (into) the element.