Issue 1:
I'm submitting a ... (check one with "x")

[x?] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Previous behavior

Using RC4, the following would work...

*ngIf="(searchResults | async)?.length > 0"

or

*ngIf="(searchResults | async)?.length == 0"

Current behavior

RC5 throws

TypeError: Cannot read property 'length' of null

This syntax does work in RC5

*ngIf="((searchResults | async) || []).length > 0"

and

*ngIf="((searchResults | async) || {}).length == 0"

What is the expected behavior?

The original RC4 behavior seems more intuitive, especially when checking .length == 0 since it did not evaluate until the observable returned.

Please tell us about your environment:

Angular version: 2.0.0-rc.5

Browser: [Chrome ]

Language: [TypeScript 1.9]

Issue 2:
I'm submitting a ... (check one with "x")

[x] bug report
[ ] feature request
[ ] support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

Per the component interaction docs [https://angular.io/docs/ts/latest/cookbook/component-communication.html], there are a few different ways to communicate between parent/child. However, there is an issue that arises when trying to use @output event emitters with recursive components (i.e. of the same type) - the @output emitter property is supposed to map to the listener on the parent; however, since the parent is of the same type, it can't do that (you get duplicate declaration errors).

A good example is a menu that has collapsible/nestable children - they're all of the same type.

Maybe I'm wrong but I'm having trouble of finding a way to do this.

Expected/desired behavior

The ability to set a listener target from the child, or alias/rename the output parameter. Basically, not have them have to map to the same property so that this method could be used with recursive types.

Reproduction of the problem

This isn't a bug as much as it is a design problem. I'm unsure how to use the other methods laid out, because they don't seem to match what I'm looking to do or are overly complex (and therefore frustrating) for something as simple as the equivalent of NG1's $emit.

Most options are parent->child flow, and I need child->parent

-Input bindings

-Input property change interception

-ngOnChanges

-Parent interacts with child via a local variable

The remaining child->parent options seem overly complex or impossible

-Parent calls a ViewChild (doesn't seem to work with recursive components since a component can't reference itself?)

-Parent listens for child event - This is the only child->parent direction communication that I can see (outside of the service option, below) and is outlined as impossible above.

-Parent and children communicate via a service -- Overly complex, and when it comes to referencing a chain of parents (think in the case of a nested menu structure), it becomes very difficult and you have to create an entire tracking system or something else complex to replace a simple event emitter.

What is the expected behavior?

...This is already a section above (you might edit your template)....

What is the motivation / use case for changing the behavior?

Nesting components into themselves is a common thing in user interfaces. Sometimes you need recursion; it makes sense to have child-parent signals/events/whatever work in an easy/intuitive way. @output bindings are awesome until rendered useless by this quirk :(

Please tell us about your environment:

Mac OSX 10.11.3

Angular version: 2.0.0-rc.1

Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

Language: [all | TypeScript X.X | ES6/7 | ES5 | Dart]