Angular: Vorschlag: Möglichkeit zum Hinzufügen von Direktiven zu Hostelementen in der Komponentendeklaration erforderlich.

Ich entwickle derzeit einen großen Client und versuche daher, alle GUI-bezogenen Probleme in wiederverwendbare Angular2-Direktiven aufzuschlüsseln. Dies führt mich immer zu demselben Problem, wie James perfekt betont hat.
Das muss im Interesse einer guten modularen und dynamischen Architektur wirklich irgendwie funktionieren. Das Touch-Beispiel ist nur eines von vielen Szenarien, in denen dies erforderlich ist. zB Drag&Drop, Größenänderung beobachten, etc. etc. etc.
Habe ein weiteres Beispiel als Plunker gemacht:
https://plnkr.co/edit/J65THEMic0yhObt1LkCu?p=info

Besteht die Möglichkeit, dass diese Funktion bald hinzugefügt wird?

Hier ist eine StackOverflow-Frage dazu: http://stackoverflow.com/questions/37148080/use-angular2-directive-in-host-of-another-directive

@Andy1605 hast du jemals einen Weg gefunden? Aus diesem Grund habe ich während der RCs die Arbeit mit NG2 auf den Tisch gelegt. Würde es gerne wieder aufnehmen, aber dieses spezielle Problem hindert mich daran, erweiterbare UI-Muster zu erstellen.

Ich habe auch das Gefühl, dass Angular hier ein wesentliches Feature fehlt. Es sollte möglich sein, dass eine Komponente (mehrere) Attribut-Direktiven für ihren Host deklariert. Das nicht zu können, ist auch für mein Projekt ein großes Hindernis.
Weiß jemand, ob dies in Zukunft umgesetzt wird oder ob es Gründe gibt, warum dies nicht möglich ist?

Ich habe eine Lösung für dieses Problem (wenn auch für die Winkelversion 1) hier vorgeschlagen: https://github.com/angular/angular.js/issues/15270.

Meine Idee ist, anstatt nur die Möglichkeit zu haben, Direktiven hinzuzufügen, hätte das Kompilierungs-Framework einen neuen Erweiterbarkeitspunkt namens "hostTransforms" (im Fall von Angular 1, "nodeTransforms"), der Zugriff auf die unveränderte, ungefilterte Komponentendeklaration hätte und der ursprüngliche, unkompilierte Komponenten-Hostknoten, wann immer eine Komponente zum ersten Mal von dem Compiler angetroffen wird und zum Einfügen in das DOM vorbereitet wird. Auf diese Weise könnte ein Entwickler Komponenten-Dekoratoren mit benutzerdefinierten Eigenschaften erweitern und dann nodeTransforms verwenden, um diese benutzerdefinierten Eigenschaften in etwas zu konvertieren, mit dem das Angular Framework vertraut ist, kurz vor der Kompilierung. Beispiele finden Sie im Feature-Request-Thread.

Ich bin mit dem eckigen Quellcode besser vertraut als mit dem eckigen 2-Quellcode, daher bin ich mir nicht sicher, ob der Implementierungsprozess hier derselbe wäre. Aber da dies eine ziemlich beliebte Anfrage zu sein scheint, würde ich es gerne sehen, wenn sie entweder in angle 2 implementiert und zurückportiert oder in anglejs implementiert und vorwärts portiert wird (ist das eine Sache?).

+1

Ich muss zustimmen, eine Funktion, mit der wir dem Host beitragende Attributdirektiven hinzufügen können, wäre großartig. Ich weiß, dass ich eine solche Funktion jetzt verwenden könnte, um eine "eckigere" Methode zu implementieren, die meinen UI-Komponenten Drag / Drop-Funktionalität hinzufügt.

Wie wäre es mit dem Erstellen eines neuen Tags ähnlich dem von <ng-container> , mit dem Sie sie in der Vorlage der Komponente anstelle der Metadateneigenschaft host anwenden können? Etwas wie <ng-host [attributeDirective]> um anzuzeigen, dass die Direktiven der Hostkomponente hinzugefügt werden.

@jjstreet Ihr Vorschlag klingt ähnlich wie replace: true (offensichtlich nicht identisch, aber ähnlich), der vor einiger Zeit eingestellt wurde. Aber vielleicht wurde replace: true aus einem Grund eingestellt, der hier nicht zutrifft.

@pkozlowski-opensource Könnten wir diesbezüglich eine Antwort vom ng2-Team erhalten?

Ich bin bereit, dies zu erreichen. Ich habe die host-Eigenschaft vorgeschlagen, weil sie Zugriff auf den lokalen Bereich der Komponente hat und der Komponente selbst bereits Attribute hinzufügt. Direktiven scheinen eine natürliche Erweiterung dieses Verhaltens zu sein.

+1 Diese Funktion ist erforderlich, um sauberen und wiederverwendbaren Code in UI-Komponenten zu haben

+1

Könnten wir bitte eine Antwort vom ng2-Team dazu bekommen? Auch wenn es nur darum geht, zu sagen, dass Sie es nicht tun werden, oder zu sagen, dass es eine gute Idee ist, aber derzeit keine Priorität hat, würde ich gerne eine Art Input hören.

Dazu möchte ich einen weiteren Anwendungsfall hinzufügen. Es würde es ng2-mobx (https://github.com/500tech/ng2-mobx) ermöglichen, die Verpackungskomponente loszuwerden und viel sauberer auszusehen.

Das hätte ich auch gerne. Derzeit benötige ich es, um eine benutzerdefinierte routerLink Direktive zu erstellen. Ich würde gerne einen eckigen wiederverwenden und ihn einfach mit Parametern versehen, die von der mi-Direktive vorbereitet wurden.

Anstelle von <a [routerLink]="repeatedCodeToGetLink()"> hätte ich also <a [myRouterLink]> und es würde [routerLink] mit aufgelösten Parametern dynamisch anwenden.

Wirklich gespannt auf die Aussichten davon!

Das brauchen wir schon länger. Tatsächlich fragte ich vor einiger Zeit, bevor ich wusste, dass es ein offenes Problem dafür gab,

Ich habe ein ausführliches Beispiel dafür bereitgestellt, wie wir diese Funktion verwenden können, um https://github.com/angular/flex-layout/issues/162 zu lösen, das wir seit einiger Zeit geöffnet haben. ( Siehe Beispiel und Erklärung hier )

Wir freuen uns sehr über jedes Feedback, ich sehe, dass dieses Problem das dritthäufigste aller offenen Probleme in diesem Repo ist. Hoffentlich können wir dies in der nächsten Veröffentlichung oder früher sehen (Daumen drücken)!

/cc @tbosch @IgorMinar @mhevery @jelbourn @hansl @ThomasBurleson

@jjstreet Ich denke dein Vorschlag

<ng-host myDirective="foo"></ng-host> 

... würde gut zu einem anderen separaten Vorschlag passen, der vor einiger Zeit aus anderen Gründen gemacht wurde, als wir hier diskutieren.

Siehe https://github.com/angular/angular/issues/7297

Derzeit umgehe ich dies, indem ich der übergeordneten Komponente eine Direktive hinzufüge und dann mit dem @HostListener einen Listener im Host hinzufüge.

Übergeordnet.html
<my-component myDirective>

Komponente.ts
@HostListener('myEvent') handler() { // do stuff }

Aber es wäre sauberer, wenn wir Attribute direkt im Host hinzufügen könnten...

So bin ich damit umgegangen, aber ich denke wirklich, dass die Implementierung dieser Funktion von Grund auf die beste Lösung wäre.

• Vollständige Erklärung in meiner Stack Overflow-Antwort: http://stackoverflow.com/a/41650302/2959469
• TL;DR Siehe Plunker: https://plnkr.co/edit/TCagW8vOPrqSiOT9Oztf

Nur eine monatliche Erinnerung, dass wir auf positive oder negative Kommentare vom Angular-Team warten.

@tbosch - Alle öffentlichen Gedanken zur Priorität dieses Themas. Es wirkt sich auch auf @angular/flex-layout .

@fadzic können Sie die Direktive nicht einfach dem Host-Element hinzufügen, indem Sie dies tun ...

Komponente.ts
@HostBinding('attr.myHilite') myHilite = new myHiliteDirective()

oder so, wenn Sie Parameter wie ElementRef oder Renderer2 benötigen
@HostBinding('attr.myHilite') myHilite = new myHiliteDirective(this.elementRef, this.renderer)

Ich muss auch dem Host-Element eine Direktive hinzufügen und wurde auf dieses Problem umgeleitet. Ich konnte mit dem obigen Code tun, was ich brauchte. Ich bin in keiner Weise ein Experte im Umgang mit Angular, aber dieser Workaround scheint bisher zu funktionieren. Wenn jemand Probleme mit diesem Ansatz hatte, lassen Sie es mich wissen. Vielen Dank.

@btinoco das funktioniert nicht, weil keine Lebenszyklusmethoden aufgerufen werden. Sie müssten alles in jeder Komponente, die die Direktive verwendet, manuell verdrahten, anstatt es nur von Angular für Sie verdrahten zu lassen.

@hccampos danke für die ngOnInit meiner Direktive wurde nicht ausgeführt (es sei denn, ich verwende die Direktive in meiner Komponente manuell) oder ich rufe die Direktive ngOnInit() der Direktive auf ngOnInit() . Nochmals vielen Dank, dass Sie mich das wissen lassen.

@btinoco - ja. es ist ein subtiles, aber unangenehmes Problem. Eine, von der @angular/flex-layout hofft, dass sie bald behoben wird. ;-)

Gibt es dazu Neuigkeiten vom Angular-Team? 1 Jahr ist es her, dass das Thema geöffnet wurde...

Es war super cool, diese detaillierte Beschreibung zu diesem Thema zu finden.
dann kein Feedback vom Angular-Team zu finden war super uncool :(

Zu den bereits funktionierenden Lösungen:

Diese Funktionsanforderung klingt sehr nach Mixins. Tatsächlich Punkt Nr. 2 in der Beschreibung
dieser Funktion entspricht tatsächlich dem offiziellen
Dokumentation von TypeScript, siehe hier .
In Angular wird dies jedoch etwas schlimmer, als wenn Sie eine Klasse mit @Input() s mischen, Sie
müssen sie in der Basisklasse neu deklarieren.

Eine andere Lösung, die bereits heute funktioniert, wäre, die Komponente ein Wrapper-Element enthalten zu lassen und dort die Direktiven anzuwenden.
ZB wenn die Komponente eine Vorlage wie <wrapper g-touch>...

Bezüglich "Erstellen einer Hilfsfunktion, die dies über einen Dienst direkt auf elementRef.nativeElement tut":
Ja, das scheint auch eine gute Idee zu sein. WebWorker würden mich jetzt nicht interessieren,
da sie noch experimentell sind und einige größere Funktionen für die Produktion fehlen,
und fast keine Bibliothek da draußen würde mit WebWorkern funktionieren.
Siehe zB auch unsere Materialbibliothek, die direkt auf das DOM zugreift.

Zu Option 1) des Vorschlags:

Die aktuelle Semantik für Host-Eigenschaftenbindungen lautet:
dass sie eine Eigenschaft myDir für das zugrunde liegende HTML-Element setzen,
aber keine Direktive. Wenn host jedoch auch Direktiven einführen kann, könnten Benutzer Folgendes schreiben:
und wäre verwirrt, warum dies die Eigenschaft in der Direktive myDir nicht aktualisiert:

@Component({
  host: {
    '[myDir]': true
  },
  template: '...'
})
class MyComp {}

Zu Option 1) und Option 3):
Die Einführung einer Art von host Bindungen zwischen Direktiven für dasselbe Element kann:

• zu einem Zyklus im Datenbindungsgraphen führen, der von Angular nicht unterstützt wird, und daher
  führen zu schwer zu debuggenden Fehlern aufgrund veralteter Werte / Fehler "Ausdruck hat sich nach Überprüfung geändert".
• führen zu zusätzlichem Perf-Overhead im Vergleich zu Anweisungen, die sich gegenseitig injizieren
  und direkt kommunizieren.

Zu Option 2) des Vorschlags:

• Ja, auf die Klasse gTouch verweisen zu müssen, erscheint seltsam, wie alle anderen Anweisungen
  werden über NgModule s ausgelöst.

@ThomasBurleson lassen Sie uns offline

@tbosch Ich möchte eine andere Option vorschlagen: Angular- Tag ein, nennen wir es <ng-host> .

Hinweis: @mhevery hat die Einführung eines <ng-host> Tags in https://github.com/angular/angular/issues/7546 vorgeschlagen , obwohl ich hier denselben Tag-Namen verwende, was ich bin Der Vorschlag ist separat und soll speziell das hier angesprochene Problem ansprechen.

Das Tag ng-host würde nicht als reguläre Direktive/Komponentenklasse implementiert, sondern wäre stattdessen "magischer" Framework-Code ... ähnlich wie ng-content , ng-container usw.. .,
Das Tag würde einfach als "Zeiger" auf den Komponentenhost dienen, analog zum css- Selektor :host .

Es vermeidet mehrdeutige Szenarien, jede Komponente darf höchstens einen <ng-host> Block haben und es müsste das Root-Tag/der Root-Knoten des Templates dieser Komponente sein.

So würde man es verwenden:

// Option 5: Use `<ng-host>`.. Very declarative and intuitive
@Component({
  selector: 'g-btn',
  template: `
    <!-- 
      Besides comments, having dom code inside the template but outside of a declared 
      ng-host code block would raise an error (hopefully at compile-time) .
    -->

    <ng-host role="button" g-touch> 
      <ng-content></ng-content>
    </ng-host>
  `
})

Übrigens @tbosch , geantwortet habt. Wir freuen uns sehr über Ihr Engagement und Ihr Feedback zu diesem Thema.

Sind die Meinungen aller anderen zu dieser Funktionalität spezifisch für Komponenten oder wäre es auch sinnvoll, wenn eine Direktive eine andere Direktive auf ihren Host anwenden könnte? Der Anwendungsfall, den ich für dieses Problem abonniert habe, beinhaltete einige Direktiven von Drittanbietern, die A) von unserem Code isolieren wollten, falls wir später etwas ändern wollten, und B) wollten einige Standardfunktionen auf jede Instanz anwenden, ohne sie duplizieren zu müssen das Setup jedes Mal, wenn wir es benutzt haben.

Zum Beispiel eine Tooltip-Direktive, die auf eine große Anzahl von Elementen in unserer gesamten Anwendung angewendet wird, und wir möchten die Verzögerung und appendToBody als Standard festlegen (sie unterstützt kein zentralisiertes Konfigurationsobjekt). Da es kein zentrales Konfigurationsobjekt unterstützte, mussten wir drei oder vier Attribute überall dort platzieren, wo wir es verwenden wollten. Und später haben wir uns von dieser Bibliothek entfernt (begonnen mit der Verwendung von Material-Tooltips) und mussten jeden Tooltip manuell ersetzen. Wären wir in der Lage gewesen, unsere eigene Direktive zu erstellen, die sie "umhüllte", wäre es so einfach gewesen, diese Direktive zu ändern, um [mdTooltip] auf ihren Host anstelle der anderen Bibliothek anzuwenden.

@MikeMatusz Sieht so aus, als hätte ich das auch im Hinterkopf, hier ist mein Ausschnitt von https://github.com/angular/flex-layout/issues/162#issuecomment -290350270.

@Directive({
  selector: 'fxLayoutFullPage',
  hostDirectives: [LayoutDirective],
  host: { 
    'fxLayout': 'column', 
    'style': 'min-height:100vh; background-color:yellow'
  }, 
}) class LayoutFullPageDirective {}

Wäre es möglich, einen Property-Decorator zu erstellen, der eine Direktive instanziiert?
Zum Beispiel:
@HostDirective(LayoutDirective) myLayoutDirective: LayoutDirective;

Dies würde sowohl für Komponenten als auch für Direktiven funktionieren, eine Instanzreferenz für die Interaktion bereitstellen und würde beim Vererben von der Komponente/Direktive nicht verloren gehen.
Ich denke, es wird komplizierter, wenn Sie auch Eingabe- und Ereignisbindungen bereitstellen möchten.

Wo steht das? Ich bin ziemlich neu bei Angular2/4 und möchte eine Direktive erstellen, die nur mehrere andere Direktiven gleichzeitig anwendet. Also statt:

<button directiveA directiveB directiveC>BUTTON TEXT</button>

Ich kann nur schreiben:

<button customDirectiveABC>BUTTON TEXT</button>

Fühlt sich an, als ob dies einfach sein sollte - grundlegende Zusammensetzung / Trockenheit. Aber soweit ich das beurteilen kann ist das nicht möglich?

Siehe auch https://github.com/angular/flex-layout/issues/76#issuecomment -310509013

@soynog , mir geht es genauso. Ich würde auch gerne wissen, wo das steht.

Ich hatte gehofft, ziehbare Dialoge mit Angular Material und angle2-dragable erstellen zu können (da angle/material#1206 noch nicht unterstützt wird), wo ich dynamisch eine Direktive zu md-dialog-container hinzufügen möchte, die MdDialog Dienst erstellt, aber es scheint viel schwieriger zu sein, hier das Verhalten des Angular 1.x-Compilers für dynamische Direktiven zu erhalten.

@tbosch , @ThomasBurleson , war der Offline-Anwendungsfall, den Sie im Zusammenhang mit den Problemen oder Zielen besprochen haben, die Thomas in angle/material#1206 zufällig angesprochen hat? Ich versuche nur, mich mit den Verhaltensänderungen zwischen den Frameworks 1.6.x und 2+ auseinanderzusetzen.

Gibt es Updates zu diesem Thema? Es hat am Anfang an Zugkraft gewonnen, aber ich denke, es wird nicht mehr beachtet.

Jup ein Update dazu?

Das ist etwas, was ich so dringend brauche, hoffe, dass dieser Vorschlag seinen Weg flussaufwärts findet.

Das wäre schön, habe heute festgestellt, dass ich Direktiven nicht programmatisch/dynamisch anwenden kann, wurde traurig.

+1
Gleiche für mich :)
Ich suche nach einer Möglichkeit, mehrere Direktiven in eine benutzerdefinierte Direktive einzuschließen, die alles tut, was ich brauche. Zum Beispiel :

<my-cmp [myDirective]="content"
        [isOpen]="myCondition"
        customProp2="customClass"
        customProp1="customText">
 ...
</my-cmp>

Es wäre schön, wenn ich eine Direktive erstellen könnte, die all diese Dinge umschließt, damit ich sie wiederverwenden kann, ohne alle Zeilen kopieren / einfügen zu müssen.

<my-cmp myCustomDirective>
</my-cmp>

Und in meine benutzerdefinierte Direktive

<ng-host [myDirective]="content"
        [isOpen]="myCondition"
        customProp2="customClass"
        customProp1="customText">
</ng-host>

kommt zum zweiten Jahrestag dieser Ausgabe! Ehrlich gesagt wäre diese Funktion so nützlich, dass wir hochgradig zusammensetzbare Komponenten und Direktiven erstellen können, ohne eine Million Wrapper erstellen zu müssen. Stellen Sie einfach die Komponente, die Sie benötigen, aus den Anweisungen zusammen, die Sie haben. einfach, sauber, effektiv.

@IgorMinar - Wie auch immer, können wir diese Funktion für bevorstehende Verbesserungen auf den Radar bringen?

Ich würde gerne wissen, ob ein solches Feature als schlechtes Muster angesehen wird oder nicht. Jeder?

@darkbasic - AFAIU, ohne diese Funktion müsste ein Entwickler ein Wrapper-Element (auf ng-container ) einführen, um der Vorlagenansicht und dem Inhalt übergeordnete Direktiven hinzuzufügen.

Nein, ich glaube nicht, dass es ein schlechtes Muster ist, die volle Kontrolle über Ihre eigene Komponente zu haben, ohne Wrapper verwenden zu müssen. Es ist eine Notwendigkeit.

@bradlygreen irgendein Kommentar?

Dieses Feature ist die beliebteste Anfrage (wenn nicht sogar die Top 5) unter allen offenen Themen dieses Repositorys ... Im Internet sehen wir Berichte (unterstützt durch empirische Daten) über den Niedergang von Angular als defacto-Framework ... denke ich Einer der Gründe dafür ist das Gefühl, dass die Community nicht gehört wird. Der Wettbewerb; vue.js und reagieren, sind auf dem Vormarsch und haben den Winkel überholt, denn obwohl sie nicht unbedingt jede Kleinigkeit implementieren, die jeder will, geben sie zumindest kontinuierliches Feedback zu den am häufigsten angeforderten Elementen. Es ist so frustrierend, so lange zu warten und nichts zu hören.. nicht einmal ein einfaches "Nein, das machen wir nicht".

(Siehe Abschnitt "Winkelgleiter" Js-Frameworks )

... obwohl ich denke, dass manche Meinungen zu Angular / Vue / React / ... von verschiedenen Faktoren beeinflusst werden ... dieses konkrete Feature wäre wirklich eine Umsetzung wert (auch die Umstände sind etwas komplizierter als nur ein Lösung mit einer einfachen Liste angewandter Richtlinien) ... daher wäre die konkrete Position des Angular-Kernteams sehr willkommen ... 🥇

Keine spezifische ETA, aber wir arbeiten daran, diese Kategorie von Dingen im Renderer im Jahr 2018 viel einfacher zu machen.

Hoffentlich wird es 2018 drastisch besser. Wir verlieren

Sehen:

• https://www.businesswire.com/news/home/20180104005052/en/npm-Report-State-JavaScript-Reveals-Popular-Web
• https://medium.com/@chriscordle/warum -angular-2-4-is-too-little-too-late-ea86d7fa0bae

@somombo dieser Artikel wurde vor langer Zeit als Bullshit bestätigt

Leute, die sich wirklich auskennen, haben sich über den Autor lustig gemacht und keiner von ihnen hat ihn ernst genommen, die Likes sind natürlich von React, Vue Fanboys.

Tatsache ist also, dass dieses Thema hier für das Winkelteam eine sehr niedrige Priorität hat, tatsächlich hat es die niedrigste Priorität.

Siehe veröffentlichte Prioritätenliste bei AngularHQ (

Dies ist der Fall, obwohl dieses Thema viel Diskussion und Interesse in der Community hervorgerufen hat, wie die Anzahl der Kommentare zeigt.

Wenn Sie jemand sind, der sich für dieses Thema interessiert und es wirklich gerne implementiert sehen möchte, dann können Sie, anstatt darauf zu warten, _möglicherweise nie_, vielleicht die offizielle jährliche Angular-Umfrage ausfüllen und kundtun, dass Sie sich für dieses Thema interessieren sollte eine höhere Priorität haben und würde es begrüßen, wenn sie eher früher als später erfüllt wird.

Vergessen Sie nicht, unserem Angular-Team für die großartige Arbeit zu danken, die es geleistet hat!

Auch für diese Funktion möchte ich meine Stimme abgeben. Dies war die Ursache für zu viel Kummer bei dem Versuch, dieses Problem zu umgehen.

@somombo bitte lesen Sie noch nicht zu viel in die Priorität in AngularHQ. die Prioritätsformel ist nicht vollständig ausgearbeitet. Trotzdem denke ich, dass wir diese Funktionsanfrage nach der Auslieferung von v6 erneut aufgreifen sollten. Ich befürchte, dass wir nicht früher die Bandbreite dafür haben und die Arbeit daran mit einer bereits laufenden Arbeit im Compiler/Core-Bereich kollidieren würde.

Dies ist keine schnelle Lösungsanfrage. Ich vermute, dass es einen beträchtlichen Aufwand erfordern wird, es richtig zu machen, aber die Dinge, an denen wir für v6 arbeiten, sollten die Implementierung viel einfacher machen.

@IgorMinar die Ivy-Arbeit macht dies machbarer. Aber ja nach v6.

@IgorMinar und @mhevery Ich kann nicht genug betonen, wie dankbar ich (und wir anderen, da bin ich mir sicher auch) dafür bin, dass Sie uns dieses konkrete Feedback dazu gegeben haben, was Ihre Gedanken sind und was zuerst passieren muss, bevor diese Ausgabe kann richtig angesprochen werden.

Uns Laien ist nicht immer klar, was eine "schnelle Lösung" ist und was nicht. Abgesehen davon, dass dies keine schnelle Lösung ist und richtig gemacht werden muss, bin ich besonders dankbar, dass Sie anscheinend auch der Meinung sind, dass dies eine nützliche Funktion für Angle sein wird.

Wir wissen, dass Sie beide sehr beschäftigt sind und nicht auf jedes einzelne Problem so reagieren können.
Daher gilt Ihnen unser aufrichtiger Dank, wann immer Sie es tun. Wir sind gespannt und freuen uns auf eckige v6 und darüber hinaus!

Vielen Dank für die ganze tolle Arbeit!

Sie können Ihre Komponentenklasse die Direktivenklasse erweitern oder implementieren lassen. Wenn Sie versuchen, die Direktive unter der Haube anzuwenden, sollte es wahrscheinlich nur Logik in der Komponente sein.

export class gBtn extends gTouch

@NateMay , mit dem Sie nur eine einzelne Klasse erweitern können. In diesem Thema geht es mehr um die Zusammensetzung mehrerer Funktionalitäten mithilfe von Direktiven.

@NateMay zwei Probleme damit - erstens können Sie nur eine einzelne Klasse erweitern, und zweitens haben Sie gerade die Abhängigkeitsinjektion abgebrochen.

Addiere nur meine zwei Cent. Ich baue ein mehrschichtiges SPA mit Winkel-, Material- und Flex-Layout, indem ich verschachtelte Zustände von @uirouter/angular verwende. Dann ist die Unfähigkeit, Flex-Direktiven einfach auf Komponentenelemente anzuwenden, sehr einschränkend.

Also bitte eine Stimme für diese Funktion.

+1 für diese zusätzliche Funktion

Es ist möglich, einem ng-container eine Direktive hinzuzufügen, die nicht im DOM erscheint.

Ich brauchte dies für die Schnittpunkt-Beobachter-API (die Ereignisse auslöst, wenn Elemente das Ansichtsfenster betreten/verlassen). Ich habe eine intersector Direktive, die enter() und leave() Ereignisse enthält, wenn das Element sichtbar/ausgeblendet wird. Ich habe bestimmte Komponenten, die diese API intern verwenden müssen, aber ich wollte kein zusätzliches DIV in der Vorlage hinzufügen.

Ich habe also Folgendes in component.html :

<ng-container intersector (enter)="weCameOnScreen()" (leave)="byeBye()">
     ... components normal template ...
</ng-container>

Dann injiziert der intersector.directive.ts Direktivenkonstruktor das ElementRef .

    constructor(private intersectorElementRef: ElementRef) { ... }

Für ein normales DOM-Element würden Sie einfach auf intersectorElementRef.nativeElement operieren, aber für ein ng-container der Knoten eigentlich ein Kommentarknoten. Also überprüfe ich einfach, ob es ein Kommentar ist, und wenn ja, dann gehe ich eine Stufe höher.

public ngAfterViewInit(): void 
{
    // if the directive is applied to an ng-container must go a level up
    this.domElement = (this.intersectorElementRef.nativeElement.nodeType == 8) ? this.intersectorElementRef.nativeElement.parentElement : this.intersectorElementRef.nativeElement;

   registerIntersector(this.domElement ...);

Das wird nicht für alle Situationen funktionieren, aber ich bin damit im Moment in Ordnung. Ich glaube, dass sie im IVY-Compiler möglicherweise keine Kommentare mehr verwenden - daher kann dies kaputt gehen. Das Wichtigste war, dass ich eine einzige Direktive habe, die ich auf DOM-Knoten oder in einer Art Fake " @HostBinding " für die Direktive verwenden kann.

Ich hatte wirklich gehofft, dass es möglich ist, Direktiven dynamisch hinzuzufügen. Ich möchte in der Lage sein, Direktiven auf niedrigerer Ebene in "höhere Ordnung", abstraktere Direktiven zu kapseln. Ich habe folgende Frage zum Stack Overflow gestellt und mich gefragt, ob es dafür in Zukunft eine Lösung geben wird: https://stackoverflow.com/questions/51608645/abstract-away-leaflet-directive-in-custom-directive

wie @mhevery sagte.. wir müssen geduldig sein und warten, bis die vollständige Version ivy (ng v7.0.0 ?) landet. Anscheinend wird es für sie mit ivy viel einfacher zu implementieren sein... Nach ivy müssen wir das Team daran erinnern, wie wichtig uns dieses Feature ist, damit sie es nicht vergessen 😉

Diese abonnieren. Ich muss auch in der Lage sein, eine Direktive dynamisch an eine Komponente anzuhängen, die ich mitresolutionComponentFactory/createComponent erstellt habe.

const componentFactory = this.componentFactoryResolver.resolveComponentFactory(componentItem.component);

const componentRef = viewContainerRef.createComponent(componentFactory);
(<DynamicComponent>componentRef.instance).data = componentItem.data;
(<DynamicComponent>componentRef.instance).cssClassList = componentItem.cssClassList;
// Add directive to new component here
// componentRef.addDirective(someDirective)

Irgendein Update???
Ich bin auf einen anderen Anwendungsfall gestoßen, in dem ich die Direktive von Drittanbietern verwende.
In einigen Szenarien muss ich eine Direktive für ein HTML-Element dynamisch entfernen/hinzufügen.
ist das irgendwie möglich oder steht die lösung noch aus?

@micronyks ... eigentlich ist es nicht möglich, eine Direktive dynamisch hinzuzufügen. Wir müssen auf Ivy warten, der die Möglichkeit hinzufügen sollte, ein solches Feature zu erstellen.

@mlc-mlapis aber irgendein Plan, wann kommt IVY? in welcher Ausführung?

@micronyks ... Angular 7 nach Zeitplan.

Leute, lasst uns hier vernünftig sein, das Angular Team versucht hart, an mehreren großen Funktionen zu arbeiten, die sehr gefragt sind (PWAs, SSR, Ivy und insbesondere Custom Elements), wobei das letzte Feature eine sehr hohe Priorität hat, wie ich verstehen konnte, weil viele der großen Unternehmen (wie Microsoft) fragen schon immer danach, und dafür gibt es einen Grund. Um effiziente benutzerdefinierte Elemente zu erzielen, benötigen sie Ivy, sobald sie mit Ivy fertig sind, wie @mhevery sagte, wird die Engine dynamische Direktiven einfacher zulassen.

In der Zwischenzeit können wir dem Angular-Team helfen, den Prozess zu beschleunigen, indem wir die Betas testen, Fehler melden, bei der Dokumentation helfen usw.

Denken wir daran, dass Angular Team nicht einmal so groß ist, es sind nur ein Dutzend Leute, die versuchen, ein großartiges Framework für alle zu erstellen, aber das braucht Zeit.

... ja, es ist jetzt notwendig, etwas Geduld zu haben und bis zu dem Moment zu warten, an dem wir mit Ivy mehr helfen können ... wenn der Compiler fertig ist und einige Detaildesign-Dokumente verfügbar sind.

@avatsaev Ich kann allem zustimmen, was du gesagt hast. Hier drinnen sollte man nichts fordern. Aber Sie können die Probleme erklären, mit denen Sie bei der Arbeit mit Angular zu tun haben.

Ich bin bei weitem kein sehr erfahrener Angular-Entwickler, aber einige Dinge fühlen sich falsch an oder werden nicht klar genug erklärt.

Ich bin auf dieses Problem gestoßen, weil ich eine Komponente / Direktive eines Drittanbieters kapseln möchte, ohne eine undichte Abstraktion zu haben. Dazu gehört auch, dynamische Direktiven zu ermöglichen. Was mich überrascht, ist, dass es ziemlich kompliziert ist, so etwas zu erreichen.

Ich baue einen Formulargenerator mit Angular Material und Flex-Layout, der eine JSON-Konfiguration verwendet und ein Formular generiert. Diese Funktion würde mir helfen, die flex-layout-Anweisungen zur Laufzeit auf die Hostkomponente anzuwenden. Ich glaube, einer der größten Vorteile von Angular ist die Möglichkeit, Code zur Laufzeit aus einer Konfiguration zu generieren. Dies wird einen großen Beitrag dazu leisten, diesen Code vielseitiger zu machen. Wollte nur einen guten Anwendungsfall reinwerfen. Ungeduldig ;)

Das ist mein genauer Anwendungsfall

@NateMay hier ist meine Implementierung, wenn Sie sie ausprobieren möchten .

@NateMay hier ist meine Implementierung, wenn Sie sie ausprobieren möchten .

könnten Sie bitte erklären? Du meinst wohl dynamic-field.directive

Das dynamic-field.directive macht die ausgefallenen Sachen, aber es passiert auch eine Menge anderer Sachen. Ich habe gerade CONTRIBUTING.md im Stammordner hinzugefügt, der Anweisungen zum lokalen Einrichten enthält. Seien Sie vorsichtig bei der Verwendung in allem, was seit ein paar Monaten in Produktion ist. Ich nehme große Veränderungen vor, während ich auf eine stabile Implementierung hinarbeite.

+1

Bei weitem sind meine Workarounds, sie haben alle Nachteile.

1. has-it , definiere neu eine Member-Eigenschaft als diese Direktive in meiner Komponentenklasse, übergebe alle benötigten Konstruktorargumente an diese Direktive, wenn ihre Konstruktorfunktion aufgerufen wird (z. , und rufen Sie seinen Lebenszyklus-Callback manuell auf, wenn dies der Fall ist, z. B. ngInit() ngAfterViewInit() bei der entsprechenden Lebenszyklus-Callback-Funktion der aktuellen Komponente.

@component(...)
class MyComponent {
   theDirective: TargetDirective;
   constructor(el: ElementRef) {
       this.theDirective = new TargeDirective(el);
   }

  ngOnInit() {
     this.theDirective.ngOnInit();
  }
  ...
}

1. Verpacken Sie alles in der Komponentenvorlage in eine ng-Vorlage der obersten Ebene,
   <ng-template><div targetDirective>....</div></ng-template> rendern sie in ngAfterViewInit() wie:

const vf = this.viewContainerRef.createEmbeddedView(this.templateRef);
vf.detectChanges();

Auf diese Weise erstellt Angular ein weiteres element mit dieser Direktive und dem tatsächlichen Inhalt meiner Komponente darin direkt nach dem ursprünglichen Komponentenelement im DOM-Baum.

<my-component></my-component>
<div targetDirective>....</div>

Dieser Weg ist wie das, was <route-outlet> tut.

Es gibt offensichtliche Nebenwirkungen

Kann mir jemand bestätigen, ob dies jetzt mit Ivy möglich ist? Wenn ja, hat jemand ein Beispiel?

Denken wir daran, dass Angular Team nicht einmal so groß ist, es sind nur ein Dutzend Leute, die versuchen, ein großartiges Framework für alle zu erstellen, aber das braucht Zeit.

Es könnte größer sein, wenn Sie eine Gemeinschaft von Mitwirkenden haben.

Die Wahrscheinlichkeit, dass ein beigetragener Fix dafür akzeptiert wird, ist jedoch sehr gering.

Stattdessen sind wir wieder bei einem Dutzend Leuten.

Kann mir jemand bestätigen, ob dies jetzt mit Ivy möglich ist? Wenn ja, hat jemand ein Beispiel?

Da ich noch kein Wort habe, dachte ich, ich würde das nächstgelegene liefern, was ich finden konnte, ein Artikel von vor einiger Zeit über die Implementierung von Mixins mit Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -und-mixins-with-angular-ivy-75748fcbc310

Laut Artikel denke ich, dass eine mögliche Lösung für das ursprüngliche Problem dieses Threads darin besteht, das neue Feature namens ... "features" zu verwenden.

...Sie können sich vorstellen, dass es ein Albtraum ist, etwas über diese Funktion zu googeln. In der Hoffnung, dass sie bald eine offizielle Ivy-Dokumentation veröffentlichen! :)

@nayfin baut auch visuelle Formulardesigner/
Und nach ein paar Monaten der Arbeit, um an der Tatsache festzuhalten, dass ich keine Möglichkeit habe, eine Direktive für dynamisch hinzugefügte div bereitzustellen, macht mich verrückt .... Sollte so vergesslich sein, einige MyDirectiveFactory::apply(HTMLElement) aufzurufen.

Diese Funktion würde überwältigend begrüßt, da ich immer ein einziges div erstelle, um Anweisungen auf höchster Ebene anzuhängen. Außerdem muss ich, wenn ich irgendwelche Flex-Layout-Anweisungen haben möchte, auch dieses einmalige div machen und es wäre schön, wenn ich sie direkt an das Host-Element anhängen könnte, anstatt dies tun zu müssen.

Wäre super cool, Direktiven dynamisch hinzufügen zu können, wie zum Beispiel:

const msked = componentFactory.createDirective(MaskedInputDirective);
msked.textMaskConfig = {};
this.elementRef.directives.add(msked);

Außerdem muss ich, wenn ich irgendwelche Flex-Layout-Anweisungen haben möchte, auch dieses einmalige div machen und es wäre schön, wenn ich sie direkt an das Host-Element anhängen könnte, anstatt dies tun zu müssen.

@tsteuwer Sie können immer einfach den :host-Selektor in Ihrer scss verwenden, um Stileigenschaften auf das Host-Element anzuwenden.

Aber ja, ich möchte auch die Möglichkeit haben, Direktiven auf das Host-Element anzuwenden. wäre nützlich, um das Hostelement scrollbar zu machen und CdkScrollable von Angular Material CDK anzuwenden.

Verpacken Sie alles in einer Komponentenvorlage in eine ng-Vorlage der obersten Ebene

Eine etwas schickere Alternative dazu ist die Verwendung von https://github.com/trotyl/angular-contrib und add

host: { ngNoHost: '' }

Dieses Projekt verschiebt den Renderer und rendert untergeordnete Elemente von Elementen mit dem ngNoHost-Attribut, ohne Eltern.

Es hat natürlich viele der gleichen Nachteile.

Schade, dass dies nach 3 Jahren noch geöffnet ist. Direktiven, die an das Host-Element gebunden sind, würden die Wiederverwendbarkeit von Code wirklich verbessern.

Außerdem muss ich, wenn ich irgendwelche Flex-Layout-Anweisungen haben möchte, auch dieses einmalige div machen und es wäre schön, wenn ich sie direkt an das Host-Element anhängen könnte, anstatt dies tun zu müssen.

@tsteuwer Sie können immer einfach den :host-Selektor in Ihrer scss verwenden, um Stileigenschaften auf das Host-Element anzuwenden.

Aber ja, ich möchte auch die Möglichkeit haben, Direktiven auf das Host-Element anzuwenden. wäre nützlich, um das Hostelement scrollbar zu machen und CdkScrollable von Angular Material CDK anzuwenden.

Nicht ideal, aber Sie können das CdkScrollable auf diese Weise programmgesteuert erstellen:
this.scrollable = new CdkScrollable(this.elementRef, this.scrollDispatcher, this.zone);
this.scrollable.ngOnInit();

Sie müssen es auch manuell zerstören:
if (this.scrollable) {
this.scrollable.ngOnDestroy();
}

https://github.com/angular/angular/issues/8785#issuecomment -361004682 IgorMinar the Ivy Arbeit macht dies machbarer. Aber ja nach v6.

@mhevery Nach Ihrem Kommentar :point_up_2: können wir diese Funktion jetzt, da Ivy endlich vollständig gelandet ist, bitte bei (oder vor) der Veröffentlichung von v10 haben? Wenn nicht, informieren Sie uns bitte darüber, welche anderen Überlegungen dies möglicherweise noch weiter aufhalten.

Gibt es Änderungen?

Wenn diese spezielle Funktion in der Angular-Umfrage https://twitter.com/angular/status/1252646001162088448?s=20 enthalten wäre , wäre dies der Beitrag mit der höchsten Bewertung.

Es gibt Unmengen von Funktionen, die am besten bewertet werden würden, diese mit Sicherheit, aber auch die Verwendung von Observables für @output und viele andere. Leider werden sie beim derzeitigen Tempo nie umgesetzt.

Wenn dieses spezielle Feature in der Angular-Umfrage wäre, wäre es der am besten bewertete Eintrag.

Tolle Idee @princemaple!

Dies ist zwar nicht ideal, kann aber im Abschnitt "Zusätzliche Kommentare" der Umfrage (von Frage 2) angesprochen werden.
Wo steht:

"How else should we improve Angular for you?"

Im Grunde also, alle, die an dieser Funktion interessiert sind, beantworten Sie bitte einfach die Umfrage und machen Sie deutlich , dass Ihnen die Implementierung und Lösung von "Issue #8785" sehr am

Hier der direkte Link zur Umfrage:
https://goo.gle/angular-survey-2020

Möge die Macht mit dir sein! 🙂

Auch ich habe mich damit beschäftigt, wie man Komponenten programmatisch mehr Funktionalität hinzufügt, und ehrlich gesagt denke ich, dass einige der Vorschläge hier die BESTEN Wege sind, um diese spezifischen Probleme anzugehen.

Ich habe mit kantigen Teammitgliedern über diesen Artikel gesprochen

Kann mir jemand bestätigen, ob dies jetzt mit Ivy möglich ist? Wenn ja, hat jemand ein Beispiel?

Da ich noch kein Wort habe, dachte ich, ich würde das nächstgelegene liefern, was ich finden konnte, ein Artikel von vor einiger Zeit über die Implementierung von Mixins mit Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -und-mixins-with-angular-ivy-75748fcbc310

Und im Grunde wurde der Eindruck erweckt, dass es sich um ein Hacken mit den Interna von Angular handelt, und es war tatsächlich nicht für den typischen Benutzerverbrauch ausgelegt.

Ich bin mir nicht sicher, was, wenn es einen technischen Grund gibt, der uns daran hindert, dies zu tun, aber ich denke, wenn wir die Fähigkeiten dazu hätten, würde es meinen Alltag mit Angular DRASTISCHER verbessern.

„Wir haben unsere Investitionen in die Zusammenarbeit mit der Community drastisch erhöht. In den letzten drei Wochen hat sich die Zahl der offenen Probleme in Bezug auf Framework, Tools und Komponenten um über 700 Probleme verringert. Wir haben über 2.000 Themen angesprochen und planen, in den nächsten Monaten große Investitionen zu tätigen, um mit der Community zusammenzuarbeiten, um noch mehr zu erreichen.“ — @StephenFluin
von Angular 10 Ankündigung

Ich denke, das bedeutet, dass dieses Problem in v11 beseitigt wird? 🤞😏

Gibt es einen besseren Weg, um "mit der Community zu arbeiten" (und sie zu besänftigen), als daran zu arbeiten, eine ihrer am häufigsten nachgefragten Funktionen hinzuzufügen!? (dieser )

Hört auf sie!

Nur um die Erwartungen zu setzen, was Sie verlangen, ist kein trivialer Arbeitsaufwand und die aktuellen Datenstrukturen sind auch nicht wirklich dafür ausgelegt. Um so etwas zu unterstützen, bedarf es also einiger großer Ingenieursleistungen.

@mhevery, wie unterscheidet es sich davon, sie vom übergeordneten

@k3nsei Es ist notwendig, es aus der Sicht von NgModule zu sehen, die eigentlich das Schlüsselelement ist, das die Infrastruktur für alle ihre Komponenten schafft.

@ MLC-mlapis Wir haben @HostBinding und @HostListener so vielleicht würde @HostDirective für diese Funktionalität gute Wahl sein. Ich habe Gespräche gesehen, dass Ivy apis solche Funktionalitäten ermöglicht.

Für mich ist der Schlüsselpunkt, eine Kompositions-API zu haben, die es uns ermöglicht, mehr entkoppelte Klassen mit der Möglichkeit zu haben, Erweiterungen/Eigenschaften mit wiederverwendbarem Funktionalitätsmüll zu haben. Zum Beispiel wie auswählbar, erweiterbar/zusammenklappbar.

@k3nsei Es könnte sein, aber ich bin mir nicht sicher, ob es nicht zu dynamisch ist, also weniger performant als streng statische Strukturen.

„Nur um die Erwartungen zu formulieren, ist das, was Sie verlangen, kein trivialer Arbeitsaufwand und die aktuellen Datenstrukturen sind nicht wirklich dafür ausgelegt. — https://github.com/angular/angular/issues/8785#issuecomment -654391378

Vielen Dank für Ihre zeitnahe Antwort @mhevery.

Ich denke, ich spreche für die Gemeinschaft, indem ich sage, dass es uns nicht entgangen ist, dass dies eine sehr große Herausforderung sein wird. Wäre dies nicht der Fall, hätten wir inzwischen sicherlich einige Bibliotheken von Drittanbietern erstellt, die dies (irgendwie) richtig erreichen. [gibt es meines Wissens nicht].

Es versteht sich auch von selbst, aber bitte lassen Sie uns wissen, ob es einige niedrig hängende Früchte (oder auf andere Weise) gibt, bei denen wir dazu beitragen können.

Wir danken Ihnen aufrichtig und schätzen Ihre ernsthafte Kommunikation und hoffen, dass wir weiterhin Teil des Dialogs darüber sein werden, was wir brauchen und was realistisch/pragmatisch ist.

Mein Verständnis ist jedoch, dass Ivy dies einfacher macht als zuvor.

@mhevery

@IgorMinar die Ivy-Arbeit macht dies machbarer. Aber ja nach v6.

Obwohl ich verstehe, dass Ivy dies einfacher macht als zuvor

Mein neues Verständnis ist "einfacher" bedeutet immer noch nicht "einfach"

Mein neues Verständnis ist "einfacher" bedeutet immer noch nicht "einfach"

Ivy: Die Sache, an der Sie zwei Jahre gearbeitet haben und die immer noch keines der beliebtesten Angular-Probleme anspricht.

Ivy: Die Sache, an der Sie zwei Jahre gearbeitet haben und die immer noch keines der beliebtesten Angular-Probleme anspricht.

@pauldraper Ich denke, unsere Probleme sind nicht ihre "Probleme", da dieses spezielle nicht einmal auf ihrem Radar ist (siehe Roadmap https://angular.io/guide/roadmap).

Für mich persönlich denke ich, dass es an der Zeit ist, woanders nach einem Projekt zu suchen, das nicht nur Open Source ist, sondern ein Projekt, auf dessen Richtung die Community (und die Benutzer) einen echten Einfluss haben.

@pauldraper Ich denke, unsere Probleme sind nicht ihre "Probleme", da dieses spezielle nicht einmal auf ihrem Radar ist (siehe Roadmap https://angular.io/guide/roadmap).

@somombo Ich bin enttäuscht von der Tatsache, dass dieses Thema nach all den Jahren immer noch offen ist, aber ich kann dir nicht zustimmen Der erste Punkt auf der Roadmap betrifft explizit den Umgang mit offenen Github-Problemen. Sie alle auf der Roadmap aufzulisten, würde nicht viel Sinn machen, oder? Dieses Problem ist eines der am meisten positiv bewerteten (oder am meisten positiv bewerteten) und ich hoffe, dass es endlich gelöst wird.

Der erste Punkt der Roadmap betrifft explizit den Umgang mit offenen Github-Problemen. Sie alle auf der Roadmap aufzulisten, würde nicht viel Sinn machen, oder? Dieses Problem ist eines der am meisten positiv bewerteten (oder am meisten positiv bewerteten) und ich hoffe, dass es endlich gelöst wird.

Nein, das ist nur Wunschdenken, lesen Sie https://github.com/angular/angular/issues/5689 es gibt absolut keinen Hinweis darauf, dass sie eines der am meisten empfohlenen Probleme angehen möchten, abgesehen von "stark typisierten Formen" in der Zukunft

@pauldraper Ich denke, unsere Probleme sind nicht ihre "Probleme", da dieses spezielle nicht einmal auf ihrem Radar ist (siehe Roadmap https://angular.io/guide/roadmap).

@somombo Ich bin enttäuscht von der Tatsache, dass dieses Thema nach all den Jahren immer noch offen ist, aber ich kann dir nicht zustimmen Der erste Punkt auf der Roadmap betrifft explizit den Umgang mit offenen Github-Problemen. Sie alle auf der Roadmap aufzulisten, würde nicht viel Sinn machen, oder? Dieses Problem ist eines der am meisten positiv bewerteten (oder am meisten positiv bewerteten) und ich hoffe, dass es endlich gelöst wird.

Trotzdem .. ich habe es satt zu warten .. dieses Problem war buchstäblich ein großer Blocker für mich. Die Tatsache, dass es noch nicht einmal geplant zu sein scheint, bedeutet, dass es für mich persönlich an der Zeit ist, weiterzumachen. Allen anderen viel Glück.

Ich möchte, dass dies in "Unterstützung für das Hinzufügen von Direktiven zu Direktiven" umbenannt wird. Obwohl dieser Name verwirrend sein mag, denke ich, dass es wichtig ist, dass dieses Feature auf Direktiven funktioniert und nicht auf Komponenten beschränkt ist. Andere Namen für die Funktion können "implizierte Anweisungen" oder "angehängte Anweisungen" sein, d.

Ich habe dies oft gewollt, hauptsächlich weil die Komposition im Vergleich zur Vererbung möglicherweise eine sauberere Form der Wiederverwendung in Angular ist. Die Vererbung kann umständlich sein, da es keine Mehrfachvererbung gibt, Konstruktorparameter weitergegeben werden müssen und einige Angular-Features beim Vererben funktionieren und andere in jeder Blattklasse "neu verbunden" werden müssen.

Ich stelle mir vor, dass "implizierte/angehängte Direktiven" wie eine komponentenlokale oder direktweisungslokale Form der Direktiveninstanzierung funktionieren, was dazu führt, dass die Direktive auf dem Hostelement instanziiert wird, ohne dass der Direktivenselektor im Vorlagen-Markup vorhanden sein muss.

Hier ist ein Beispiel:

@Directive({
  selector: 'app-popup',
  attachDirectives: [
    FocusAreaDirective
  ]
})
export class PopupDirective {

  // Attached directives can be injected, just like template-declared directives today
  constructor(public focusArea: FocusAreaDirective) {
  }

}

Die Eigenschaften @Input() und @Output() der angehängten Direktive können in der Vorlage verwendet werden, und die Lebenszyklusmethoden der angehängten Direktive sollten als Teil des Lebenszyklus der Hostkomponente aufgerufen werden. Die angehängte Direktive kann auch an das Host-Element binden. Im Grunde verhält sie sich heute genau wie eine durch Vorlagen deklarierte Direktive, muss aber nicht in der Vorlage deklariert werden.

Ich denke, diese Funktion würde Angular einen erheblichen Vorteil verschaffen und sauberere/einfachere Komponentenarchitekturen über die Zusammensetzung von Direktiven ermöglichen.

Heute haben Sie zwei Möglichkeiten, wenn Sie eine ähnliche Form der Wiederverwendung von Direktiven wünschen:

• Erfordern, dass ein Satz zusammengehöriger Direktiven immer zusammen im Vorlagen-Markup deklariert werden; und Fehler erkennen und auslösen, wenn die erforderlichen Direktiven nicht im Konstruktor vorhanden sind. Es gibt keine Möglichkeit zu verlangen, dass die erforderlichen Direktiven für dasselbe Element deklariert werden. Dies ist vom Standpunkt der Vorlagenerstellung und -dokumentation aus chaotisch und aufgrund von Redundanz keine starke API oder kein Vertrag, aber ansonsten nicht schrecklich.
• Instanziieren Sie die angehängten Direktiven innerhalb der Host-Direktive manuell und leiten Sie Konstruktorparameter, @Input/@ Output- Eigenschaften,

Anders ausgedrückt führt das Fehlen der Funktion manchmal zu einem unnötigen Kompromiss zwischen sauberer und einfacher Komponentenverwendung und sauberer und einfacher Komponentenerstellung.

@johncrim
Beachten Sie, dass Ihre benutzerdefinierte Direktive in einem realen Fall Eingaben enthält, die Sie transformieren und als Eingaben an die angehängte Direktive übergeben möchten. Vielleicht könnte dies mit einer Syntax erfolgen, die den host Attributen in den Direktiven-Dekorator-Optionen ähnelt.

@amakhrov : Guter Punkt - ich habe die Eingaben aus meinem Beispiel aus Gründen der Klarheit ausgeschlossen. In den meisten Fällen, in denen ich dies benötige, muss ich die Eingaben (oder Ausgaben) für die angehängten Direktiven nicht transformieren - sie fungieren (idealerweise) als zusammensetzbare Einheiten und ihre Eingabe- (oder Ausgabe-) Werte könnten aus der Vorlage gebunden werden unter Verwendung der übergeordneten Direktive (oder Komponente).

In Fällen, in denen es entweder Namenskonflikte oder Probleme mit der Namensklarheit gibt (die ich beim Entwerfen von Direktiven für die Komposition vermeiden würde) oder wenn Eingaben oder Ausgaben transformiert werden müssen, könnte dies ziemlich einfach durch Einfügen der angehängten Direktive in das übergeordnete Element gehandhabt werden -Direktive und erstellen Sie neue Eingabe- oder Ausgabeeigenschaften auf dem übergeordneten Element, die an die angehängten Direktiven delegieren.

Ich stehe korrigiert.
Dieses Problem ist jetzt im Abschnitt "Zukunft" der offiziellen Roadmap aufgeführt. Siehe https://angular.io/guide/roadmap#support -adding-directives-to-host-elements

Unterstützt das Hinzufügen von Direktiven zu Hostelementen

Eine seit langem bestehende Feature-Anfrage besteht darin, die Möglichkeit zum Hinzufügen von Direktiven zu Host-Elementen hinzuzufügen. Die Funktion ermöglicht es Entwicklern, ihre eigenen Komponenten mit zusätzlichen Verhaltensweisen zu erweitern, ohne Vererbung zu verwenden. Das Projekt wird erhebliche Anstrengungen in Bezug auf die Definition von APIs, Semantik und Implementierung erfordern.

Da ich es gerade erst bemerkt habe, bin ich mir nicht sicher, wann es hinzugefügt wurde, aber ich gebe zu, dass dies eine großartige Nachricht und eine bedeutungsvolle und beruhigende Geste ist. Ich werde weiter die Daumen drücken.

Vielen Dank an das Team für die Bereitstellung! 🙏🏾