Selamat siang
Kisah publikasi ini cukup sederhana dan mungkin akrab bagi banyak orang. Perusahaan mengembangkan banyak produk - dalam kasus kami, terutama untuk satu pelanggan. Baru-baru ini, semua solusi dikembangkan untuk web, dan solusi desktop yang ada di web ditransfer.
Dalam hal ini, jika ada keinginan untuk meningkatkan kecepatan pengembangan dan memastikan keseragaman produk, diputuskan untuk mengembangkan basis komponen umum. Kami tidak akan berbicara tentang bagaimana kit ui dibuat dan tentang pertempuran panjang dengan desainer, tetapi saya ingin berbicara tentang implementasi tugas ini.
Di depan, kita memiliki demokrasi atau bahkan anarki. Orang bebas menggunakan solusi yang mereka sukai. Saat ini ada proyek dalam pertempuran di AngularJS, Angular, React, Vanilla, dan ada juga proyek di Vue untuk penggunaan internal. Pada titik ini, pandangan kami beralih ke komponen web.
Komponen web
Mari kita lihat konsep komponen web. Ini didasarkan pada konsep elemen kustom, yang memungkinkan Anda untuk memperluas kelas HTMLElement dengan membuat tag html Anda sendiri, dengan logika bisnis yang disembunyikan dari pengguna. Kedengarannya keren, terlihat bagus. Mari kita lihat apa yang bisa kita lakukan. Selanjutnya, kode sumber diberikan dalam bentuk naskah.
Untuk membuat elemen khusus, kita perlu melakukan hal berikut. Jelaskan kelas dan daftarkan komponen.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('Here I am'); } } if (!customElements.get('new-custom-element')) { customElements.define('new-custom-element', NewCustomElement); }
Selanjutnya, dengan menghubungkan kode ini ke html apa pun (kompilasi dalam JS), kami dapat menggunakan komponen (kami akan kembali ke ini, pada kenyataannya, jika klien Anda tidak berani menggunakan Chrome).
Elemen khusus juga memberi kami beberapa kait untuk melacak umur komponen.
export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('I am created'); } connectedCallback() { console.log('Now I am in Dom'); this._render(); this._addEventListeners(); } disconnectedCallback() { console.log('I am removed now'); this._removeEventListeners(); } static get observedAttributes() { return ['date']; } attributeChangedCallback(attrName, oldVal, newVal) { switch (attrName) { case 'date': { break; } } } adoptedCallback() { } }
Kami juga dapat membuat acara dalam komponen melalui metode dispatchEvent
export class NewCustomElement extends HTMLElement {
Masa depan telah datang, kata mereka, Anda menulis kode sekali dan menggunakannya di mana-mana, kata mereka
Kami sedikit berkenalan dengan komponen, sekarang saya akan berbicara tentang perasaan yang tersisa setelah bekerja dengan teknologi ini. Secara umum, dalam artikel
Komponen Web di Dunia Nyata, penulis menggambarkan sikap terhadap teknologi yang ternyata sangat dekat dengan saya.
Mari kita lihat keuntungan apa yang kita dapatkan.
- Dapat digunakan kembali : kami memiliki perpustakaan yang benar-benar dapat digunakan kembali. Saat ini, ia bekerja di proyek vanilla, menghubungkan sebagai bundel Webpack yang dikompilasi, dan dalam proyek 7 angular, menghubungkan sebagai sumber naskah di AppModule
- Perilaku yang dapat dimengerti : jika Anda mengikuti praktik terbaik , kami mendapatkan komponen dengan perilaku yang dapat dipahami yang dapat dengan mudah diintegrasikan ke dalam kerangka kerja yang ada, misalnya, untuk sudut, menggunakan pisang dalam kotak, dalam aplikasi asli melalui atribut, atau bekerja dengan properti yang mencerminkan atribut
- Gaya terpadu : ini adalah pengulangan poin tentang usabilitas ulang, tapi tetap saja. Sekarang semua proyek menggunakan blok bangunan tunggal untuk pembangunan UI.
- Sejujurnya, saya tidak dapat memberikan keuntungan lagi : beri tahu kami bagaimana WebComponents membantu Anda.
Selanjutnya, saya akan mencoba menggambarkan hal-hal yang mungkin tidak saya sukai.
- Biaya tenaga kerja : biaya pengembangan komponen jauh lebih tinggi daripada pengembangan kerangka kerja.
- Penamaan : komponen bersaing secara global, sehingga nama kelas dan nama tag harus diawali. Mengingat bahwa kami masih memiliki pustaka komponen yang diimplementasikan dalam kerangka kerja yang dinamai sebagai < company -component-name>, kami harus mengawali komponen web dua kali dengan < company-wc -component-name>.
- ShadowRoot : Menurut praktik terbaik, disarankan menggunakan shadowRoot. Namun, ini sangat tidak nyaman, karena tidak ada kemungkinan untuk mempengaruhi penampilan komponen dari luar. Dan kebutuhan seperti itu sering dijumpai.
- Render : tanpa kerangka kerja, Anda harus melupakan pengikatan dan reaktivitas data (LitElement untuk membantu, tetapi ini adalah ketergantungan lainnya).
- Masa depan belum tiba : Untuk mempertahankan dukungan pengguna di tingkat lama (kami memilikinya yaitu11 dan segala sesuatu yang lebih segar), Anda harus mengencangkan polyphiles, es5 adalah standar target, yang menciptakan masalah tambahan.
- Polyphils sendiri : Untuk mendapatkan semua hal ini di bawah IE, saya harus menyiksa banyak dan membuat beberapa keputusan buruk, karena polycoms dari webcomponent memecahkan sesuatu di dalam hanggar, menyebabkan panggilan stack overflow. Akibatnya, saya harus polyfill, setelah menerima dependensi tambahan.
Saya tidak tahu kesimpulan mana yang bisa ditarik dari semua ini. Jika Microsoft membuat peramban berbasis kromium dan berhenti mendukung IE dan Edge, maka ya, pernafasan akan menjadi lebih mudah.
Ada satu manfaat aneh: Anda dapat memberikan pengembangan komponen web bersih untuk pengembang pemula - biarkan mereka melihat bagaimana itu, menulis di JS tanpa kerangka kerja. Seorang kolega untuk waktu yang lama tidak dapat memahami mengapa perubahan properti dalam komponen tidak segera tercermin dalam DOM. Di sini mereka adalah orang-orang yang tumbuh dalam kerangka kerja. Dan saya sama.