CSS-in-JS , yang bukan merupakan teknologi yang sepenuhnya baru dan diimplementasikan di banyak perpustakaan , masih menimbulkan keraguan dan perdebatan tentang kesesuaian penggunaannya. Gajus Kuizinas , penulis react-css-modules dan babel-plugin , mengatur titik-titiknya di atas "i" dalam perselisihan tentang CSS-in-JS secara umum, dan tentang komponen yang ditata secara khusus, setahun yang lalu (27 Apr 2017). -react-css-modules , dalam publikasi saya yang menurut pendapat saya saat ini "Hentikan penggunaan CSS-in-JavaScript dalam pengembangan web . "
Berikut ini adalah terjemahan yang sedikit diringkas dengan beberapa tambahan dan kesimpulan:
CSS tidak kemana-mana . Dalam banyak proyek, pilihan penataan dalam JavaScript salah. Kami akan membuat daftar kesalahpahaman umum (mitos) dan keputusan terkait melalui CSS.
Sejarah Css dan JavaScript
CSS dibuat untuk menggambarkan penyajian dokumen yang ditulis dalam bahasa markup. JavaScript dibuat sebagai "lem bahasa" untuk merakit komponen seperti gambar dan plugin. Selama bertahun-tahun, JS telah tumbuh dan berubah, beradaptasi dengan bidang aplikasi yang baru. Dan, sebagai hasilnya, hari ini kita hidup di era aplikasi satu halaman (SPA), aplikasi yang dikumpulkan dari komponen.
Bagaimana dengan CSS?
Berikut ini kutipan dari dokumentasi komponen-gaya :
Masalah dengan CSS biasa adalah bahwa itu dibuat di era ketika web terdiri dari dokumen. Web diciptakan untuk bertukar dokumen yang sebagian besar ilmiah pada tahun 1993 dan CSS diperkenalkan sebagai solusi untuk menata dokumen-dokumen ini. Namun, hari ini kami sedang mengembangkan aplikasi yang dikembangkan, interaktif, berorientasi pengguna, dan CSS sama sekali tidak dirancang untuk ini.
Ini tidak benar.
CSS sudah memperhitungkan semua persyaratan antarmuka pengguna modern. Jumlah fungsi baru yang diterapkan dalam dekade terakhir sedemikian rupa sehingga tidak mungkin untuk meratakan semuanya (pseudo-class, pseudo-elements, variabel CSS, kueri media, kerangka kunci, kombinator, kolom, flex, kisi, kisi nilai, ...).
Dari sudut pandang antarmuka pengguna, "komponen" adalah bagian terpisah dari dokumen (<tombol /> adalah "komponen"). CSS dirancang untuk menata dokumen, dan dokumen tersebut mencakup semua komponen. Apa masalahnya?
Seperti kata pepatah: "Gunakan alat yang tepat untuk pekerjaan itu."
Komponen yang ditata
komponen-gaya memungkinkan untuk menulis CSS dalam JavaScript menggunakan apa yang disebut string templat yang ditandai . Perpustakaan menghapus pemetaan antara komponen dan gaya - komponen berubah menjadi konstruksi gaya tingkat rendah, misalnya:
// Create a <Title> react component that renders an <h1> which is // centered, palevioletred and sized at 1.5em const Title = styled.h1` font-size: 1.5em; text-align: center; color: palevioletred; `;
styled-components populer saat ini dan dikenal sebagai cara baru untuk menata komponen di React, meskipun kadang-kadang bahkan disajikan sebagai "puncak pengembangan CSS":
Evolusi CSS: Dari CSS, SASS, BEM, Modul CSS ke Komponen Gaya .
Tapi mari kita perjelas berikut ini: komponen yang ditata hanyalah add-on CSS. Pustaka ini mem-parsing gaya CSS yang Anda tetapkan dalam JavaScript dan membuat elemen JSX yang sesuai.
Popularitas komponen yang ditata penuh dengan banyak kesalahpahaman. Tinjauan terhadap jawaban programmer (ditemukan di IRC, Reddit, dan Discord) untuk pertanyaan tentang alasan yang mendorong mereka untuk menggunakan perpustakaan ini memungkinkan untuk membuat daftar yang paling banyak disebutkan. Sebut saja mitos.
Mitos # 1: komponen ditata memecahkan masalah namespace global dan konflik gaya
Ini adalah mitos, karena kedengarannya seperti masalah yang disebutkan belum diselesaikan. Namun, Modul CSS , Shadow DOM, dan konvensi penamaan yang tak terhitung jumlahnya (seperti BEM ) menawarkan solusi untuk masalah ini sejak lama.
komponen-gaya (seperti modul CSS) menghilangkan masalah penamaan tanggung jawab dari seseorang. Sudah menjadi sifat manusia untuk melakukan kesalahan, komputer tidak sering melakukan kesalahan.
Dengan sendirinya, ini bukan alasan yang cukup baik untuk menggunakan komponen bergaya.
Mitos 2: Menggunakan komponen yang ditata memungkinkan untuk mendapatkan kode yang lebih ringkas.
Untuk mendukung ini, sebuah contoh sering diberikan:
<TicketName></TicketName> <div className={styles.ticketName}></div>
Pertama-tama, itu tidak masalah. Perbedaannya dapat diabaikan.
Kedua, ini tidak benar. Jumlah karakter tergantung pada nama gaya.
<TinyBitLongerStyleName></TinyBitLongerStyleName> <div className={styles.longerStyleName}></div>
Hal yang sama berlaku untuk membuat gaya, yang akan kita lihat nanti dalam artikel ini.
(Mitos 5: komponen yang ditata memfasilitasi gaya penataan komponen yang kondisional). komponen-komponen gaya menang dalam singkat hanya dalam kasus komponen paling dasar.
Mitos 3. Menggunakan komponen gaya membuat Anda lebih memikirkan semantik.
Pesan asli itu sendiri salah. Stilisasi dan semantik adalah masalah yang berbeda dan memerlukan solusi yang berbeda. Baca, misalnya, ini adalah Adam Morse (mrmrs) .
Namun, pertimbangkan:
<PersonList> <PersonListItem> <PersonFirstName>Foo</PersonFirstName> <PersonLastName>Bar</PersonLastName> </PersonListItem> </PersonList>
Semantik berkaitan dengan penggunaan tag yang benar untuk markup. Apakah Anda tahu tag HTML apa yang akan digunakan untuk membuat komponen seperti itu? Tidak, Anda tidak tahu.
Bandingkan:
<ol> <li> <span className={styles.firstName}>Foo</span> <span className={styles.lastName}>Bar</span> </li> </ol>
Mitos 4: Mengembangkan gaya lebih mudah.
Bandingkan:
const Button = styled.button` padding: 10px; `; const TomatoButton = Button.extend` color: #f00; `;
Hebat! Tetapi Anda dapat melakukan hal yang sama dalam CSS (atau menggunakan komposisi modul CSS, serta mixin inheritance SASS @extend).
button { padding: 10px; } button.tomato-button { color: #f00; }
Dan semakin sederhana pilihan pertama?
Mitos 5: Styling komponen bersyarat yang difasilitasi
Idenya adalah Anda dapat menata elemen menggunakan alat peraga, misalnya:
<Button primary /> <Button secondary /> <Button primary active={true} />
Itu masuk akal dalam Bereaksi. Pada akhirnya, perilaku komponen dikendalikan melalui alat peraga. Apakah masuk akal untuk langsung mengikat nilai prop ke gaya? Mungkin Tapi mari kita lihat implementasi komponen seperti itu:
styled.Button` background: ${props => props.primary ? '#f00' : props.secondary ? '#0f0' : '#00f'}; color: ${props => props.primary ? '#fff' : props.secondary ? '#fff' : '#000'}; opacity: ${props => props.active ? 1 : 0}; `;
Membuat gaya bersyarat menggunakan JavaScript menyediakan banyak kemungkinan. Namun, ini juga berarti bahwa gaya akan jauh lebih sulit untuk ditafsirkan. Bandingkan dengan CSS:
button { background: #00f; opacity: 0; color: #000; } button.primary, button.seconary { color: #fff; } button.primary { background: #f00; } button.secondary { background: #0f0; } button.active { opacity: 1; }
Dalam hal ini, CSS lebih pendek (229 karakter berbanding 222) dan lebih mudah dipahami (secara subyektif). Selain itu, di CSS Anda bisa menggunakan preprocessor untuk mendapatkan hasil yang lebih pendek dan dikelompokkan:
button { background: #00f; opacity: 0; color: #000; &.primary, &.seconary { color: #fff; } &.primary { background: #f00; } &.secondary { background: #0f0; } &.active { opacity: 1; } }
Mitos 6: Organisasi Kode Membaik
Beberapa mengatakan bahwa mereka menyukai komponen yang ditata, karena memungkinkan untuk menempatkan gaya dan skrip dalam satu file. Anda dapat memahami bahwa memiliki banyak file untuk satu komponen mungkin terasa membosankan, tetapi mendorong gaya dan tata letak menjadi satu file sangat buruk. Sistem kontrol versi ini tidak hanya akan mempersulit perubahan pelacakan, tetapi juga akan menyebabkan “pengguliran” tanpa akhir pada elemen apa pun yang lebih rumit daripada tombol sederhana.
Jika Anda tentu perlu meletakkan CSS dan JavaScript di file yang sama, coba css-literal-loader . Yang terakhir memungkinkan Anda untuk membangun gaya selama membangun menggunakan ekstrak-teks-webpack-plugin dan menggunakan konfigurasi pemuat standar untuk menangani CSS.
Mitos 7: “Pengalaman Pengembang (DX)” menjadi luar biasa. Alat ini luar biasa!
Jelas Anda tidak menggunakan komponen yang ditata.
- Jika ada yang salah dengan gaya, seluruh aplikasi lumpuh dengan jejak kesalahan yang panjang. Kebalikan dari ini adalah CSS, di mana kesalahan dalam gaya hanya akan menyebabkan tampilan elemen yang salah.
- Elemen tidak memiliki className yang dapat dibedakan, jadi selama debugging Anda harus beralih tanpa henti antara pohon elemen React dan pohon DOM DevTools.
- Meskipun plugin untuk linting, highlight kode, penyelesaian kode, dan "pesona" serupa lainnya sudah ada untuk komponen yang ditata, mereka mungkin masih belum tersedia untuk IDE Anda. Jika Anda bekerja dengan keuangan di lembaga pemerintah, ada kemungkinan Atom Atom tidak tersedia.
Mitos 8: Semuanya menjadi "lebih cepat", semuanya menjadi "lebih mudah"
- Ternyata, gaya komponen-gaya tidak dapat diekstraksi menjadi statis
File CSS (mis. Menggunakan ekstrak-teks-webpack-plugin ). Ini berarti bahwa browser tidak akan dapat mulai menafsirkan gaya sampai komponen yang ditata mem-parsing mereka dan menambahkannya ke DOM. - Menggabungkan gaya dan skrip dalam satu file berarti bahwa cache yang terpisah tidak dimungkinkan.
- Sifat komponen yang ditata sedemikian rupa sehingga semuanya dibungkus dalam HOC tambahan. Dan ini adalah penurunan kinerja yang tidak perlu. Kelemahan yang sama menyebabkan penghentian modul react-css dan munculnya babel-plugin-react-css-modules .
- Karena HOC yang sama, rendering sisi-server menghasilkan ukuran markup dokumen yang jauh lebih besar.
- Bahkan tidak mencoba menghidupkan komponen menggunakan gaya dinamis daripada bingkai kunci.
Mitos 9: Ada kemungkinan mengembangkan komponen "responsif"
Kita berbicara tentang kemampuan untuk mendesain komponen berdasarkan lingkungan, misalnya, ukuran wadah induk, jumlah ahli waris, dll.
Pertama-tama, komponen yang ditata tidak ada hubungannya dengan ini.
Ini di luar cakupan proyek. Dalam hal ini, lebih baik mengatur nilai gaya komponen secara langsung untuk menghindari beban prosesor tambahan.
Tunggu sebentar!
Sebagian besar, jika tidak semua masalah ini dapat diselesaikan dalam jangka panjang baik oleh komunitas, dengan perubahan Bereaksi atau dalam komponen yang ditata sendiri. Tapi mengapa? CSS sudah didukung secara luas, ada komunitas yang solid dan ... hanya berfungsi.
Tetapi Anda tidak harus selalu menghindari penggunaan komponen CSS-in-JavaScript atau gaya.
Ada sesuatu yang membuat komponen bergaya menjadi pustaka yang bagus - ini adalah dukungan lintas platform terbaik.
Hanya saja, jangan menggunakan komponen bergaya berdasarkan pada representasi yang salah.
Sepasang pendapat dari pihak yang berkepentingan.
Dengan menggunakan komponen yang ditata dalam proyek kami, kami menemukan bahwa ada beberapa aturan gaya yang sulit untuk diterapkan dalam komponen yang ditata; misalnya, aturan yang mengontrol penempatan elemen pada halaman (margin atau properti tampilan). Itu sulit untuk dibakukan, jadi kami masih harus bergantung pada CSS sederhana untuk menempatkan komponen dalam aliran elemen.
... meskipun ada kesulitan dalam menggunakan komponen yang ditata, perpustakaan membantu kami mengurangi basis kode.
(komentar tentang "Evolusi CSS: dari CSS, SASS, BEM dan CSS - modul hingga komponen yang ditata" )
... Tidak ada evolusi CSS di sini berarti alat berevolusi.
Menurut pendapat saya, tidak ada masalah ketika penyusunan huruf terlibat dalam tata letak, dan programmer terlibat dalam pemrograman.
Tetapi ketika programmer terlibat dalam pengaturan huruf, maka seluruh kebun binatang ini dimulai, yang bukannya SIMPLICITY dengan dukungan lebih lanjut, memberikan sakit kepala tambahan.
...
Tulis dalam CSS murni, dan berikan alat peran namespace dan kolektor - maka semuanya akan bahagia ...
Dan akhirnya, sepatah kata untuk penulis:
Gajus Kuizinas: - Jadi, apa yang harus digunakan?