Issue 1:
I was expecting when a child component becomes invalid, parent component should become invalid too

[x] bug report => search github for a similar issue or PR before submitting
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Parent form is valid even if child component is invalid, parent form should become invalid as well

http://plnkr.co/edit/6IEwagKr6fZaKY06QUWE?p=preview

There is no way to react on the parent form unless there is a separate output emitter to do the same.

Windows 10, lite-server

Angular 2.0.0

Browser: Chrome

Language: TypeScript 2.0.3 ES5

Issue 2:
Currently, when classes with decorators are used in an inheritance chain, the results are undefined.

Consider the following two components:

@Component({selector: 'a', inputs: ['metaFoo'])
class A {
@Input() fieldFoo;
metaFoo;
}

@Component({selector: 'b', inputs: ['metaBar']}
class B extends A {
@Input() fieldBar;
metaBar;
}

Currently, using component B in JIT mode does not cause an error, but only inputs fieldBar and metaBar will be understood by Angular. This is because the decorators result in properties being defined on the class functions, and those properties are subject to shadowing via prototypical inheritance. So B.annotations (where the @Component metadata lives) shadows A.annotations, and B.propMetadata (where the @Inputs live) shadows A.propMetadata.

If the @Input() fieldBar from B is removed, however, then B will have no property metadata, and so the lookup forB.propMetadata will reach A.propMetadata via the prototype chain and suddenly the fieldFoo input will become visible to Angular.

There is no provision in the spec for inheritance of decorator metadata. However, Angular could be made to support well-defined rules of inheritance for its own decorators.

Here is one set of rules which I believe covers most of the cases where users attempt to inherit components:

Class-level decorators (@Component and friends) have their metadata merged according to the merge rules:

Metadata objects are merged property by property.

For properties with primitive values, a subclass value, if present, overwrites a superclass value.

For properties with array values, the arrays are concatenated, superclass first.

If the subclass provides no value, the superclass value, if present, is used.

Property-level decorators (@Input, etc) on superclasses are included in compilation.

@Inputs with the same name on the superclass and subclass should have the same behavior as two @Inputs with the same name on the same class.

Applying these rules would change the behavior of the above example, so component B would have all 4 defined inputs recognized.

For JIT mode, this requires two changes to Angular.

First, the class-level decorators would be changed to check for metadata on the superclass, and perform the merging operation if present.

Secondly, the runtime compiler would need to consider superclass metadata when checking for property annotations.

For the AOT compiler, the semantics would have to be built into the compiler itself as the decorators don't execute during AOT compilation.