Angular: Proposal: Perlu kemampuan untuk menambahkan arahan ke elemen host dalam deklarasi komponen.

Saat ini saya sedang mengembangkan klien besar dan karena itu saya mencoba memecah semua masalah terkait GUI menjadi arahan Angular2 yang dapat digunakan kembali. Ini selalu membawa saya ke masalah yang sama, seperti yang ditunjukkan oleh james dengan sempurna.
Ini benar-benar harus bekerja entah bagaimana demi arsitektur modular dan dinamis yang baik. Contoh sentuhan hanyalah salah satu dari banyak skenario di mana ini diperlukan. misalnya Drag&Drop, Resize mengamati, dll dll dll.
Buat contoh lain sebagai plunker:
https://plnkr.co/edit/J65THEMic0yhObt1LkCu?p=info

Apakah ada kemungkinan fungsi ini akan ditambahkan dalam waktu dekat?

Berikut adalah pertanyaan StackOverflow yang terkait dengan ini: http://stackoverflow.com/questions/37148080/use-angular2-directive-in-Host-of-another-directive

@ Andy1605 apakah Anda pernah menemukan cara untuk mengatasi ini? Saya agak bekerja dengan NG2 karena ini selama RC. Ingin mengambilnya kembali, tetapi masalah khusus ini mencegah saya membangun pola UI yang dapat diperluas.

Saya juga merasa bahwa Angular kehilangan fitur penting di sini. Seharusnya komponen dapat mendeklarasikan (beberapa) arahan atribut untuk hostnya. Tidak dapat melakukan itu juga merupakan penghalang besar bagi proyek saya.
Adakah yang tahu apakah ini akan diterapkan di masa depan atau jika ada alasan mengapa hal itu tidak dapat dilakukan?

Saya telah mengusulkan solusi untuk masalah ini (meskipun untuk versi sudut 1) di sini: https://github.com/angular/angular.js/issues/15270 .

Ide saya adalah, alih-alih hanya memiliki kemampuan untuk menambahkan arahan, kerangka kompilasi akan memiliki titik ekstensibilitas baru yang disebut "hostTransforms" (dalam kasus sudut 1, "nodeTransforms") yang akan memiliki akses ke deklarasi komponen yang tidak dimodifikasi dan tidak difilter dan node host komponen asli yang tidak dikompilasi setiap kali komponen pertama kali ditemukan oleh kompiler dan sedang dipersiapkan untuk dimasukkan ke dalam DOM. Dengan cara ini pengembang dapat memperluas dekorator komponen dengan properti khusus, dan kemudian menggunakan nodeTransforms untuk mengonversi properti khusus tersebut menjadi sesuatu yang familiar dengan kerangka kerja sudut, tepat sebelum kompilasi. Periksa utas permintaan fitur untuk contoh.

Saya lebih akrab dengan kode sumber sudut daripada kode sumber sudut 2, jadi saya tidak yakin apakah proses implementasinya akan sama di sini. Tetapi karena ini tampaknya merupakan permintaan yang cukup populer, saya ingin melihatnya diimplementasikan dalam angular 2 dan di-backport, atau diimplementasikan dalam angularjs dan diteruskan (apakah itu?).

+1

Saya harus setuju, fitur yang memungkinkan kita menambahkan arahan atribut kontribusi ke host akan sangat bagus. Saya tahu saya bisa menggunakan fitur seperti itu sekarang dengan menerapkan cara yang lebih "sudut" seperti menambahkan fungsionalitas seret/lepas ke komponen UI saya.

Bagaimana dengan membuat tag baru yang mirip dengan <ng-container> yang memungkinkan Anda menerapkannya di template komponen alih-alih properti metadata host ? Sesuatu seperti <ng-host [attributeDirective]> untuk menunjukkan arahan ditambahkan ke komponen host.

@jjstreet proposal Anda terdengar mirip dengan replace: true (jelas tidak identik, tetapi serupa), yang sudah usang beberapa waktu lalu. Tapi mungkin replace: true tidak digunakan lagi karena alasan yang tidak berlaku di sini.

@pkozlowski-opensource Bisakah kami mendapat tanggapan apa pun dari tim ng2 tentang ini?

Saya permainan untuk cara apa pun untuk mencapai ini. Saya menyarankan properti Host karena memiliki akses ke lingkup lokal komponen, dan sudah menambahkan atribut ke komponen itu sendiri. Arahan tampak seperti perpanjangan alami dari perilaku ini.

+1 fitur ini diperlukan untuk memiliki kode yang bersih dan dapat digunakan kembali di komponen UI

+1

Bisakah kami mendapatkan semacam tanggapan dari tim ng2 tentang ini? Bahkan jika itu hanya untuk mengatakan Anda tidak akan melakukannya, atau untuk mengatakan itu ide yang bagus tetapi bukan prioritas saat ini, saya hanya ingin mendengar semacam masukan.

Saya ingin menambahkan kasus penggunaan lain untuk ini. Itu akan memungkinkan ng2-mobx (https://github.com/500tech/ng2-mobx) untuk menyingkirkan komponen pembungkus dan terlihat jauh lebih bersih.

Saya juga ingin memiliki ini. Saat ini saya membutuhkannya untuk membuat direktif routerLink kustom. Saya ingin menggunakan kembali yang bersudut dan hanya menyediakannya dengan parameter yang disiapkan oleh arahan mi.

Jadi alih-alih <a [routerLink]="repeatedCodeToGetLink()"> saya akan memiliki <a [myRouterLink]> dan itu akan secara dinamis menerapkan [routerLink] dengan parameter yang diselesaikan.

Benar-benar bersemangat tentang prospek ini!

Kami membutuhkan ini untuk sementara waktu. Sebenarnya, beberapa waktu lalu sebelum saya tahu ada masalah terbuka untuk itu, saya bertanya di stack overflow tentang fitur ini pada dasarnya.

Saya telah memberikan contoh yang rumit tentang bagaimana kami dapat menggunakan fitur ini untuk menyelesaikan https://github.com/angular/flex-layout/issues/162 yang telah kami buka untuk sementara waktu. ( Lihat contoh dan penjelasannya di sini )

Kami sangat menantikan umpan balik apa pun, saya melihat bahwa masalah ini adalah yang paling banyak diacungi jempol ketiga dari semua masalah terbuka di repo ini. Semoga kita bisa melihat ini di rilis berikutnya atau lebih cepat (semoga saja)!

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

@jjstreet Saya pikir saran Anda

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

... akan cocok dengan proposal terpisah lain yang dibuat beberapa waktu lalu untuk alasan terpisah daripada yang kita diskusikan di sini.

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

Saat ini saya mengatasi ini dengan menambahkan arahan di komponen induk dan kemudian menambahkan pendengar di Host dengan @HostListener.

Induk.html
<my-component myDirective>

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

Tapi akan lebih bersih jika kita bisa menambahkan atribut langsung di host...

Inilah cara saya menangani ini, tetapi saya benar-benar berpikir menerapkan fitur ini dari dasar akan menjadi solusi terbaik.

• Penjelasan Lengkap di Jawaban Stack Overflow saya: http://stackoverflow.com/a/41650302/2959469
• TL;DR Lihat Plunker: https://plnkr.co/edit/TCagW8vOPrqSiOT9Oztf

Hanya pengingat bulanan bahwa kami sedang menunggu komentar positif atau negatif tentang ini dari tim Angular.

@tbosch - Setiap pemikiran publik tentang prioritas masalah ini. Ini juga berdampak pada @angular/flex-layout .

@fadzic bisakah Anda tidak hanya menambahkan arahan ke elemen Host dengan melakukan ini ...

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

atau seperti ini jika Anda memerlukan parameter seperti ElementRef atau Renderer2
@HostBinding('attr.myHilite') myHilite = new myHiliteDirective(this.elementRef, this.renderer)

Saya juga perlu menambahkan arahan ke elemen Host dan saya dialihkan ke masalah ini. Saya dapat melakukan apa yang saya butuhkan menggunakan kode di atas. Saya sama sekali bukan ahli menggunakan sudut tetapi solusi ini tampaknya berhasil sejauh ini, jika seseorang memiliki masalah dengan pendekatan ini, beri tahu saya. Terima kasih.

@btinoco itu tidak berfungsi karena tidak ada metode siklus hidup yang dipanggil. Anda harus menghubungkan semuanya secara manual di setiap komponen yang menggunakan arahan daripada hanya memasang Angular untuk Anda.

@hccampos terima kasih atas perhatiannya. Saya baru saja mencobanya dan ngOnInit dari arahan saya tidak dijalankan (kecuali saya menggunakan arahan di komponen saya secara manual) atau saya memanggil ngOnInit() arahan di komponen saya ngOnInit() . Sekali lagi terima kasih telah memberi tahu saya tentang hal itu.

@btinoco - ya. itu adalah masalah yang halus tapi jahat. Yang diharapkan @angular/flex-layout akan segera diperbaiki. ;-)

Adakah berita dari tim Angular tentang ini? Sudah 1 tahun sejak edisi ini dibuka...

Menemukan deskripsi terperinci tentang masalah ini sangat keren,
kemudian tidak menemukan umpan balik dari tim Angular sangat tidak keren :(

Mengenai solusi yang sudah berfungsi:

Permintaan fitur ini terdengar sangat mirip dengan mixin. Sebenarnya, peluru no 2 dalam deskripsi
fitur ini benar-benar cocok dengan yang resmi
dokumentasi TypeScript, lihat di sini .
Dalam sudut, ini menjadi sedikit lebih buruk, untuk mencampur kelas dengan @Input() s, Anda
harus mendeklarasikan ulang mereka di kelas dasar.

Solusi lain yang sudah berfungsi hari ini adalah membuat komponen berisi elemen pembungkus dan menerapkan arahan di sana.
Misalnya jika komponen berisi template seperti <wrapper g-touch>...

Mengenai "Buat fungsi pembantu yang melakukannya melalui layanan langsung di elementRef.nativeElement":
Ya, sepertinya itu ide yang bagus juga. Saya tidak akan peduli dengan WebWorkers untuk saat ini,
karena masih eksperimental dan kehilangan beberapa fitur yang lebih besar untuk produksi,
dan hampir tidak ada perpustakaan di luar sana yang berfungsi di WebWorkers.
Lihat misalnya juga pustaka materi kami yang mengakses DOM secara langsung.

Mengenai Opsi 1) dari proposal:

Semantik saat ini untuk binding properti host adalah,
bahwa mereka menetapkan properti myDir pada elemen HTML yang mendasarinya,
tapi tidak ada arahan. Namun, jika host juga dapat memperkenalkan arahan, pengguna dapat menulis yang berikut:
dan akan bingung mengapa ini tidak memperbarui properti di direktif myDir :

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

Mengenai Opsi 1) dan Opsi 3):
Memperkenalkan semacam host binding antara direktif pada elemen yang sama dapat:

• mengarah ke siklus dalam grafik pengikatan data, yang tidak didukung oleh Angular, dan karenanya
  menyebabkan kesalahan yang sulit untuk di-debug karena nilai basi / kesalahan "Ekspresi telah berubah setelah diperiksa".
• menyebabkan overhead kinerja tambahan, dibandingkan dengan arahan yang saling menyuntikkan
  dan berkomunikasi secara langsung.

Mengenai Opsi 2) dari proposal:

• ya, harus merujuk ke kelas gTouch tampaknya aneh, seperti semua arahan lainnya
  dipicu melalui NgModule s.

@ThomasBurleson mari kita bicara offline tentang kasus penggunaan Anda lebih detail...

@tbosch Saya ingin mengusulkan opsi lain: Perkenalkan tag sudut asli, sebut saja <ng-host> .

Catatan: @mhevery mengusulkan pengenalan tag <ng-host> di https://github.com/angular/angular/issues/7546 , namun, meskipun saya menggunakan nama tag yang sama di sini, siapa saya mengusulkan terpisah dan dimaksudkan khusus untuk mengatasi masalah yang diangkat di sini.

Tag ng-host tidak akan diimplementasikan sebagai direktif/kelas komponen biasa tetapi akan menjadi kode kerangka kerja "ajaib"... mirip dengan ng-content , ng-container , dll. .,
Tag hanya akan berfungsi sebagai "penunjuk" ke host komponen dengan cara yang analog dengan css :host selector .

Ini menghindari skenario ambigu, setiap komponen hanya akan diizinkan untuk memiliki, paling banyak, satu blok <ng-host> dan itu harus menjadi tag/simpul root dari templat komponen itu.

Berikut adalah bagaimana seseorang akan menggunakannya:

// 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>
  `
})

By the way @tbosch , Terima kasih telah menanggapi sama sekali. Kami sangat menghargai keterlibatan dan umpan balik Anda tentang masalah ini.

Apakah pemikiran orang lain tentang fungsi ini khusus untuk Komponen, atau apakah masuk akal juga jika Arahan dapat menerapkan arahan yang berbeda ke hostnya? Kasus penggunaan saya mulai berlangganan masalah ini karena melibatkan beberapa arahan pihak ketiga yang A) kami ingin mengisolasi dari kode kami jika kami ingin mengubah nanti dan B) ingin menerapkan beberapa fungsi default untuk setiap instance tanpa harus menduplikasi setup setiap kali kita menggunakannya.

Misalnya, direktif tooltip, yang akan diterapkan pada sejumlah besar elemen di seluruh aplikasi kita, dan kita ingin default delay dan appendToBody (tidak mendukung objek konfigurasi terpusat). Karena tidak mendukung objek konfigurasi pusat, kami harus meletakkan tiga atau empat atribut di mana pun kami ingin menggunakannya. Dan kemudian, kami akhirnya pindah dari perpustakaan itu (mulai menggunakan tooltips Material) dan kami harus mengganti setiap tooltip secara manual. Seandainya kami dapat membuat direktif kami sendiri yang "membungkusnya", itu akan menjadi sesederhana mengubah direktif itu untuk menerapkan [mdTooltip] ke host-nya alih-alih perpustakaan lain.

@MikeMatusz Sepertinya saya juga memikirkannya, ini cuplikan saya dari 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 {}

Apakah mungkin untuk membuat dekorator properti yang memberikan arahan?
Sebagai contoh:
@HostDirective(LayoutDirective) myLayoutDirective: LayoutDirective;

Ini akan berfungsi untuk Komponen serta Arahan, memberikan referensi instans untuk interaksi dan tidak akan hilang saat mewarisi dari Komponen/Petunjuk.
Saya kira itu menjadi lebih rumit jika Anda juga ingin memberikan input dan pengikatan acara.

Di mana ini berdiri? Saya cukup baru di Angular2/4, dan yang ingin saya lakukan adalah membuat arahan yang hanya menerapkan beberapa arahan lain sekaligus. Sehingga alih-alih:

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

Saya hanya bisa menulis:

<button customDirectiveABC>BUTTON TEXT</button>

Terasa seperti ini seharusnya mudah--komposisi dasar/DRYness. Tapi sejauh yang saya tahu itu tidak mungkin?

Lihat juga https://github.com/angular/flex-layout/issues/76#issuecomment -310509013

@soynog , saya merasakan hal yang sama. Saya juga ingin tahu di mana ini berdiri.

Saya berharap dapat membuat dialog yang dapat diseret menggunakan Angular Material dan angular2-draggable (karena angular/material#1206 belum didukung) di mana saya ingin menambahkan arahan secara dinamis ke md-dialog-container yang MdDialog membuat layanan, tetapi tampaknya jauh lebih sulit untuk mendapatkan perilaku kompiler Angular 1.x di sini untuk arahan dinamis.

@tbosch , @ThomasBurleson , apakah kasus penggunaan offline yang Anda diskusikan terkait dengan masalah atau tujuan yang diangkat Thomas dalam angular/material#1206 secara kebetulan? Saya hanya mencoba untuk memahami perubahan perilaku antara kerangka kerja 1.6.x dan 2+.

Apakah ada pembaruan tentang masalah ini? Itu mendapat daya tarik pada awalnya tapi saya pikir itu tidak mendapat perhatian lagi.

Yup ada update tentang itu?

Ini adalah sesuatu yang sangat saya butuhkan, semoga proposal ini sampai ke hulu.

Ini akan menyenangkan, menyadari hari ini bahwa saya tidak dapat menerapkan arahan secara terprogram/dinamis, menjadi sedih.

+1
Sama untuk ku :)
Saya mencari cara untuk membungkus beberapa arahan yang mengikat menjadi arahan khusus yang melakukan semua yang saya butuhkan. Sebagai contoh :

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

Akan lebih baik jika saya bisa membuat arahan yang membungkus semua hal itu sehingga saya dapat menggunakannya kembali tanpa menyalin/menempel semua baris.

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

Dan ke dalam arahan khusus saya

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

datang pada ulang tahun kedua dari masalah ini! sejujurnya fitur ini akan sangat, sangat berguna, memungkinkan kita membuat komponen dan arahan yang sangat mudah dikomposisi tanpa harus membuat sejuta pembungkus. buat saja komponen yang Anda butuhkan dari arahan yang Anda miliki. sederhana, bersih, efektif.

@IgorMinar - Pokoknya kita bisa mendapatkan fitur ini di radar untuk peningkatan yang akan datang?

Saya ingin tahu apakah fitur seperti itu akan dianggap sebagai pola yang buruk atau tidak. Siapa pun?

@darkbasic - AFAIU, tanpa fitur ini, pengembang perlu memperkenalkan elemen pembungkus (pada ng-container ) hanya untuk menambahkan arahan induk ke tampilan templat dan konten.

Tidak, saya tidak berpikir bisa memiliki kontrol penuh atas komponen Anda sendiri tanpa harus menggunakan pembungkus adalah pola yang buruk. Ini adalah kebutuhan.

@bradlygreen ada komentar?

Fitur ini adalah permintaan paling populer (jika bukan teratas 5) di antara semua masalah terbuka repo ini... Di internet kami melihat laporan (didukung oleh data empiris) penurunan Angular sebagai kerangka kerja de facto ... Saya pikir salah satu hal yang mendorong yaitu sentimen bahwa masyarakat tidak didengar. Sebuah kompetisi; vue.js dan reaksi, semakin kuat dan telah melampaui sudut karena meskipun mereka mungkin tidak selalu mengimplementasikan setiap hal kecil yang diinginkan setiap orang, mereka setidaknya memberikan umpan balik berkelanjutan tentang item yang paling populer diminta. Sangat frustasi menunggu begitu lama dan tidak mendengar apa-apa .. bahkan tidak sederhana "tidak, kami tidak akan melakukannya".

(Lihat bagian kerangka kerja Js "Slip sudut" )

... meskipun menurut saya beberapa pendapat tentang Angular / Vue / React / ... dipengaruhi oleh faktor yang berbeda ... fitur konkret ini benar-benar layak untuk beberapa bentuk implementasi (bahkan keadaan sedikit lebih rumit daripada hanya solusi dengan daftar sederhana arahan yang diterapkan) ... sehingga posisi konkret tim inti Angular akan sangat disambut ...

Tidak ada ETA khusus, tetapi kami berupaya membuat kategori ini lebih mudah di perender pada tahun 2018.

Semoga segalanya menjadi lebih baik secara drastis di tahun 2018. Kami kalah

Lihat:

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

@somombo artikel ini sudah lama dikonfirmasi omong kosong

Orang-orang yang benar-benar tahu barang-barang mereka mengolok-olok penulis dan tidak ada yang menganggapnya serius, suka dari reaksi, vue fanboys, tentu saja.

Jadi faktanya adalah bahwa masalah ini di sini adalah prioritas yang sangat rendah untuk tim sudut, sebenarnya ini adalah prioritas yang paling rendah.

Lihat Daftar prioritas yang diterbitkan di AngularHQ (cari nomor Masalah 8785)

Hal ini terjadi meskipun isu ini telah menimbulkan banyak diskusi dan minat dari masyarakat seperti yang ditunjukkan oleh jumlah komentar.

Jika Anda adalah seseorang yang peduli dengan masalah ini dan benar-benar ingin melihatnya diimplementasikan, maka alih-alih menunggu.. jujur ​​saja _mungkin tidak pernah_, mungkin Anda dapat mengisi Survei Sudut Tahunan Resmi , dan menyatakan bahwa Anda menyukai masalah ini harus menjadi prioritas yang lebih tinggi dan akan menghargai melihatnya terpenuhi lebih cepat daripada nanti.

Jangan lupa untuk berterima kasih kepada Tim Sudut kami untuk semua pekerjaan hebat yang telah mereka lakukan!

Saya juga ingin memberikan suara saya untuk fitur ini. Ini telah menjadi penyebab terlalu banyak kesedihan mencoba untuk mengatasi masalah ini.

@somombo tolong jangan terlalu banyak membaca prioritas di AngularHQ. formula prioritas tidak sepenuhnya disempurnakan. karena itu, saya pikir kita harus meninjau kembali permintaan fitur ini setelah v6 dikirimkan. Saya khawatir kami tidak memiliki bandwidth untuk itu lebih cepat dan mengerjakan ini akan bertentangan dengan pekerjaan yang sudah berlangsung di area kompiler/inti.

Ini bukan permintaan perbaikan cepat. Saya menduga itu akan membutuhkan banyak upaya untuk menyelesaikannya dengan benar, tetapi hal-hal yang sedang kami kerjakan untuk v6 seharusnya membuat yang ini lebih mudah untuk diterapkan.

@IgorMinar pekerjaan Ivy membuat ini lebih layak. Tapi ya melewati v6.

@IgorMinar dan @mhevery Saya tidak bisa cukup menekankan betapa bersyukurnya saya (dan kita semua juga, saya yakin) bahwa Anda telah memberi kami umpan balik konkret tentang apa yang Anda pikirkan dan apa yang perlu terjadi terlebih dahulu sebelum masalah ini bisa terjadi. ditangani dengan benar.

Tidak selalu jelas bagi kita orang awam apa itu "perbaikan cepat" dan apa yang tidak. Namun, kecuali fakta bahwa ini bukan jenis perbaikan cepat dan harus dilakukan dengan benar, saya sangat menghargai bahwa tampaknya Anda juga merasa bahwa ini akan menjadi fitur yang berguna untuk dimiliki oleh angular.

Kami tahu Anda berdua sangat sibuk dan tidak mungkin menanggapi seperti ini untuk setiap masalah.
Jadi, Anda memiliki rasa terima kasih yang tulus setiap kali Anda melakukannya. Kami senang dan menantikan angular v6 dan seterusnya!

Terima kasih untuk semua pekerjaan hebat!

Anda dapat meminta kelas komponen Anda memperluas atau mengimplementasikan kelas direktif. Jika Anda mencoba menerapkan arahan di bawah tenda, maka itu mungkin hanya logika dalam komponen.

export class gBtn extends gTouch

@NateMay , itu hanya memungkinkan Anda untuk memperluas satu kelas. Masalah ini lebih lanjut tentang komposisi beberapa bagian fungsionalitas menggunakan arahan.

@NateMay dua masalah dengan itu - pertama, Anda hanya dapat memperluas satu kelas, dan kedua, Anda baru saja memutus injeksi ketergantungan.

Hanya menambahkan dua sen saya. Saya sedang membangun SPA multi-layer dengan sudut, material, dan tata letak fleksibel, menggunakan status bersarang @uirouter/angular. Kemudian ketidakmampuan untuk dengan mudah menerapkan arahan fleksibel ke elemen komponen sangat terbatas.

Jadi silakan pilih fitur ini.

+1 untuk fitur tambahan ini

Dimungkinkan untuk menambahkan arahan ke ng-container , yang tidak akan muncul di DOM.

Saya membutuhkan ini untuk API pengamat persimpangan (yang memunculkan peristiwa ketika elemen masuk/keluar dari viewport). Saya memiliki direktif intersector , yang memiliki peristiwa enter() dan leave() ketika elemen menjadi terlihat/tersembunyi. Saya memiliki komponen tertentu yang perlu menggunakan API ini secara internal, tetapi saya tidak ingin menambahkan DIV tambahan di template.

Jadi yang saya lakukan adalah yang berikut di component.html :

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

Kemudian konstruktor direktif intersector.directive.ts menyuntikkan ElementRef .

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

Untuk elemen DOM normal Anda hanya akan beroperasi pada intersectorElementRef.nativeElement , tetapi untuk ng-container node sebenarnya adalah node komentar. Jadi saya hanya memeriksa untuk melihat apakah itu komentar, dan jika ya, maka saya naik satu level.

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 ...);

Ini tidak akan berhasil untuk semua situasi, tetapi saya baik-baik saja dengan ini untuk saat ini. Saya percaya bahwa dalam kompiler IVY mereka mungkin tidak menggunakan komentar lagi - jadi ini mungkin rusak. Yang penting adalah saya memiliki satu arahan yang dapat saya gunakan pada node DOM atau dalam apa yang efektif sebagai ' @HostBinding ' palsu untuk arahan.

Saya sangat berharap mungkin untuk menambahkan arahan secara dinamis. Saya ingin dapat merangkum arahan tingkat yang lebih rendah dalam arahan "urutan lebih tinggi", lebih abstrak. Saya mengajukan pertanyaan berikut tentang stack overflow, dan saya bertanya-tanya apakah akan ada solusi untuk ini di masa mendatang: https://stackoverflow.com/questions/51608645/abstract-away-leaflet-directive-in-custom-directive

seperti yang dikatakan @mhevery .. kita harus bersabar dan menunggu versi lengkap ivy (ng v7.0.0?) mendarat. Sepertinya akan lebih mudah bagi mereka untuk mengimplementasikannya dengan ivy... Setelah ivy, kami harus mengingatkan tim betapa pentingnya fitur ini bagi kami, agar mereka tidak melupakannya

Berlangganan ini. Saya juga harus dapat secara dinamis melampirkan arahan ke komponen yang saya buat dengan resolveComponentFactory/createComponent.

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)

Perubahan apapun???
Saya mengalami kasus penggunaan lain di mana saya menggunakan arahan pihak ketiga.
Dalam beberapa skenario, saya perlu menghapus/menambahkan arahan pada elemen HTML secara dinamis.
apakah ini mungkin dengan cara apa pun atau masih menunggu solusinya?

@micronyks ... sebenarnya tidak mungkin menambahkan arahan secara dinamis. Kami harus menunggu Ivy yang akan menambahkan kemungkinan untuk membuat fitur seperti itu.

@mlc-mlapis tapi ada rencana kapan IVY datang ? di versi mana?

@micronyks ... Angular 7 menurut jadwal.

Guys mari kita masuk akal di sini, Tim Angular berusaha keras untuk mengerjakan beberapa fitur besar yang sangat dituntut, (PWA, SSR, Ivy, dan terutama Elemen Kustom) yang terakhir menjadi fitur prioritas sangat tinggi seperti yang saya mengerti, karena banyak perusahaan besar (seperti Microsoft) telah memintanya selamanya, dan ada alasan untuk itu. Untuk mencapai Elemen Kustom yang efisien, mereka membutuhkan Ivy, segera setelah mereka selesai dengan Ivy, seperti yang dikatakan @mhevery , mesin akan memungkinkan arahan dinamis dengan lebih mudah.

Sementara itu, alih-alih terus menuntut fitur ini (yang saya juga sangat membutuhkan btw), kami dapat membantu tim Angular untuk mempercepat proses, dengan menguji beta, melaporkan bug, membantu dengan dokumen, dll.

Mari kita ingat bahwa Tim Angular bahkan tidak sebesar itu, hanya selusin orang yang mencoba membuat kerangka kerja yang luar biasa untuk semua orang, tetapi itu membutuhkan waktu.

... ya, sekarang perlu sedikit bersabar dan menunggu sampai kami dapat membantu lebih banyak dengan Ivy ... ketika kompiler akan selesai dan beberapa dokumen desain detail tersedia.

@avatsaev Saya setuju dengan semua yang Anda katakan. Anda tidak harus menuntut hal-hal di sini. Tetapi Anda dapat menjelaskan masalah yang Anda hadapi saat bekerja dengan Angular.

Saya sama sekali bukan pengembang Angular yang sangat berpengalaman, tetapi beberapa hal terasa salah atau tidak dijelaskan dengan cukup jelas.

Saya menemukan masalah ini karena saya ingin merangkum komponen/arahan pihak ketiga, tanpa abstraksi yang bocor. Bagian dari ini adalah memungkinkan untuk memiliki arahan dinamis. Yang mengejutkan saya adalah cukup rumit untuk mencapai hal seperti itu.

Saya sedang membangun generator formulir, menggunakan Bahan Sudut dan Tata Letak Flex, yang mengambil konfigurasi JSON dan menghasilkan formulir. Fitur ini akan membantu saya menerapkan arahan flex-layout ke komponen Host saat runtime. Saya merasa salah satu aset terbesar Angular adalah kemampuan untuk menghasilkan kode saat runtime dari konfigurasi, ini akan sangat membantu untuk membuat kode itu lebih fleksibel. Hanya ingin memasukkan kasus penggunaan yang baik. Tidak sabar ;)

Itu kasus penggunaan saya yang tepat

@NateMay inilah implementasi saya jika Anda ingin memeriksanya.

@NateMay inilah implementasi saya jika Anda ingin memeriksanya.

bisa tolong jelaskan? Saya kira maksud Anda dynamic-field.directive

dynamic-field.directive melakukan hal-hal mewah tetapi ada banyak hal lain yang terjadi juga. Saya baru saja menambahkan CONTRIBUTING.md di folder root, yang memiliki instruksi untuk mengatur secara lokal. Berhati-hatilah menggunakan apa pun yang sedang diproduksi selama beberapa bulan. Saya membuat perubahan besar saat saya bekerja menuju implementasi yang stabil.

+1

Sejauh ini, solusi saya adalah, mereka semua memiliki kelemahan.

1. has-it , tentukan properti anggota baru sebagai arahan di dalam kelas komponen saya, berikan semua argumen konstruktor yang diperlukan ke arahan itu saat memanggil fungsi konstruktornya (mis. ElementRef, ViewContainerRef, TemplateRef... , dan secara manual memanggil panggilan balik siklus hidupnya jika ada, seperti ngInit() ngAfterViewInit() pada fungsi panggilan balik siklus hidup yang sesuai dengan komponen saat ini.

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

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

1. Bungkus semua yang ada di templat komponen dalam templat ng tingkat atas,
   <ng-template><div targetDirective>....</div></ng-template> membuat mereka di ngAfterViewInit() seperti:

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

Dengan cara ini, Angular membuat element dengan arahan itu dan konten aktual komponen saya di dalamnya tepat setelah elemen komponen asli di pohon DOM.

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

Cara ini seperti yang dilakukan <route-outlet> .

Ada efek samping yang jelas

Dapatkah seseorang mengonfirmasi apakah ini sekarang memungkinkan dengan Ivy? Jika demikian, apakah ada yang punya contoh?

Mari kita ingat bahwa Tim Angular bahkan tidak sebesar itu, hanya selusin orang yang mencoba membuat kerangka kerja yang luar biasa untuk semua orang, tetapi itu membutuhkan waktu.

Itu bisa lebih besar dengan memiliki komunitas kontributor.

Namun, kemungkinan perbaikan kontribusi untuk ini diterima sangat rendah.

Jadi alih-alih kami kembali ke selusin orang.

Dapatkah seseorang mengonfirmasi apakah ini sekarang memungkinkan dengan Ivy? Jika demikian, apakah ada yang punya contoh?

Karena belum ada kabar, saya pikir saya akan memberikan hal terdekat yang dapat saya temukan, yang merupakan artikel dari beberapa waktu lalu tentang menerapkan mixin dengan Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -dan-campuran-dengan-angular-ivy-75748fcbc310

Menurut artikel tersebut, saya pikir solusi yang mungkin untuk masalah asli utas ini adalah dengan menggunakan fitur baru yang disebut ... "fitur".

...Anda dapat membayangkan sedikit mimpi buruk untuk mencoba Google apa pun tentang fitur ini. Berharap mereka segera merilis beberapa dokumentasi Ivy resmi! :)

@nayfin juga membangun desainer/pembangun bentuk visual
Dan setelah beberapa bulan bekerja untuk terjebak pada kenyataan saya tidak punya cara untuk menyebarkan arahan ke div yang ditambahkan secara dinamis membuat saya gila .... Harus begitu tidak menyadari untuk memanggil beberapa MyDirectiveFactory::apply(HTMLElement)

Fitur ini akan sangat disambut karena saya selalu membuat satu div untuk melampirkan arahan tingkat atas. Selain itu, Jika saya menginginkan arahan flex-layout, saya harus membuat div satu kali itu juga dan alangkah baiknya jika saya dapat melampirkannya langsung ke elemen Host daripada harus melakukan ini.

Akan sangat keren untuk dapat menambahkan arahan secara dinamis seperti:

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

Selain itu, Jika saya menginginkan arahan flex-layout, saya harus membuat div satu kali itu juga dan alangkah baiknya jika saya dapat melampirkannya langsung ke elemen Host daripada harus melakukan ini.

@tsteuwer Anda selalu bisa menggunakan pemilih :host di scss Anda untuk menerapkan properti gaya ke elemen host.

Tapi ya, saya juga ingin kemampuan untuk menerapkan arahan ke elemen host. akan berguna untuk membuat elemen host dapat digulir dan menerapkan CdkScrollable dari Angular Material CDK.

Bungkus semua yang ada di template komponen dalam template ng tingkat atas

Alternatif yang sedikit lebih licin untuk ini adalah dengan menggunakan https://github.com/trotyl/angular-contrib dan tambahkan

host: { ngNoHost: '' }

Proyek ini menggeser perender dan merender turunan elemen dengan atribut ngNoHost, tanpa induk.

Ini memiliki banyak kelemahan yang sama tentu saja.

Sayang sekali ini masih buka setelah 3 tahun. Arahan yang terikat ke elemen Host akan benar-benar meningkatkan kemampuan penggunaan kembali kode.

Selain itu, Jika saya menginginkan arahan flex-layout, saya harus membuat div satu kali itu juga dan alangkah baiknya jika saya dapat melampirkannya langsung ke elemen Host daripada harus melakukan ini.

@tsteuwer Anda selalu bisa menggunakan pemilih :host di scss Anda untuk menerapkan properti gaya ke elemen host.

Tapi ya, saya juga ingin kemampuan untuk menerapkan arahan ke elemen host. akan berguna untuk membuat elemen host dapat digulir dan menerapkan CdkScrollable dari Angular Material CDK.

Tidak ideal tetapi Anda dapat membuat CdkScrollable secara terprogram dengan cara ini:
this.scrollable = new CdkScrollable(this.elementRef, this.scrollDispatcher, this.zone);
this.scrollable.ngOnInit();

Anda juga harus menghancurkannya secara manual:
if (this.scrollable) {
this.scrollable.ngOnDestroy();
}

https://github.com/angular/angular/issues/8785#issuecomment -361004682 IgorMinar pekerjaan Ivy membuat ini lebih layak. Tapi ya melewati v6.

@mhevery Menindaklanjuti komentar Anda :point_up_2:, sekarang Ivy akhirnya sepenuhnya mendarat, bisakah kita memiliki fitur ini pada (atau sebelum) rilis v10? Jika tidak, mohon perbarui kami tentang pertimbangan lain apa yang dapat menahan ini lebih jauh.

Apakah ada perubahan?

Jika fitur khusus ini ada di survei Angular https://twitter.com/angular/status/1252646001162088448?s=20 , saya yakin itu akan menjadi entri dengan suara terbanyak.

Ada banyak fitur yang akan menjadi yang teratas, yang ini pasti tetapi juga menggunakan Observables untuk @output dan banyak lainnya. Sayangnya pada kecepatan saat ini mereka tidak akan pernah diimplementasikan.

Jika fitur khusus ini ada di survei Angular, saya yakin itu akan menjadi entri dengan suara terbanyak.

Ide bagus @princemaple!

Meskipun tidak ideal, ini sebenarnya dapat diatasi di bagian "komentar tambahan" survei (dari pertanyaan 2)
Dimana dikatakan:

"How else should we improve Angular for you?"

Jadi pada dasarnya, semua orang tertarik dalam melihat fitur ini, silahkan saja menjawab survei dan membuatnya eksplisit diketahui, bahwa Anda peduli banyak tentang melihat "Edisi # 8785" dilaksanakan dan diselesaikan.

Berikut adalah tautan langsung ke survei:
https://goo.gle/angular-survey-2020

Semoga kekuatan menyertai Anda! 🙂

Saya juga telah berjuang dengan cara menambahkan lebih banyak fungsionalitas secara terprogram ke komponen, dan sejujurnya saya pikir beberapa proposal di sini tampak seperti cara TERBAIK untuk mendekati masalah khusus tersebut.

Saya telah berbicara dengan anggota tim sudut mengenai artikel itu

Dapatkah seseorang mengonfirmasi apakah ini sekarang memungkinkan dengan Ivy? Jika demikian, apakah ada yang punya contoh?

Karena belum ada kabar, saya pikir saya akan memberikan hal terdekat yang dapat saya temukan, yang merupakan artikel dari beberapa waktu lalu tentang menerapkan mixin dengan Ivy: https://blog.nrwl.io/metaprogramming-higher-order-components -dan-campuran-dengan-angular-ivy-75748fcbc310

Dan pada dasarnya mengarah pada kesan bahwa ini adalah peretasan dengan internal sudut, dan itu sebenarnya tidak dirancang untuk konsumsi pengguna biasa.

Saya tidak yakin bagaimana jika ada alasan teknis yang mencegah kami untuk dapat melakukan ini, tetapi saya pikir jika kami memiliki kemampuan untuk melakukan ini, itu akan secara DRASTIS meningkatkan hari ke hari saya dengan sudut.

“Kami telah secara dramatis meningkatkan investasi kami dalam bekerja dengan masyarakat. Dalam tiga minggu terakhir, jumlah masalah terbuka kami telah berkurang lebih dari 700 masalah di seluruh kerangka kerja, alat, dan komponen. Kami telah menyentuh lebih dari 2.000 masalah, dan kami berencana untuk melakukan investasi besar selama beberapa bulan ke depan, bekerja dengan komunitas untuk melakukan lebih banyak lagi.” — @StephenFluin
dari Angular 10 Pengumuman

Jadi saya kira ini berarti kita akan melihat masalah ini dibatalkan di v11? 🤞😏

Apa cara yang lebih baik untuk "bekerja dengan komunitas" (dan menenangkan mereka) selain bekerja untuk menambahkan salah satu fitur yang paling banyak diminta!? (yang ini )

Dengarkan mereka!

Hanya untuk menetapkan harapan, apa yang Anda minta bukanlah jumlah pekerjaan yang sepele dan struktur data saat ini tidak benar-benar dirancang untuk ini. Jadi untuk mendukung hal seperti ini akan membutuhkan beberapa rekayasa besar.

@mhevery apa bedanya dengan menerapkannya dari induk di templat?

@k3nsei Ini perlu dilihat dari sudut pandang NgModule , yang sebenarnya merupakan elemen kunci yang menciptakan infrastruktur untuk semua komponennya.

@mlc-mlapis Kami memiliki @HostBinding dan @HostListener jadi mungkin @HostDirective akan menjadi pilihan yang baik untuk fungsi itu. Saya telah melihat pembicaraan bahwa Ivy apis memungkinkan fungsi seperti itu.

Bagi saya, poin kuncinya adalah memiliki beberapa API komposisi yang memungkinkan kita memiliki lebih banyak kelas yang dipisahkan dengan kemampuan untuk memiliki ekstensi/sifat dengan jung fungsionalitas yang dapat digunakan kembali. Misalnya seperti yang dapat dipilih, dapat diperluas/diciutkan.

@ k3nsei Bisa jadi, tapi saya tidak yakin apakah itu tidak terlalu dinamis, jadi kurang berkinerja daripada struktur yang benar-benar statis.

"Hanya untuk menetapkan harapan, apa yang Anda minta bukanlah jumlah pekerjaan yang sepele dan struktur data saat ini tidak benar-benar dirancang untuk ini. Jadi untuk mendukung sesuatu seperti ini akan memerlukan beberapa rekayasa besar." — https://github.com/angular/angular/issues/8785#issuecomment -654391378

Terima kasih atas tanggapan Anda yang tepat waktu @mhevery.

Saya pikir saya akan berbicara untuk komunitas dengan mengatakan bahwa sama sekali tidak hilang dari kita bahwa ini akan menjadi tantangan yang sangat besar. Jika tidak, saya yakin sekarang kami akan membuat beberapa perpustakaan pihak ketiga yang mencapai ini dengan benar (entah bagaimana). [setahu saya tidak ada].

Juga, tidak perlu dikatakan lagi, harap beri tahu kami jika ada beberapa buah yang menggantung rendah (atau lainnya) yang dapat kami bantu untuk berkontribusi dalam hal ini.

Kami dengan tulus berterima kasih dan menghargai komunikasi tulus Anda dan berharap kami akan terus menjadi bagian dari dialog tentang apa yang kami butuhkan vs. apa yang realistis/pragmatis untuk ditambahkan.

Meskipun pemahaman saya adalah bahwa Ivy membuat ini lebih mudah dari sebelumnya.

@mhevery

@IgorMinar pekerjaan Ivy membuat ini lebih layak. Tapi ya melewati v6.

Meskipun pemahaman saya adalah bahwa Ivy membuat ini lebih mudah dari sebelumnya

Pemahaman baru saya adalah "lebih mudah" tetap tidak berarti "mudah"

Pemahaman baru saya adalah "lebih mudah" tetap tidak berarti "mudah"

Ivy: Hal yang Anda habiskan selama dua tahun dan masih belum mengatasi masalah Angular yang paling populer.

Ivy: Hal yang Anda habiskan selama dua tahun dan masih belum mengatasi masalah Angular yang paling populer.

@pauldraper Saya kira masalah kami bukan "masalah" mereka mengingat yang satu ini bahkan tidak ada di radar mereka (Lihat Peta Jalan https://angular.io/guide/roadmap ).

Bagi saya pribadi, saya pikir waktunya bagi saya untuk mencari tempat lain untuk sebuah proyek yang tidak hanya open source tetapi proyek yang arah masyarakat (dan pengguna) memiliki pengaruh nyata pada.

@pauldraper Saya kira masalah kami bukan "masalah" mereka mengingat yang satu ini bahkan tidak ada di radar mereka (Lihat Peta Jalan https://angular.io/guide/roadmap ).

@somombo Saya kecewa dengan kenyataan bahwa masalah ini masih terbuka setelah bertahun-tahun, tetapi saya tidak setuju dengan Anda Poin pertama di peta jalan secara eksplisit tentang menangani masalah github terbuka. Mencantumkan semuanya di peta jalan tidak masuk akal, bukan? Masalah ini adalah salah satu yang paling upvoted (atau paling upvoted) dan saya berharap itu akan akhirnya diambil diselesaikan.

Poin pertama pada peta jalan secara eksplisit tentang menangani masalah github terbuka. Mencantumkan semuanya di peta jalan tidak masuk akal, bukan? Masalah ini adalah salah satu yang paling banyak dipilih (atau paling banyak dipilih) dan saya berharap akhirnya akan diselesaikan.

tidak, ini hanya angan-angan, baca melalui https://github.com/angular/angular/issues/5689 sama sekali tidak ada indikasi mereka ingin menangani salah satu masalah yang paling banyak dipilih, selain dari "formulir yang diketik dengan kuat" di masa depan

@pauldraper Saya kira masalah kami bukan "masalah" mereka mengingat yang satu ini bahkan tidak ada di radar mereka (Lihat Peta Jalan https://angular.io/guide/roadmap ).

@somombo Saya kecewa dengan kenyataan bahwa masalah ini masih terbuka setelah bertahun-tahun, tetapi saya tidak setuju dengan Anda Poin pertama di peta jalan secara eksplisit tentang menangani masalah github terbuka. Mencantumkan semuanya di peta jalan tidak masuk akal, bukan? Masalah ini adalah salah satu yang paling upvoted (atau paling upvoted) dan saya berharap itu akan akhirnya diambil diselesaikan.

Semua sama .. Saya sudah selesai menunggu .. masalah ini telah menjadi penghalang besar bagi saya. Jadi fakta bahwa sepertinya itu tidak direncanakan untuk waktu dekat berarti sudah waktunya bagi saya secara pribadi untuk melanjutkan. Semoga sukses untuk semua orang.

Saya ingin melihat ini diganti namanya menjadi "Dukungan untuk menambahkan arahan ke arahan". Meskipun nama itu mungkin membingungkan, saya pikir penting bahwa fitur ini berfungsi pada arahan, dan tidak terbatas pada komponen. Nama lain untuk fitur tersebut mungkin adalah "petunjuk tersirat" atau "arahan terlampir", yang berarti ketika Anda menggunakan komponen atau arahan tertentu dalam template, itu menarik arahan tersirat/terlampir pada elemen host.

Saya sudah menginginkan ini berkali-kali, terutama karena komposisi berpotensi menjadi bentuk penggunaan kembali yang lebih bersih di Angular, dibandingkan dengan pewarisan. Pewarisan dapat menjadi kikuk karena tidak ada pewarisan berganda, parameter konstruktor harus diturunkan, dan beberapa fitur Angular berfungsi saat diwarisi, dan yang lainnya harus "terhubung kembali" di setiap kelas daun.

Saya membayangkan "petunjuk tersirat/terlampir" bekerja seperti bentuk instantiasi direktif komponen-lokal atau lokal-lokal, yang menghasilkan arahan yang dipakai pada elemen Host tanpa memerlukan pemilih direktif ada di markup templat.

Berikut ini contohnya:

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

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

}

Properti @Input() dan @Output() pada direktif terlampir dapat digunakan dalam template, dan metode siklus hidup pada direktif terlampir harus dipanggil sebagai bagian dari siklus hidup komponen host. Arahan terlampir juga dapat mengikat ke elemen host. Pada dasarnya, ia bertindak persis seperti direktif yang dideklarasikan oleh template hari ini, tetapi tidak perlu dideklarasikan dalam template.

Saya pikir fitur ini akan memberikan manfaat yang signifikan bagi Angular, memungkinkan arsitektur komponen yang lebih bersih/sederhana melalui komposisi direktif.

Hari ini, Anda memiliki 2 pilihan jika Anda menginginkan bentuk penggunaan kembali arahan yang serupa:

• Mengharuskan satu set arahan terkait selalu dideklarasikan bersama dalam markup template; dan mendeteksi dan membuang kesalahan jika arahan yang diperlukan tidak ada di konstruktor. Tidak ada cara untuk mengharuskan arahan yang diperlukan dideklarasikan pada elemen yang sama. Ini berantakan dari sudut pandang pembuatan dan dokumentasi template, dan bukan API atau kontrak yang kuat karena redundansi, tetapi sebaliknya tidak mengerikan.
• Buat instance directive terlampir secara manual di dalam host directive, dan forward parameter constructor, properti @Input/ @Output , binding host, dan metode siklus hidup ke directive internal. Ini adalah kekacauan yang rapuh bagi pembuat komponen, tetapi dapat dilakukan dengan serangkaian komponen terkait yang sederhana. Ini jauh lebih baik untuk pembuatan template.

Dengan kata lain, tidak adanya fitur terkadang menciptakan tradeoff yang tidak perlu antara penggunaan komponen bersih+sederhana, dan pembuatan komponen bersih+sederhana.

@johncrim
Perhatikan bahwa dalam kasus dunia nyata, arahan khusus Anda akan memiliki input, dan Anda ingin mengubahnya dan meneruskannya sebagai input ke arahan terlampir. Mungkin ini bisa dilakukan dengan sintaks yang mirip dengan atribut host dalam opsi dekorator Directive.

@amakhrov : Poin bagus - saya mengecualikan input dari contoh saya untuk kejelasan. Dalam sebagian besar kasus di mana saya membutuhkan ini, saya tidak perlu mengubah input (atau output) untuk arahan terlampir - mereka (idealnya) bertindak sebagai unit yang dapat dikomposisi dan nilai input (atau output) mereka dapat diikat dari template menggunakan direktif induk (atau komponen).

Dalam kasus di mana ada konflik penamaan atau masalah kejelasan penamaan (yang akan saya coba hindari ketika merancang arahan untuk komposisi), atau ketika input atau output perlu diubah, itu dapat ditangani dengan cukup mudah dengan menyuntikkan arahan terlampir di induk direktif, dan buat properti input atau output baru pada induk yang mendelegasikan ke arahan terlampir.

Saya berdiri dikoreksi.
Masalah ini sekarang terdaftar di bawah bagian "Masa Depan" dari peta jalan resmi. Lihat https://angular.io/guide/roadmap#support -adding-directives-to-host-elements

Dukungan menambahkan arahan ke elemen host

Permintaan fitur lama adalah untuk menambahkan kemampuan untuk menambahkan arahan ke elemen host. Fitur ini akan memungkinkan pengembang untuk menambah komponen mereka sendiri dengan perilaku tambahan tanpa menggunakan pewarisan. Proyek ini akan membutuhkan upaya substansial dalam hal definisi API, semantik, dan implementasi.

Karena saya baru menyadarinya, saya tidak yakin kapan itu ditambahkan, tetapi saya akui bahwa ini adalah berita bagus, dan isyarat yang bermakna dan meyakinkan. Aku akan terus menyilangkan jariku.

Terima kasih kepada tim untuk meletakkannya di sana! 🙏🏾