Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

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

Conversation

@vsavkin
Copy link
Contributor

@vsavkin 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
Copy link
Contributor

@vicb 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
Copy link
Member

@mhevery 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
Copy link
Contributor

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

@vsavkin vsavkin force-pushed the vsavkin:rename_properties_events_into_inputs_and_outputs branch from 7ddaf9e to ef78fa3 Oct 1, 2015
@mary-poppins
Copy link

@mary-poppins mary-poppins commented Oct 1, 2015

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

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;}
@vsavkin vsavkin force-pushed the vsavkin:rename_properties_events_into_inputs_and_outputs branch from ef78fa3 to 4f8f4fe Oct 1, 2015
@choeller
Copy link
Contributor

@choeller 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
Copy link

@tapas4java tapas4java commented 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).

@PascalPrecht
Copy link
Contributor

@PascalPrecht 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
Copy link

@TommyM 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
Copy link
Contributor

@PascalPrecht 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
Copy link
Contributor

@choeller 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
Copy link
Contributor

@PascalPrecht 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
Copy link
Contributor

@choeller choeller commented Oct 1, 2015

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

@TommyM
Copy link

@TommyM 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
Copy link
Contributor

@choeller 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
Copy link

@endash 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
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
Copy link
Contributor

@johnpapa johnpapa commented Oct 1, 2015

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

@hsakkout
Copy link

@hsakkout 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
Copy link

@webteckie webteckie commented 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;
}
@timkindberg
Copy link

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

@blackxored
Copy link

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

@mhevery
Copy link
Member

@mhevery 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
Copy link

@timkindberg timkindberg commented Oct 11, 2015

@mhevery hmmm yeah. How about @HostAttr.

Others: @hostinput @HostOutput.

I also kind of liked @visible.

@BlackHC
Copy link

@BlackHC 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
Copy link
Contributor

@PascalPrecht 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
Copy link

@montoyland montoyland commented 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
Copy link
Member

@mhevery 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
Copy link
Contributor

@todoubaba todoubaba commented Oct 12, 2015

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

@alexpods
Copy link

@alexpods alexpods commented Oct 12, 2015

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

@BlackHC
Copy link

@BlackHC 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
Copy link

@jimthedev jimthedev commented 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).

@alexpods
Copy link

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

@hsakkout
Copy link

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

@montoyland
Copy link

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

@choeller
Copy link
Contributor

@choeller 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
Copy link

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

@mhevery
Copy link
Member

@mhevery 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
Copy link
Contributor

@johnpapa 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
Copy link

@montoyland montoyland commented 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!

@jimthedev
Copy link

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

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
Copy link

@aikeru 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
Copy link

@diwu1989 diwu1989 commented 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!

@Vips120
Copy link

@Vips120 Vips120 commented Nov 24, 2016

@angular-automatic-lock-bot
Copy link

@angular-automatic-lock-bot angular-automatic-lock-bot bot commented Sep 10, 2019

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 10, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.