Dalam pengembangan proyek Angular, kami biasanya menggunakan pengikatan properti Input dan pengikatan peristiwa Output untuk komunikasi komponen komponen. mengirimkan informasi. Komponen membentuk pohon komponen berdasarkan hubungan pemanggilan. Jika hanya ada pengikatan properti dan pengikatan peristiwa, maka dua komponen hubungan tidak langsung perlu berkomunikasi melalui setiap titik koneksi itu sendiri tidak perlu tahu informasinya (Gambar 1 kiri). Layanan Injectable yang disediakan di Angular dapat disediakan dalam modul, komponen atau instruksi, dan dikombinasikan dengan injeksi di konstruktor, dapat mengatasi masalah ini (tepat di Gambar 1). [Tutorial terkait yang direkomendasikan: "tutorial sudut"]
Gambar 1 Model komunikasi komponen
Gambar kiri hanya mengirimkan informasi melalui komponen induk-anak. Node a dan node b perlu melewati banyak node untuk berkomunikasi; jika node c ingin mengontrol node b melalui beberapa konfigurasi, node di antara keduanya juga harus diatur atribut atau peristiwa tambahan untuk mengirimkan informasi terkait secara transparan. Mode injeksi ketergantungan node c pada gambar di sebelah kanan dapat menyediakan layanan bagi node a dan b untuk berkomunikasi. Node a berkomunikasi langsung dengan layanan yang disediakan oleh node c, dan node b juga berkomunikasi langsung dengan layanan yang disediakan oleh node c. Akhirnya, komunikasi disederhanakan, dan bagian tengah Node tidak digabungkan dengan bagian konten ini, dan tidak memiliki kesadaran yang jelas tentang komunikasi yang terjadi antara komponen atas dan bawah.
Injeksi Ketergantungan (DI) tidak hanya terjadi pada Angular. Ini adalah cara untuk mengimplementasikan pola desain kontrol inversi (IOC). Munculnya injeksi ketergantungan memecahkan masalah kopling berlebih pada manual instantiasi, dan semua sumber daya tidak dapat digunakan. Pengelolaan sumber daya oleh kedua belah pihak, dibandingkan disediakan oleh pusat sumber daya atau pihak ketiga yang tidak menggunakan sumber daya, dapat membawa banyak manfaat. Pertama, pengelolaan sumber daya terpusat membuat sumber daya dapat dikonfigurasi dan mudah dikelola. Kedua, mengurangi tingkat ketergantungan antara kedua pihak dalam menggunakan sumber daya, yang disebut dengan kopling.
Analoginya dengan dunia nyata, ketika kita membeli suatu produk seperti pensil, kita hanya perlu mencari toko untuk membeli produk sejenis pensil tersebut. Kita tidak peduli di mana pensil itu diproduksi atau bagaimana kayu dan pensil itu dibuat terikat. Kami hanya membutuhkannya untuk melengkapi fungsi menulis pensil. Kami tidak akan memiliki kontak apa pun dengan produsen atau pabrik pensil tertentu. Sedangkan untuk toko, dapat membeli pensil dari saluran yang sesuai dan mewujudkan konfigurasi sumber daya.
Dikombinasikan dengan skenario pengkodean, lebih khusus lagi, pengguna tidak perlu secara eksplisit membuat instance (operasi baru) untuk memasukkan dan menggunakan instance. Pembuatan instance ditentukan oleh penyedia. Manajemen sumber daya dilakukan melalui token. Karena tidak peduli dengan penyedia atau pembuatan instance, pengguna dapat menggunakan beberapa metode injeksi lokal (konfigurasi token sekunder) untuk akhirnya mencapai mode penggantian instance dan injeksi ketergantungan (AOP ) saling melengkapi.
Injeksi ketergantungan Angular adalah salah satu modul inti terpenting dari kerangka kerja Angular. Angular tidak hanya menyediakan injeksi jenis Layanan, tetapi pohon komponen itu sendiri adalah pohon ketergantungan injeksi, dan fungsi serta nilai juga dapat disuntikkan. Artinya, dalam kerangka Angular, komponen anak dapat memasukkan instance komponen induk melalui token komponen induk (biasanya nama kelas). Dalam pengembangan pustaka komponen, ada banyak kasus di mana interaksi dan komunikasi dicapai dengan memasukkan komponen induk, termasuk pemasangan parameter, berbagi status, dan bahkan memperoleh DOM dari node tempat komponen induk berada, dll.
Untuk menggunakan injeksi Angular, Anda harus terlebih dahulu memahami proses resolusi injeksinya. Mirip dengan proses penguraian node_modules, ketika tidak ada dependensi yang ditemukan, dependensi akan selalu muncul ke lapisan induk untuk menemukan dependensi. Angular versi lama (sebelum v6) membagi proses parsing injeksi menjadi injektor modul multi-level, injektor komponen multi-level, dan injektor elemen. Versi baru (setelah v9) disederhanakan menjadi model dua tingkat. Rantai kueri pertama adalah injektor elemen tingkat DOM statis, injektor komponen, dll., yang secara kolektif disebut injektor elemen, dan rantai kueri lainnya adalah injektor modul. Urutan penguraian dan nilai default setelah kegagalan penguraian dijelaskan lebih jelas dalam dokumen komentar kode resmi (provider_flag).
Gambar 2 Proses pencarian dependensi pada injektor dua tingkat (sumber gambar)
artinya komponen/instruksi dan penyediaan konten yang disuntikkan pada level komponen/instruksi akan terlebih dahulu mencari dependensi pada elemen di tampilan komponen hingga ke elemen root Jika tidak ditemukan, maka pada elemen Modul saat ini, referensi (termasuk referensi modul dan referensi perutean pemuatan lambat) dari modul induk modul dicari hingga modul root dan modul platform.
Perhatikan bahwa injektor di sini memiliki warisan. Injektor elemen dapat membuat dan mewarisi fungsi pencarian injektor elemen induk, dan injektor modul serupa. Setelah pewarisan berkelanjutan, ini menjadi seperti rantai prototipe objek js.
memahami urutan prioritas resolusi ketergantungan, dan kami dapat menyediakan konten pada tingkat yang sesuai. Kita sudah tahu bahwa ini hadir dalam dua jenis: injeksi modul dan injeksi elemen.
Injektor modul: Penyedia dapat dikonfigurasi dalam atribut metadata @NgModule, dan Anda juga dapat menggunakan pernyataan @Injectable yang disediakan setelah v6. provideIn dideklarasikan sebagai nama modul, 'root', dll. (Sebenarnya, ada dua injektor di atas modul root, Platform dan Null. Keduanya tidak akan dibahas di sini.)
Injektor elemen: Penyedia, viewProviders dapat dikonfigurasi dalam atribut metadata komponen @Component, atau di @ direktif penyedia dalam metadata Directive.
Selain menggunakan injektor modul yang dideklarasikan, dekorator @Injectable juga dapat dideklarasikan sebagai injektor elemen. Lebih sering hal ini akan dideklarasikan sebagai disediakan di root untuk mengimplementasikan singleton. Ini mengintegrasikan metadata melalui kelas itu sendiri untuk menghindari modul atau komponen yang secara langsung mendeklarasikan penyedianya. Dengan cara ini, jika kelas tidak memiliki layanan arahan komponen dan kelas lain untuk menyuntikkannya, tidak akan ada kode yang ditautkan ke deklarasi tipe dan. itu dapat diabaikan oleh kompiler, sehingga mencapai Shake the tree.
Cara lain untuk menyediakannya adalah dengan memberikan nilai secara langsung saat mendeklarasikan InjectionToken.
Berikut adalah templat singkat untuk metode ini:
@NgModule({ penyedia: [
//Injektor modul]
})
ekspor kelas MyModule {} @Component({ penyedia: [
// injektor elemen - komponen],
penyedia tampilan: [
//Injektor Elemen - Tampilan Komponen]
})
ekspor kelas MyComponent {} @Directive({ penyedia: [
// injektor elemen - arahan]
})
kelas ekspor MyDirective {} @Injectable({
disediakan di: 'root'
})
kelas ekspor MyService {} ekspor const MY_INJECT_TOKEN = New InjectionToken<MyClass>('my-inject-token', {
disediakanDalam: 'root',
pabrik: () => {
kembalikan MyClass baru();
}
}); Pilihan yang berbeda untuk menyediakan lokasi ketergantungan akan membawa beberapa perbedaan, yang pada akhirnya mempengaruhi ukuran paket, cakupan di mana dependensi dapat disuntikkan, dan siklus hidup dependensi. Ada beberapa solusi berbeda yang dapat diterapkan untuk skenario berbeda, seperti singleton (root), isolasi layanan (modul), beberapa jendela pengeditan (komponen), dll. Anda harus memilih lokasi yang masuk akal untuk menghindari informasi bersama yang tidak pantas atau pengemasan kode yang berlebihan.
hanya menyediakan injeksi instans, hal tersebut tidak akan menunjukkan fleksibilitas injeksi ketergantungan kerangka kerja Angular. Angular menyediakan banyak alat injeksi yang fleksibel. useClass secara otomatis membuat instance baru, useValue menggunakan nilai statis, useExisting dapat menggunakan kembali instance yang ada, dan useFactory dibangun melalui fungsi, dengan deps tertentu dan parameter konstruktor tertentu. Anda dapat memotong token token suatu kelas dan menggantinya dengan instance lain yang telah Anda siapkan. Anda dapat membuat token untuk menyimpan nilai atau instance terlebih dahulu, lalu menggantinya lagi saat Anda perlu menggunakannya nanti fungsi pabrik untuk mengembalikannya. Informasi lokal dari instance dipetakan ke objek atau nilai atribut lain. Gameplay di sini akan dijelaskan melalui kasus-kasus berikut, jadi saya tidak akan membahasnya di sini. Situs resminya juga memiliki banyak contoh untuk referensi.
Injeksi di Angular dapat disuntikkan ke dalam konstruktor, atau Anda bisa mendapatkan injektor untuk mendapatkan elemen yang disuntikkan melalui metode get.
Angular mendukung penambahan dekorator untuk ditandai saat menyuntikkan,
, ada artikel "@Self atau @Optional @Host? Panduan visual untuk dekorator Angular DI." yang dengan jelas menunjukkan bahwa jika dekorator berbeda digunakan antara komponen induk dan anak, contoh yang pada akhirnya akan terkena adalah: Sungguh aduh. perbedaan.
Gambar 3 Hasil pemfilteran dari berbagai dekorator yang disuntikkan
Di antara tampilan host dan dekorator @Host, @Host mungkin yang paling sulit dipahami. Berikut adalah beberapa instruksi khusus untuk @Host. Penjelasan resmi dari dekorator @Host adalah
...mengambil ketergantungan dari injektor mana pun hingga mencapai elemen host.
Host di sini berarti host. Dekorator @Host akan membatasi cakupan kueri ke dalam elemen host. Apa itu elemen host? Jika komponen B adalah komponen yang digunakan oleh template komponen A, maka instance komponen A adalah elemen host dari instance komponen B. Konten yang dihasilkan oleh templat komponen disebut Tampilan. Tampilan yang sama mungkin merupakan tampilan berbeda untuk komponen berbeda. Jika komponen A menggunakan komponen B dalam lingkup templatnya sendiri (lihat Gambar 4), tampilan (bagian kotak merah) yang dibentuk oleh konten templat A adalah tampilan tersemat dari komponen A, dan komponen B berada dalam tampilan ini, jadi Untuk B , tampilan ini adalah tampilan host B. Dekorator @Host membatasi cakupan pencarian pada tampilan host. Jika tidak ditemukan, maka tidak akan muncul.
Gambar 4 Tampilan tertanam dan tampilan host
Mari kita gunakan kasus nyata untuk melihat cara kerja injeksi ketergantungan, cara memecahkan masalah kesalahan, dan cara bermain.
Komponen jendela modal dari pustaka komponen DevUI menyediakan layanan ModalService, yang dapat memunculkan kotak modal dan dapat dikonfigurasi sebagai komponen khusus. Pelajar bisnis sering melaporkan kesalahan saat menggunakan komponen ini, mengatakan bahwa paket tidak dapat menemukan komponen khusus.
Misalnya, kesalahan berikut dilaporkan:
Gambar 5 Saat menggunakan ModalService, terjadi kesalahan saat membuat komponen yang mereferensikan EditorX. Penyedia layanan terkait tidak dapat ditemukan
Analisis bagaimana ModalService membuat komponen khusus. Seperti yang Anda lihat, jika componentFactoryResolver tidak diteruskan, componentFactoryResolver yang dimasukkan oleh ModalService akan digunakan. Dalam kebanyakan kasus, bisnis akan memperkenalkan DevUIModule satu kali di modul root, namun tidak akan memperkenalkan ModalModule di modul saat ini. Artinya, situasi saat ini pada Gambar 6 adalah seperti ini. Menurut Gambar 6, tidak ada EditorXModuleService di injektor ModalService.
Gambar 6 Diagram hubungan penyediaan layanan modul
Menurut warisan injektor, ada empat solusi:
letakkan EditorXModule di mana ModalModule dideklarasikan, sehingga injektor dapat menemukan EditorModuleService yang disediakan oleh EditorXModule - ini adalah solusi terburuk, pemuatan lambat diimplementasikan oleh loadChildren adalah untuk mengurangi pemuatan modul halaman beranda. Hasilnya adalah konten yang perlu digunakan di sub-halaman ditempatkan di AppModule. Modul teks kaya berukuran besar dimuat pada pemuatan pertama, yang memperburuk FMP (Cat Bermakna Pertama).
Perkenalkan ModalService dalam modul yang memperkenalkan EditorXModule dan menggunakan ModalService - disarankan. Hanya ada satu situasi yang tidak disarankan, yaitu memanggil ModalService sebagai layanan publik tingkat atas lainnya, yang masih menempatkan modul yang tidak diperlukan di lapisan atas untuk dimuat.
Saat memicu komponen menggunakan ModalService, masukkan componentFactoryResolver dari modul saat ini dan teruskan ke parameter fungsi terbuka ModalService - disarankan untuk memperkenalkan EditorXModule di tempat ia sebenarnya digunakan.
Dalam modul yang digunakan, disarankan untuk menyediakan ModalService secara manual, yang memecahkan masalah injeksi pencarian.
Keempat metode tersebut sebenarnya memecahkan masalah EditorXModuleService di rantai internal injektor componentFactoryResolver yang digunakan oleh ModalService. Dengan memastikan bahwa rantai pencarian berada pada dua tingkat, masalah ini dapat diatasi.
Ringkasan poin pengetahuan : pewarisan modul injektor dan cakupan pencarian.
Biasanya ketika kita menggunakan template yang sama di beberapa tempat, kita akan mengekstrak bagian yang umum melalui template. Ketika komponen DevUI Select dikembangkan sebelumnya, pengembang ingin mengekstrak bagian yang umum dan melaporkan kesalahan.
Gambar 7 Pergerakan kode dan kesalahan injeksi tidak ditemukan.
Hal ini karena instruksi CdkVirtualScrollFor perlu menyuntikkan CdkVirtualScrollViewport. Namun, sistem pewarisan injektor injeksi elemen mewarisi DOM dari hubungan AST statis, dan yang dinamis tidak dimungkinkan perilaku kueri berikut terjadi, dan pencarian gagal.
Gambar 8 Rentang Pencarian Rantai Kueri Injektor Elemen
Solusi Akhir: 1) Pertahankan posisi kode asli tidak berubah, atau 2) Anda perlu menyematkan seluruh templat untuk menemukannya.
Gambar 9 Menyematkan seluruh modul memungkinkan CdkVitualScrollFo menemukan CdkVirtualScrollViewport (Solusi 2)
Ringkasan poin pengetahuan : Rantai kueri injektor elemen adalah nenek moyang elemen DOM dari templat statis.
Kasus ini berasal dari blog ini "Angular: Formulir berbasis template bersarang".
Kami juga mengalami masalah yang sama saat menggunakan validasi formulir. Seperti yang ditunjukkan pada Gambar 10, karena beberapa alasan kami merangkum alamat ketiga bidang tersebut ke dalam komponen untuk digunakan kembali.
Gambar 10: Enkapsulasi tiga bidang alamat formulir menjadi subkomponen.
Saat ini, kita akan menemukan bahwa kesalahan dilaporkan. ngModelGroup memerlukan ControlContainer di dalam host, yang merupakan konten yang disediakan oleh direktif ngForm.
Gambar 11 ngModelGroup tidak dapat menemukan ControlContainer.
Melihat kode ngModelGroup, Anda dapat melihat bahwa itu hanya menambahkan batasan dekorator host.
Gambar 12 ng_model_group.ts membatasi cakupan injeksi ControlContainer.
Di sini Anda dapat menggunakan viewProvider dengan menggunakan Existing untuk menambahkan Penyedia ControlContainer ke tampilan host AddressComponent.
Gambar 13 Menggunakan viewProviders untuk menyediakan
poin pengetahuan Penyedia eksternal untuk komponen bersarang Ringkasan poin pengetahuan: Penggunaan viewProvider dan usingExisting yang luar biasa.
pemuatan yang lambat, mengakibatkan ketidakmampuan untuk melakukan drag dan drop satu sama lain. Platform bisnis internal melibatkan drag dan drop di beberapa modul memuat loadChildren, setiap modul akan DragDropModule dari pustaka komponen DevUI dikemas secara terpisah, dan Modul ini menyediakan DragDropService. Instruksi drag-and-drop dibagi menjadi instruksi Draggable dan instruksi Droppable. Kedua instruksi tersebut berkomunikasi melalui DragDropService. Awalnya, komunikasi dapat dilakukan dengan memperkenalkan modul yang sama dan menggunakan Layanan yang disediakan oleh modul. Namun, setelah pemuatan lambat, modul DragDropModule dipaketkan dua kali, yang juga menghasilkan dua instance terisolasi. Saat ini, instruksi Draggable dalam modul yang dimuat dengan lambat tidak dapat berkomunikasi dengan instruksi Droppable di modul yang dimuat dengan lambat lainnya, karena DragDropService bukan instance yang sama saat ini.
Gambar 14 Pemuatan modul yang lambat menyebabkan layanan tidak menjadi instance/kasus tunggal yang sama.
Jelas bahwa persyaratan kita di sini adalah kita memerlukan singleton, dan metode singleton biasanya providerIn: 'root' DragDropService dari pustaka komponen? Sebaiknya sediakan domain root langsung di tingkat modul. Namun jika dipikir-pikir baik-baik, ada masalah lain di sini. Pustaka komponen itu sendiri disediakan untuk digunakan oleh berbagai bisnis. Jika beberapa bisnis memiliki dua grup seret dan lepas yang sesuai di dua tempat pada laman, bisnis tersebut tidak ingin ditautkan. Pada saat ini, singleton menghancurkan isolasi alami berdasarkan modul.
Maka akan lebih masuk akal untuk menerapkan penggantian tunggal di sisi bisnis. Ingat rantai permintaan ketergantungan yang kami sebutkan sebelumnya. Injektor elemen dicari terlebih dahulu. Jika tidak ditemukan, injektor modul dimulai. Jadi ide penggantinya adalah kami dapat menyediakan penyedia tingkat elemen.
Gambar 15 Gunakan metode ekstensi untuk mendapatkan DragDropService baru dan tandai sebagai disediakan di tingkat root
Gambar 16 Anda dapat menggunakan pemilih yang sama untuk menumpangkan instruksi berulang, menumpangkan instruksi tambahan pada instruksi Draggable dan instruksi Droppable dari pustaka komponen, dan mengganti token DragDropService dengan DragDropGlobalService yang telah menyediakan singleton di
root Gambar 15 dan 16, kita menyuntikkan melalui elemen. Handler menempatkan instruksi dan mengganti token DragDropService dengan instance singleton global kita sendiri. Saat ini, ketika kita perlu menggunakan DragDropService singleton global, kita hanya perlu memperkenalkan modul yang mendeklarasikan dan mengekspor dua instruksi tambahan ini untuk mengaktifkan instruksi Draggable instruksi Droppable dari pustaka komponen untuk berkomunikasi di seluruh modul yang dimuat dengan lambat.
Ringkasan poin pengetahuan : Injektor elemen memiliki prioritas lebih tinggi daripada injektor modul.
Tema pustaka komponen DevUI menggunakan atribut khusus CSS (variabel css) untuk mendeklarasikan nilai variabel css dari root untuk mencapai peralihan tema. . Jika kita ingin menampilkan pratinjau tema yang berbeda secara bersamaan dalam satu antarmuka, kita dapat mendeklarasikan ulang variabel css secara lokal di elemen DOM untuk mencapai fungsi tema lokal. Ketika saya membuat generator tema gentar sebelumnya, saya menggunakan metode ini untuk menerapkan tema secara lokal.
Gambar 17 Fungsi tema lokal
, tetapi tidak cukup untuk menerapkan nilai variabel CSS secara lokal. Ada beberapa lapisan pop-up drop-down yang terpasang di bagian belakang badan secara default, yang berarti lapisan lampirannya berada di luar. variabel lokal, yang akan menyebabkan situasi yang sangat memalukan. Kotak drop-down komponen tema lokal menampilkan gaya tema eksternal.
Gambar 18 Komponen dalam tema lokal terlampir pada kotak drop-down overlay eksternal.
Apa yang harus saya lakukan jika tema salah? Kita harus memindahkan titik lampiran kembali ke dalam dom tema lokal.
Diketahui bahwa Overlay komponen DatePickerPro pada pustaka komponen DevUI menggunakan Overlay Angular CDK. Setelah serangkaian analisis, kami menggantinya dengan injeksi sebagai berikut:
1) Pertama, kami mewarisi OverlayContainer dan mengimplementasikan ElementOverlayContainer kami sendiri seperti yang ditunjukkan pada gambar. di bawah.
Gambar 19 Kustomisasi ElementOverlayContainer dan ganti logika _createContainer
2) Kemudian langsung sediakan ElementOverlayContainer baru kita di sisi komponen preview, dan berikan Overlay baru agar Overlay baru tersebut dapat menggunakan OverlayContainer kita. Awalnya Overlay dan OverlayContainer disediakan di root, di sini kita perlu membahas keduanya.
Gambar 20 Ganti OverlayContainer dengan ElementOverlayContainer kustom dan berikan Overlay baru.
Sekarang pergi ke pratinjau situs web, dan DOM lapisan pop-up akan berhasil dilampirkan ke elemen pratinjau komponen.
Gambar 21 Wadah Overlay cdk dilampirkan ke dom yang ditentukan. Pratinjau sebagian tema berhasil.
Ada juga OverlayContainerRef khusus di pustaka komponen DevUI untuk beberapa komponen dan bangku laci kotak modal, yang juga perlu diganti. Terakhir, lapisan pop-up dan lapisan pop-up lainnya dapat direalisasikan untuk mendukung tema lokal dengan sempurna.
Ringkasan poin pengetahuan : Pola abstraksi yang baik dapat membuat modul dapat diganti dan mencapai aspek pemrograman yang elegan.
kasus terakhir, saya ingin berbicara tentang pendekatan yang kurang formal memfasilitasi pemahaman semua orang tentang sifat penyedia. , mengonfigurasi penyedia pada dasarnya berarti membiarkannya membantu Anda membuat instance atau memetakan ke instance yang ada.
Kita tahu bahwa jika cdkOverlay digunakan, jika kita ingin kotak pop-up mengikuti scroll bar dan ditangguhkan di posisi yang benar, kita perlu menambahkan instruksi cdkScrollable ke scroll bar.
Skenarionya masih sama dengan contoh sebelumnya. Seluruh halaman kita dimuat melalui perutean. Untuk mempermudah, saya menulis bilah gulir pada host komponen.
Gambar 22 Bilah gulir luapan konten menulis overflow:auto di komponen:host.
Dengan cara ini kita menghadapi masalah yang lebih sulit. Modul ditentukan oleh definisi router, yaitu, <app-theme-picker-customize></app-theme-picker-customize> , lalu bagaimana cara menambahkan instruksi cdkScrollable? Solusinya adalah sebagai berikut. Beberapa kode disembunyikan di sini dan hanya tersisa kode inti.
Gambar 23 Buat sebuah instance melalui injeksi dan panggil siklus hidup secara manual.
Di sini, sebuah instance cdkScrollable dihasilkan melalui injeksi, dan siklus hidup dipanggil secara sinkron selama tahap siklus hidup komponen.
Solusi ini bukanlah cara yang formal, namun menyelesaikan masalah, dibiarkan di sini sebagai ide dan eksplorasi untuk dicicipi oleh pembaca.
Ringkasan poin pengetahuan : Penyedia konfigurasi injeksi ketergantungan dapat membuat instance, namun perlu diingat bahwa instance akan diperlakukan sebagai kelas Layanan biasa dan tidak dapat memiliki siklus hidup yang lengkap.
silakan merujuk ke posting blog ini: "Rendering aplikasi Angular di Terminal"
Gambar 24 Mengganti renderer RendererFactory2 dan konten lainnya agar Angular
dapat berjalan di terminal
.Ini adalah fleksibilitas desain Angular. Bahkan platformnya dapat diganti. Detail detail penggantian dapat ditemukan di artikel asli dan tidak akan diperluas di sini.
Ringkasan poin pengetahuan : Kekuatan injeksi ketergantungan adalah penyedia dapat mengkonfigurasinya sendiri dan akhirnya mengimplementasikan logika penggantian.
Artikel ini memperkenalkan mode injeksi ketergantungan dari inversi kontrol dan manfaatnya. Artikel ini juga memperkenalkan cara injeksi ketergantungan di Angular mencari dependensi, cara mengonfigurasi penyedia, cara menggunakan dekorator terbatas dan memfilter untuk mendapatkan instance yang diinginkan, dan selanjutnya melalui N kasus menganalisis bagaimana menggabungkan poin pengetahuan injeksi ketergantungan untuk memecahkan masalah yang dihadapi dalam pengembangan dan pemrograman.
Dengan memahami proses pencarian ketergantungan dengan benar, kita dapat mengonfigurasi penyedia di lokasi yang tepat (Kasus 1 dan 2), mengganti instance lain dengan singleton (Kasus 4 dan 5), dan bahkan terhubung melintasi batasan paket komponen bersarang. Kasus 3) atau gunakan kurva metode yang disediakan untuk mengimplementasikan instantiasi instruksi (Kasus 6).
Kasus 5 tampaknya merupakan pengganti yang sederhana, tetapi untuk dapat menulis struktur kode yang dapat diganti memerlukan pemahaman mendalam tentang mode injeksi dan abstraksi yang lebih baik dan masuk akal dari setiap fungsi. Jika abstraksinya tidak sesuai, ketergantungan tidak dapat digunakan. Mode injeksi menyediakan lebih banyak ruang bagi modul untuk dapat dipasang, dipasang, dan berbasis komponen, sehingga mengurangi sambungan dan meningkatkan fleksibilitas, sehingga modul dapat bekerja sama dengan lebih elegan dan harmonis.
Fungsi injeksi ketergantungan yang kuat tidak hanya dapat mengoptimalkan jalur komunikasi komponen, tetapi yang lebih penting, fungsi ini juga dapat mencapai inversi kontrol, memaparkan komponen yang dienkapsulasi ke lebih banyak aspek pemrograman, dan penerapan beberapa logika khusus bisnis juga dapat menjadi lebih fleksibel.