Styling dan CSS

Cascading Style Sheets (CSS) adalah bahasa untuk menentukan presentasi dokumen secara terpusat alih-alih format hard-coding untuk teks dan objek. Fitur cascading bahasa dirancang untuk mengontrol prioritas antar gaya dengan menggunakan pewarisan. Saat Anda mengerjakan frontend mikro dan membuat strategi untuk mengelola dependensi, fitur cascading bahasa bisa menjadi tantangan.

Misalnya, dua mikro-frontend hidup berdampingan pada halaman yang sama, masing-masing mendefinisikan styling sendiri untuk elemen HTML. body Jika masing-masing mengambil file CSS sendiri dan menempelkannya ke DOM dengan menggunakan style tag, file CSS akan menimpa yang pertama jika keduanya memiliki definisi untuk elemen HTML umum, nama kelas atau ID elemen. Ada berbagai strategi untuk mengatasi masalah ini, tergantung pada strategi ketergantungan yang Anda pilih untuk mengelola gaya.

Saat ini, pendekatan paling populer untuk menyeimbangkan kinerja, konsistensi, dan pengalaman pengembang terdiri dari pengembangan dan pemeliharaan sistem desain.

Sistem desain - Pendekatan berbagi sesuatu

Pendekatan ini menggunakan sistem untuk berbagi gaya bila sesuai sambil mendukung divergensi sesekali untuk menyeimbangkan konsistensi, kinerja, dan pengalaman pengembang. Sistem desain adalah kumpulan komponen yang dapat digunakan kembali, dipandu oleh standar yang jelas. Pengembangan sistem desain biasanya didorong oleh satu tim dengan masukan dan kontribusi dari banyak tim. Dalam istilah praktis, sistem desain adalah cara untuk berbagi elemen tingkat rendah yang dapat diekspor sebagai JavaScript perpustakaan. Pengembang micro-frontend dapat menggunakan library sebagai dependensi untuk membangun antarmuka sederhana dengan menyusun sumber daya yang tersedia dan sebagai titik awal untuk membuat antarmuka baru.

Perhatikan contoh frontend mikro yang membutuhkan formulir. Pengalaman pengembang yang khas terdiri dari penggunaan komponen premade yang tersedia dalam sistem desain untuk menyusun kotak teks, tombol, daftar dropdown, dan elemen UI lainnya. Pengembang tidak perlu menulis gaya apa pun untuk komponen yang sebenarnya, hanya untuk tampilannya bersama. Sistem untuk membangun dan merilis dapat menggunakan Federasi Modul webpack atau pendekatan serupa untuk mendeklarasikan sistem desain sebagai ketergantungan eksternal, sehingga logika formulir dikemas tanpa menyertakan sistem desain.

Beberapa frontend mikro kemudian dapat melakukan hal yang sama untuk mengatasi masalah bersama. Ketika tim mengembangkan komponen baru yang dapat dibagi antara beberapa frontend mikro, komponen tersebut ditambahkan ke sistem desain setelah mencapai kematangan.

Keuntungan utama dari pendekatan sistem desain adalah tingkat konsistensi yang tinggi. Sementara micro-frontend dapat menulis gaya dan kadang-kadang mengesampingkannya dari sistem desain, hanya ada sedikit kebutuhan untuk itu. Elemen tingkat rendah utama tidak sering berubah, dan mereka menawarkan fungsionalitas dasar yang dapat diperpanjang secara default. Keuntungan lainnya adalah kinerja. Dengan strategi yang baik untuk membangun dan merilis, Anda dapat menghasilkan bundel bersama minimal yang diinstrumentasi oleh shell aplikasi. Anda dapat meningkatkan lebih jauh lagi ketika beberapa bundel spesifik mikro-frontend dimuat secara asinkron sesuai permintaan, dengan jejak minimal dalam hal bandwidth jaringan. Last but not least, pengalaman pengembang sangat ideal karena orang dapat fokus membangun antarmuka yang kaya tanpa menciptakan kembali roda (seperti menulis JavaScript dan CSS setiap kali tombol perlu ditambahkan ke halaman).

Kelemahannya adalah bahwa sistem desain dalam bentuk apa pun adalah ketergantungan, sehingga harus dipertahankan dan terkadang diperbarui. Jika beberapa frontend mikro memerlukan versi baru dari dependensi bersama, Anda dapat menggunakan salah satu dari berikut ini:

• Mekanisme orkestrasi yang kadang-kadang dapat mengambil beberapa versi ketergantungan bersama itu tanpa konflik

• Strategi bersama untuk memindahkan semua tanggungan untuk menggunakan versi baru

Misalnya, jika semua frontend mikro bergantung pada versi 3.0 dari sistem desain dan ada versi baru bernama 3.1 untuk digunakan secara bersama, Anda dapat menerapkan flag fitur untuk semua mikro-frontend untuk bermigrasi dengan risiko minimal. Untuk informasi selengkapnya, lihat bagian Bendera fitur. Kelemahan potensial lainnya adalah bahwa sistem desain biasanya mengatasi lebih dari sekadar gaya. Mereka juga mencakup JavaScript praktik dan alat. Aspek-aspek ini membutuhkan mencapai konsensus melalui debat dan kolaborasi.

Menerapkan sistem desain adalah investasi jangka panjang yang baik. Ini adalah pendekatan yang populer, dan harus dipertimbangkan oleh siapa pun yang bekerja pada arsitektur frontend yang kompleks. Biasanya membutuhkan insinyur frontend dan tim produk dan desain untuk berkolaborasi dan menentukan mekanisme untuk berinteraksi satu sama lain. Penting untuk menjadwalkan waktu untuk mencapai kondisi yang diinginkan. Penting juga untuk memiliki sponsor dari kepemimpinan sehingga orang dapat membangun sesuatu yang dapat diandalkan, terpelihara dengan baik, dan berkinerja dalam jangka panjang.

CSS yang dienkapsulasi sepenuhnya - Pendekatan berbagi apa-apa

Setiap micro-frontend menggunakan konvensi dan alat untuk mengatasi fitur cascading CSS. Contohnya adalah memastikan gaya setiap elemen selalu dikaitkan dengan nama kelas alih-alih ID elemen, dan nama kelas selalu unik. Dengan cara ini, semuanya tercakup pada frontend mikro individu, dan risiko konflik yang tidak diinginkan diminimalkan. Shell aplikasi biasanya bertugas memuat gaya micro-frontends setelah dimuat ke DOM, meskipun beberapa alat menggabungkan gaya bersama dengan menggunakan. JavaScript

Keuntungan utama dari tidak berbagi apa pun adalah berkurangnya risiko memperkenalkan konflik antara frontend mikro. Keuntungan lainnya adalah pengalaman pengembang. Setiap frontend mikro tidak berbagi apa pun dengan frontend mikro lainnya. Melepaskan dan menguji secara terpisah lebih sederhana dan lebih cepat.

Kerugian utama dari pendekatan share-nothing adalah potensi kurangnya konsistensi. Tidak ada sistem untuk menilai konsistensi. Bahkan jika menduplikasi apa yang dibagikan adalah tujuannya, itu menjadi tantangan saat menyeimbangkan kecepatan rilis dan kolaborasi. Mitigasi umum adalah menciptakan alat untuk mengukur konsistensi. Misalnya, Anda dapat membuat sistem untuk mengambil tangkapan layar otomatis dari beberapa frontend mikro yang dirender di halaman dengan browser tanpa kepala. Anda kemudian dapat meninjau tangkapan layar secara manual sebelum rilis. Namun, itu membutuhkan disiplin dan tata kelola. Untuk informasi selengkapnya, lihat bagian Menyeimbangkan otonomi dengan penyelarasan.

Bergantung pada kasus penggunaan, potensi kerugian lainnya adalah kinerja. Jika sejumlah besar gaya digunakan oleh semua frontend mikro, pelanggan harus mengunduh banyak kode duplikat. Itu akan berdampak negatif pada pengalaman pengguna.

Pendekatan share-nothing ini harus dipertimbangkan hanya untuk arsitektur micro-frontend yang hanya melibatkan beberapa tim, atau frontend mikro yang dapat mentolerir konsistensi rendah. Ini juga bisa menjadi langkah awal alami saat organisasi sedang mengerjakan sistem desain.

CSS Global Bersama - Pendekatan berbagi semua

Dengan pendekatan ini, semua kode yang terkait dengan styling disimpan dalam repositori pusat di mana kontributor menulis CSS untuk semua micro-frontend dengan bekerja pada file CSS atau dengan menggunakan preprocessors seperti Sass. Ketika perubahan dibuat, sistem build membuat bundel CSS tunggal yang dapat di-host di CDN dan disertakan dalam setiap micro-frontend oleh shell aplikasi. Pengembang micro-frontend dapat merancang dan membangun aplikasi mereka dengan menjalankan kode mereka melalui shell aplikasi yang dihosting secara lokal.

Terlepas dari keuntungan nyata dari mengurangi risiko konflik antara frontend mikro, keuntungan dari pendekatan ini adalah konsistensi dan kinerja. Namun, memisahkan gaya dari markup dan logika membuat pengembang lebih sulit untuk memahami bagaimana gaya digunakan, bagaimana mereka dapat berkembang, dan bagaimana mereka dapat ditinggalkan. Misalnya, mungkin lebih cepat untuk memperkenalkan nama kelas baru daripada belajar tentang kelas yang ada dan konsekuensi dari mengedit propertinya. Kerugian dari membuat nama kelas baru adalah pertumbuhan ukuran bundel, yang memengaruhi kinerja, dan potensi pengenalan inkonsistensi dalam pengalaman pengguna.

Meskipun CSS global bersama dapat menjadi titik awal monolith-to-micro-frontends migrasi, jarang bermanfaat untuk arsitektur mikro-frontend yang melibatkan lebih dari satu atau dua tim yang berkolaborasi bersama. Kami merekomendasikan berinvestasi dalam sistem desain sesegera mungkin dan menerapkan pendekatan share-nothing saat sistem desain sedang dalam pengembangan.