Repository navigation
Proposal: Host Projection #7297
Description
Design: https://docs.google.com/document/d/1E_C9Dz9IyVRgeWmPu2RwTohoLREup9dkPDvL31ruZr0
Just copying the API here for ease of discussion:
app.ts:
@Component({
selector: 'my-app',
template: `
<input md-input class="my-class" (click)="window.alert(value)"
[(ngModel)]="value" [placeholder]="'First Name'">
`,
providers: [MdInput]
})
export class MyApp {
value: string = "Default Name";
}component.ts:
@Component({
selector: '[mdInput]',
renderAs: 'md-container', // See issue #6710
template: `
<div>{{placeholder}}</div>
<ng-host></ng-host>
`
})
export class MdInput {
// Using an @Input prevents the binding from being transfered to the
// <ng-host />
@Input('class') class_: string = "";
@Input() placeholder: string = "";
}Resulting DOM:
<my-app>
<md-container md-input class="my-class">
<div>First Name</div>
<input value="Default Value">
</div>
</my-app>Reacted by Adam Bradley
Activity
jelbourn commentedon Feb 26, 2016
cc @tbosch @mhevery
lacolaco commentedon Feb 26, 2016
Cannot this use case be solved by
TemplateRef?hansl commentedon Feb 26, 2016
Although it would be possible to do using a template, a native core solution would be better and perform better.
lacolaco commentedon Feb 26, 2016
I see. But I think we need something marker like
*ngIfif a directive can modify the DOM tree.e.g.
mhevery commentedon Jun 14, 2016
A fundemental problem of this proposal is where should binding and styling go? For example:
It is not cleare whether the
classandplaceholdershould be applied to the projected host or the generated host. This is the case forclassesproperties, attributes, bindings, and styles. So let's take a step back.The goal of this discussion is to allow wrapping an underlying element in a decorating component. A better way to think about it is:
With the above wrap around approach it is clear what goes where and which binding should be applied. The downside is that it is wordy. Our approach should be to take the correct behavior and simplify the wordiness. I suggest merging the two and using the
+symbol as a prefix.Therefore:
is short for:
And no new concepts have to be created.
Advantagas are:
+md-inputis a wraping the<input>.There is a requirement that the
md-inputwill probably need to set up listeners on the projected content. To acchieve that I propose that we allow decoration of theng-contentsuch as:Because the
<ng-content>is a static projection, all of the augmentations to the<ng-content>such as(change)andclasscan be computed statically without any runtime penalty.pkozlowski-opensource commentedon Jun 14, 2016
So I had a look at the initial and latest proposals and here are some thoughts.
To start with I feel like we are trying to drive change in the framework based on just one use-case. If you ask me I can't think of a use-case other than inputs for the "host projection" future. And we all know that designing API on just one use case is doomed to fail :-) So if anyone has different use-cases that would benefit from the mechanism discussed here it would be great to discuss those use-cases together.
Then, I completely agree with @mhevery that the initial proposal doesn't make it clear which attributes / bindings / event handlers go where. If I write
<md-input foo="bar" (focus)="doSth()">it is not clear at all which element will trigger(focus)event handler and what is going to happen with thefooattribute. In this sense the evolved proposal (let's put wordiness of it aside for now):is much better since it makes it clear what belongs where. At the same time it introduces new questions:
ngModelnow? On the<md-input>or<input>element?requiredetc.)? Disabled?<ng-content class="additional-class" (change)="doSomething()">when<ng-content>matches more than one element? Should the(change)handler be added to all the matching elements? The first one?So the new proposal makes certain things clearer and other things more confusing now. Based on this I would do more "soul searching" before implementing anything.
The last remark is about the proposed
+md-inputsyntax: my first gut-feeling reaction is that no of characters to type "saved" doesn't justify new syntax.At this point I'm not sure what the final solution for the "inputs case" should be but I think that it requires more thought before we can implement things.
pkozlowski-opensource commentedon Jun 15, 2016
Based on the discussion in this issue and chat I had with Jeremy / Misko we are not going to implement host projection as described here for now. The reasoning being:
Subscribing to events / binding to properties on
<ng-content>sounds like a valuable addition and we might explore this in a separate issue(s).thelgevold commentedon Jun 20, 2016
@pkozlowski-opensource @mhevery @hansl
I understand the challenges, but my primary concern about the current md-input approach is that it makes it very hard to add your own attributes to the input element, unless md-input adds an API around it to ferry inn custom attributes.
One specific example that comes to mind is forms integration.
The new forms directives are not platform directives, so it seems like integration with forms would require a dependency on forms from md-input to get access to
REACTIVE_FORM_DIRECTIVES. This seems undesirable in cases where you don't need forms.Sorry if I am missing missing something here, but with the current approach, what is the suggested integration strategy with forms from md-input?
Forms seems like a very common use case for md-input.
angular-automatic-lock-bot commentedon Sep 8, 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.