There is no way to access inputs or outputs of Components created by NgComponentOutlet

I’m submitting a … (check one with “x”)

[ ] bug report => search github for a similar issue or PR before submitting
[x] 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 There is no way to set @Inputs or subscribe to @Output events of the Component created by NgComponentOutlet.

Expected behavior I expect some to set values and to subscribe events.

What is the motivation / use case for changing the behavior? At least, we should have the same level of functionality as ViewContainerRef.createComponent() which is roughly the programatic equivalent of NgComponentOutlet. That function returns a ComponentRef<any> which provides an instance property that allows direct access to the class instance of the Component. The original feature request for NgComponentOutlet defined an event on the directive that would fire and pass this ComponentRef object after creation. This did not make it into the current implementation and I see no other alternatives to access inputs/outputs.

Supporting only Components with no inputs or outputs severely limits the usefulness of NgComponentOutlet.

• Angular version: 4.0.0-rc.1

[ybrodsky]

@meriturva struggling with this shit for 1.5 days now. Solved the same problem in React in 15 minutes, 1 google search and common sense.

[pkozlowski-opensource]

The ability to interact with inputs / outputs of the dynamically created component is obviously lacking in the current implementation of the ngComponentOutlet and there are reasons why we didn’t add it so far:

• there was no reliable way of setting inputs that are mapped / renamed - this got fixed in #46641
• there is no reliable way of subscribing to outputs are mapped / renamed - this should be trivial to add after #46641 landed
• we are not thrilled by the <ng-container *ngComponentOutlet="component; inputs:{name: 'foo'}; outputs:{select: onSelect}">

So at this point we can consider the inputs / outputs issues to be “solved” (even if more work is needed). This leaves us with the API design question.

As I’ve mentioned we are not excited about the proposed <ng-container *ngComponentOutlet="component; inputs:{name: 'foo'}; outputs:{select: onSelect}"> API. The main problem is that it represents inputs and outputs as keys on an object literal. This is not what we do in other framework APIs and it pretty much bypasses existing change detection mechanisms. The other problem is that we don’t support content projection.

An alternative approach would be to deprecate the ngComponentOutlet directive and have a dedicated tag in Angular (working name: ng-component), that could be used like:

<ng-component [this]="ComponentType" input1={{exp}} input2="static" (event)="doSth()">
    <div>
        projectable nodes
    </div>
</ng-component>

Advantages:

• dynamically creating a component becomes very similar to creating a regular component;
• interacting with inputs / outputs is identical to regular components;
• content projection can be supported.

Introducing such mechanism would require a bit more work but would offer better ergonomics and a more complete functionality.