Kami, front-end, memiliki kategori alat yang tidak menyelesaikan masalah yang kami hadapi, tetapi lebih memengaruhi proses penyelesaiannya. Ubah itu. Sikap terhadap alat-alat seperti itu sangat berbeda - mulai dari mania dalam semangat "mari kita dorong benda ini ke mana-mana, itu sangat keren" dan diakhiri dengan alasan seperti "jika itu tidak menyelesaikan masalah bisnis, maka kita tidak membutuhkannya". Tetapi, bagaimanapun, hari ini kita akan berbicara tentang PostCSS - salah satu alat tersebut.
Gelombang sensasi telah lama berlalu, dalam beberapa tahun terakhir, sangat sedikit yang dikatakan tentang PostCSS. Banyak pemula bahkan tidak tahu apa itu. Saya pikir sudah waktunya untuk melihat alat ini dari sudut pandang penggunaan praktis dalam proyek yang paling biasa, di mana orang memecahkan masalah, dan tidak bermain-main dengan teknologi modern.
PostCSS vs SASS
Oh ... Rupanya beberapa kata tentang ini. Saya pikir sekarang penyetem langka tidak bertemu dengan preprosesor. SASS atau KURANG favorit saya, lebih jarang Stylus, digunakan baik pada proyek besar maupun kecil. Seseorang mencoba memeras sebagian besar dari mereka, seseorang menggunakan set-nesting, variabel, impor minimum. Tetapi, satu atau lain cara, alat-alat ini membantu dengan masalah sintaksis. Mereka membuatnya lebih mudah bagi kita untuk menulis kode.
Sekitar dua atau tiga tahun yang lalu PostCSS secara konstan dibandingkan dengan preprosesor. Dan itu bisa dimengerti. Secara formal, dengan menggunakannya Anda dapat melakukan hal yang sama, membuat semacam sintaks yang akan lebih nyaman daripada CSS murni. Tetapi semua ini menyebabkan massa yang menggelegak, terutama karena semua orang dengan bantuan PostCSS melakukan sesuatu yang berbeda. Tak terhitung plugin yang tidak diketahui, jutaan kombinasi, dan terlepas dari pembuat konfigurasi ini atau itu, tidak ada yang mengerti cara kerjanya dan apa fungsinya. Ini seperti Vim atau Emacs - Anda dapat membuat pesawat luar angkasa dari mereka, tetapi akan sangat sulit untuk mengajari pengembang lain cara menggunakannya.
Tetapi jika kita membuang perbandingan ini, maka PostCSS adalah alat yang memungkinkan kita untuk mengambil CSS kita dan melakukan sesuatu dengannya. Tidak ada yang mengganggu untuk menggunakan SASS demi sintaks, dan setelah perakitan, tempel PostCSS dan lakukan sesuatu dengan hasilnya. Mereka tidak saling bertentangan.
Tua bukan berarti menganggur
Baru-baru ini, telah menjadi mode bagi kami untuk membuat kombinasi yang dapat melakukan segala sesuatu yang hanya terpikirkan, dan pengembangannya tidak pernah berhenti. Dan jika tidak ada komitmen baru dalam repositori selama beberapa bulan, maka semuanya - kita dapat mengasumsikan bahwa itu sudah usang dan sekarang menggunakannya - bukan kome il faut. Saya akan membesar-besarkan, tentu saja, tetapi saya pikir Anda sendiri memperhatikan betapa absurdnya hal ini.
Di dunia PostCSS, biasanya satu plugin memecahkan satu masalah. Anda dapat melihat elemen-elemen filosofi Unix di sini. Kesimpulan logis berikut dari ini - jika plugin sudah menyelesaikan tugasnya, maka tidak ada lagi yang perlu dilakukan dengannya. Anda dapat menemukan plugin yang belum diperbarui selama bertahun-tahun, tetapi ini tidak berarti bahwa mereka tiba-tiba berhenti menyelesaikan tugas yang mereka buat.
Tapi mari kita mulai ... Saya mengumpulkan selusin plug-in, yang dalam praktiknya telah menunjukkan kemampuan mereka untuk menyederhanakan kehidupan bagi desainer tata letak dan menghemat waktu selama pengembangan. Tetapi Anda selalu dapat menambahkan sesuatu di komentar.
1 Doiuse
https://github.com/anandthakker/doiuse
Saya pikir kita semua menghadapi masalah ini: Anda menulis kode, check in chrome - semuanya baik-baik saja. Anda check-in FF - sekitar. Dan kemudian di Safari seluler semuanya berantakan. Atau di Edge. Dan Anda duduk dan tidak mengerti apa yang salah. Kemudian Anda menatap kode untuk waktu yang lama, minum teh, dan tiba-tiba muncul wawasan bahwa beberapa properti tidak didukung di beberapa browser. Anda pergi kaniuse dan Anda melihat konfirmasi yang jelas.
Tentu saja, dengan pengalaman, tangan itu sendiri mengingat sifat apa yang harus dihindari, tetapi apa pun terjadi. Anda tidak bisa cukup tidur, bisa ada tenggat waktu dan saraf yang ketat, daftar browser yang perlu diubah dapat berubah. Dan kemudian pengalaman akan mulai gagal. Doiuse adalah alat yang banyak membantu dalam situasi seperti itu.
Prinsip operasi sederhana - kami memberinya daftar browser dan CSS kami. Plugin masuk ke database caniuse dan secara real time memberi kami jawaban yang kami gunakan dari apa yang tidak didukung.
Kita dapat mengatur daftar browser secara langsung di package.json. Sederhana dan nyaman. PostCSS menggunakan daftar browser dan, jika Anda belum pernah melihatnya, tampilannya seperti ini:
"browserslist": [ "> .5% and last 2 versions", "not dead", "not OperaMini all", "ie >= 11", "Edge >= 12" ]
Ada juga konfigurasi doiuse itu sendiri, di mana Anda dapat memaksanya untuk mengabaikan beberapa grup properti jika Anda yakin itu tidak mempengaruhi apa pun. Misalnya, jika Anda menggunakan polyfiles atau dari hilangnya dukungan beberapa properti, tidak ada yang akan berubah:
ignore: [ 'will-change', 'object-fit' ]
Log standar yang disediakan oleh plugin tidak mudah dibaca. Ini berisi banyak informasi dan tidak nyaman untuk melihatnya. Tapi ini bisa diperbaiki. Dalam konfigurasi yang sama, kita bisa melakukan fungsi kita untuk membuat log.
Gunakan console.log untuk mengetahui bagaimana objek yang mengirimkan PostCSS ke fungsi ini berfungsi. Ada banyak hal menarik.
Praktik saya telah menunjukkan bahwa opsi paling mudah adalah menampilkan pemilih dan properti spesifik yang tidak didukung, tanpa menentukan peramban dan baris kode. Jika proyek menggunakan BEM atau beberapa analog, dan kode komponen didistribusikan dalam file yang terpisah, maka pendekatan ini memungkinkan Anda untuk dengan cepat menemukan tempat masalahnya tanpa memuat otak.
onFeatureUsage(info) { const selector = info.usage.parent.selector; const property = `${info.usage.prop}: ${info.usage.value}`; let status = info.featureData.caniuseData.status.toUpperCase(); if (info.featureData.missing) { status = 'NOT SUPPORTED'.red; } else if (info.featureData.partial) { status = 'PARTIAL SUPPORT'.yellow; } console.log(`\n${status}:\n\n ${selector} {\n ${property};\n }\n`); }
Agar tidak menulis urutan karakter khusus untuk warna di konsol, Anda dapat menghubungkan paket warna , itu akan lebih nyaman dengannya.
Saat membangun, akan ada sesuatu seperti ini di konsol:
NOT SUPPORTED: html { -ms-text-size-adjust: 100%; } NOT SUPPORTED: html { -webkit-text-size-adjust: 100%; } PARTIAL SUPPORT: body { display: flex; }
2 Autoprefixer
https://github.com/postcss/autoprefixer
Bahkan memalukan untuk membicarakannya, tetapi terlalu sering saya melihat orang-orang yang pada tahun 2019 menulis awalan dengan tangan mereka dan masih meyakinkan orang lain bahwa mereka tahu persis mana yang dibutuhkan dan mana yang tidak. Tindakan tersebut mengarah pada fakta bahwa kode ditumbuhi banyak awalan yang tidak perlu dan menjadi benar-benar tidak dapat dibaca. Ini mempengaruhi produktivitas tenaga kerja. Di sisi lain, jika Anda memerlukan dukungan dinosaurus, Anda selalu dapat melupakan sesuatu. Jadi ada baiknya menyingkirkan tenaga manual saat memecahkan masalah ini.
Autoprefixer bekerja dengan database caniuse yang sama, menggunakan daftar browser yang sama dan dapat menambahkan ke CSS awalan yang benar-benar diperlukan di browser yang kami tentukan. Pada saat yang sama, kode itu sendiri menjadi lebih bersih, dan pekerjaan berjalan lebih cepat.
Nomor 3 Stylelint
https://github.com/stylelint/stylelint
Ketika Anda mencetak banyak dan cepat, cepat atau lambat Anda mulai membuat banyak kesalahan tanpa benar-benar menyadarinya. Mata buram. Dalam kasus CSS, ini dapat memberikan efek lucu (sebenarnya tidak) ketika Anda melihat di browser - Anda melihat masalah dengan tata letak. Anda melihat kode - itu tidak ada di sana. Anda melihat di browser - itu. Namun dalam kode - tidak. Sebagai hasilnya, Anda dapat mencari masalah yang sulit untuk waktu yang lama, sama sekali tidak menyadari bahwa Anda baru saja berkutat. Untuk mencegah hal ini, diciptakan linter.
Stylelint adalah opsi yang populer. Dia tahu bagaimana bekerja dengan sintaks dari preprosesor utama, dia tahu tentang tren terbaru dalam CSS, dia dapat menyesuaikannya dengan seleranya - konfigurasi mirip dengan eslint. Secara formal, alat ini dapat digunakan sendiri, tanpa PostCSS, tetapi belum lagi akan salah.
Nomor 4 Postcss-flexbugs-fixes
https://github.com/luisrudge/postcss-flexbugs-fixes
Atau dalam arti yang lebih luas, perbaikan postcss , yang mencakup plugin ini. Perlahan, tapi pasti, melenturkan menggantikan pendekatan lama untuk tata letak pada pelampung. Ini bagus, tetapi kita semua tahu bahwa banyak bug terkait dengan mereka. Mereka dijelaskan dalam repositori flexbugs . Beberapa dari mereka memerlukan perhatian khusus, tetapi ada juga beberapa yang sangat sederhana sehingga mereka terus-menerus terbang keluar dari kepala Anda. Sebagai contoh, IE mengabaikan fungsi calc di singkatan untuk properti flex. Ini tidak begitu sering diperlukan, tetapi jika perlu, maka tangan Anda dapat menulis versi singkat dan kemudian Anda harus berpikir lama tentang masalahnya. Untungnya, ini dapat diperbaiki secara otomatis. Plugin postcss-flexbugs-fixes datang untuk menyelamatkan.
Dalam contoh kalk, ia akan menemukan fragmen seperti ini dalam kode:
.foo { flex: 1 0 calc(1vw – 1px); }
Dan sebarkan:
.foo { flex-grow: 1; flex-shrink: 0; flex-basis: calc(1vw - 1px); }
Sederhana dan nyaman.
No. 5. Postcss-preset-env
https://github.com/csstools/postcss-preset-env
Karena kita berbicara tentang dukungan browser, itu tidak akan keluar dari tempatnya untuk mengatakan tentang postcss-preset-env. Sebelumnya, cssnext memainkan peran yang sama. Plugin ini akan berguna jika Anda tertarik dengan tren baru di CSS.
Banyak inovasi yang secara teknis dapat diimplementasikan dengan menggunakan metode lama, itu hanya akan panjang, verbose dan jelek. Preset-env membantu Anda menulis kode dengan cara baru, menghemat waktu untuk hal ini, dan kemudian mengonversinya ke versi lama yang andal. Tentu saja, beberapa hal seperti properti khusus tidak diterapkan sama sekali di peramban lama, jadi fallback akan digunakan di sana.
Seperti yang bisa Anda tebak dari nama instrumen, itu menyerupai nama yang sama ditetapkan di Babel. Di sini, semuanya sama - ada banyak konverter yang dirangkai menjadi satu set yang stabil. Beberapa transformasi memerlukan koneksi skrip polifile berikutnya pada klien, tetapi sebagian besar diimplementasikan murni oleh CSS. Sejauh yang saya mengerti, untuk skrip Stage2 + tidak diperlukan. Bagaimanapun, saya tidak menemukan kebutuhan mereka. Perbaiki saya jika saya melewatkan sesuatu di sana.
No. 6. Postcss-animasi
https://github.com/zhouwenbin/postcss-animation
Saya sering mendengar dari orang yang berbeda (kebanyakan backend yang tidak terlalu kuat dalam CSS) bahwa mereka ingin menggunakan animasi terpisah dari animate.css , tetapi menganggap itu ide yang buruk untuk menghubungkan seluruh perpustakaan. Cukup logis. Tetapi sebagai hasilnya, mereka menghabiskan banyak waktu untuk mencoba mengulangi animasi ini sendiri.
Plugin postcss-animation sangat mempercepat proses ini. Kami hanya menulis nama animasi, misalnya:
.foo { animation-name: bounce; }
Dan dia menarik implementasinya dari animate.css dan memasukkannya ke dalam kode.
.foo { animation-name: bounce; } @keyframes bounce { from, 20%, 53%, 80%, to { animation-timing-function: cubic-bezier(0.215, 0.610, 0.355, 1.000); transform: translate3d(0,0,0); } 40%, 43% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -30px, 0); } 70% { animation-timing-function: cubic-bezier(0.755, 0.050, 0.855, 0.060); transform: translate3d(0, -15px, 0); } 90% { transform: translate3d(0,-4px,0); } }
Nomor 7 Penyeleksi daftar
https://github.com/davidtheclark/list-selectors
Ketika Anda memiliki beberapa huruf dan banyak gaya, pertanyaan muncul dari tinjauan kode, bahwa akan menyenangkan untuk kadang-kadang melihat dengan mata Anda gambaran besar dengan semua penyeleksi yang kita miliki. Ketahui ID mana yang digunakan, apakah ada pemilih tag, atau seberapa baik metodologi yang diterima diikuti. Ini sangat penting ketika Anda memeriksa kode pemula, yang dapat menulis hal-hal aneh yang secara resmi akan berfungsi, tetapi sebenarnya bertentangan dengan perjanjian yang diterima (jauh dari mana-mana perjanjian ini telah diperbaiki dengan baik dan ada peluang untuk mengotomatisasi hal-hal seperti itu). Gulir ke berbagai lembar gaya Anda sendiri untuk memeriksa kecukupan pemilih untuk waktu yang lama. Kami membutuhkan cara untuk mengisolasi mereka dan menunjukkannya secara terpisah. Daftar-pemilih hanya menyelesaikan masalah ini.
Sama seperti doiuse, plugin ini memungkinkan Anda untuk menggunakan fungsinya untuk menyiapkan informasi untuk ditampilkan. Anda hanya dapat menampilkan apa yang menarik bagi Anda, atau cat semuanya dengan warna berbeda. Sebagai contoh:
require('list-selectors').plugin((list) => { const inspect = require('util').inspect; console.log('SELECTORS:'.blue); console.log(inspect(list.selectors, { maxArrayLength: null }).blue); console.log('IDS:'.red); console.log(inspect(list.simpleSelectors.ids, { maxArrayLength: null }).red); })
Contoh ini menghasilkan daftar pemilih yang sangat panjang:
SELECTORS: [ '.mui-progress-bar', '.mui-progress-bar > .indicator', '.mui-progress-bar > .value', '.mui-progress-bar.-radial', '.mui-progress-bar.-radial > .indicator', '.mui-progress-bar.-radial > .indicator > .background', '.mui-progress-bar.-radial > .indicator > .progress', '.mui-progress-bar.-radial > .value', . . .
Nomor 8 Immutable-CSS
https://github.com/johno/immutable-css
Hal lain yang harus diperhatikan adalah mengganggu gaya dari perpustakaan pihak ketiga. Jika kita menghubungkan semacam perpustakaan, dan kemudian kita mulai menulis gaya kita sendiri untuk penyeleksi dari sana, maka pada akhirnya kita mendapatkan kode yang membingungkan di mana kita tidak bisa mengetahui dari mana asalnya. Ini dapat menyebabkan bug acak, yang kemudian memakan waktu terlalu lama. Semakin sering kita mendefinisikan ulang sesuatu, semakin sulit untuk akhirnya memahami apa yang terjadi, walaupun masalah itu sendiri yang perlu diselesaikan bisa sangat sederhana. Dalam situasi ini, alat yang disebut immutable-css mungkin berguna.
Secara umum, prinsip kerjanya sederhana: ia mengambil file dengan gaya, jika menemukan kecocokan pada penyeleksi, itu mulai menjadi marah:
! .button was mutated 2 times [line 93, col 1]: /css/basscss.css [line 3, col 1]: /css/custom.css [immutable-css] ! .left was mutated 2 times [line 291, col 1]: /css/basscss.css [line 4, col 1]: /css/custom.css [immutable-css]
Satu-satunya masalah dengan alat ini adalah tidak mendukung sintaksis non-CSS. Jadi jika preprosesor digunakan dalam proyek, maka file yang sudah dirakit harus dibandingkan. Tetapi secara umum, jika tugasnya hanya untuk memastikan bahwa tidak ada yang tanpa sengaja menulis ulang gaya dari perpustakaan pihak ketiga, maka ini tidak begitu penting.
No. 9. Bye-Bye!
https://github.com/AoDev/css-byebye
Saya pikir semua orang akrab dengan situasi ketika kita secara bertahap menambahkan beberapa komponen ke situs yang berfungsi. Beberapa dari mereka segera pergi untuk produksi, dan beberapa dari mereka duduk untuk waktu yang lama dan menunggu giliran mereka (misalnya, kami berbaikan, kami belum menyelesaikan backend). Sesuatu dapat berupa eksperimen atau solusi sementara untuk liburan. Mungkin ada banyak situasi, tetapi mereka disatukan oleh fakta bahwa kita memiliki banyak komponen, dan hanya sebagian kecil dari mereka yang digunakan di situs pertempuran. Akan menyenangkan untuk menghapus semua yang tidak digunakan dari perakitan saat ini. Ini dapat secara signifikan mengurangi ukurannya, serta mengurangi sakit kepala di masa depan, ketika akan perlu untuk melakukan desain ulang misalnya, dan pertanyaannya adalah, apa dari semua ini yang benar-benar perlu ditulis ulang sekarang, dan apa yang tidak.
Ada berbagai pendekatan untuk masalah ini. Uncss segera muncul di benak saya . Alat ini secara otomatis mendeteksi gaya mana yang digunakan pada halaman dan menghapus yang tidak perlu. Namun dalam praktiknya, ini hampir selalu mengarah pada fakta bahwa tidak ada yang tahu apa yang sebenarnya digunakan dan apa yang tidak. Saya juga ragu sepanjang waktu apakah alat ini telah menghapus sesuatu yang berlebihan. Tapi ini mungkin paranoia saya. Meskipun ...
Bye-bye adalah alat yang lebih sederhana yang kami sendiri masukkan daftar pemilih untuk dihapus dari CSS. Dan Anda dapat menggunakan ekspresi reguler. Jika Anda menggunakan BEM atau hal lain seperti itu, maka dengan satu reguler sederhana Anda dapat menghapus blok dengan segala sesuatu yang berkaitan dengannya. Sampai jumpa!
Pendekatan ini ternyata cukup nyaman. Segera dihapus gaya mana yang belum digunakan atau telah dihapus karena tidak perlu, sementara semua sumber ada di tempat, semua pengaturan dalam satu file, tidak ada yang hilang, itu tidak menyebabkan kesulitan untuk membuat beberapa rakitan yang berbeda, dan yang terpenting, solusinya sederhana dan dapat diprediksi.
No. 10. Postcss-trolling
https://github.com/juanfran/postcss-trolling
Semua alat sebelumnya dapat sedikit meningkatkan produktivitas desainer tata letak Anda, tetapi yang ini memberikan hasil yang sangat fenomenal. Saya sangat merekomendasikannya.
Kesimpulan
PostCSS adalah bantuan yang baik untuk perancang tata letak. Jika mereka tidak disalahgunakan, tentu saja. Untuk banyak masalah yang memakan waktu, ada solusi siap pakai dalam bentuk plug-in, dan meskipun mereka sering tidak berkembang dan tampaknya ditinggalkan, ini tidak mengganggu penggunaannya.