Sass Tips dan Alat Praktik Terbaik Untuk Pengembang

Sama seperti bagaimana jQuery merevolusi JavaScript vanilla, Sass telah merevolusi CSS vanilla. Kebanyakan pengembang yang mempelajari Sass setuju bahwa mereka tidak akan pernah mau kembali. Banyak juga yang setuju bahwa masalah terbesar dengan pengembang baru adalah cara mereka menggunakan Sass, bukan Sass itu sendiri.

Saya telah menjelajahi web dan menyusun artikel ini praktik terbaik untuk menulis kode Sass yang dapat diperluas dan dapat digunakan kembali. Saran berasal dari pendapat saya sendiri dan dari situs web tepercaya seperti Sass Guidelines.

Anda tentu tidak perlu menerapkan semua fitur ini ke dalam alur kerja Anda. Tapi ada baiknya untuk setidaknya menghibur ide-ide ini dan merenungkan manfaat potensial.

Organisasi File

Tempat terbaik untuk memulai dengan pengembangan Sass adalah organisasi file. Jika Anda sudah menjadi kode modular maka Anda harus memahami nilai impor dan parsial (lebih lanjut tentang ini nanti).

Tetapi untuk sekarang lihat contoh struktur file ini dari DoCSSa. Saya telah membuat ulang struktur file ini yang dapat Anda lihat di bawah:

Ini hanya saran dan itu salah satu dari banyak cara Anda dapat mengatur file Anda. Anda dapat menemukan metode lain yang menggunakan struktur folder berbeda seperti “global” untuk SCSS di seluruh situs dan “halaman” untuk SCSS khusus halaman.

Mari kita telusuri gaya organisasi yang disarankan ini untuk memeriksa tujuan setiap folder:

• / global - berisi file Sass yang diterapkan di seluruh situs seperti tipografi, warna, dan kisi
• / komponen - berisi file Sass dengan gaya komponen seperti tombol, tabel, atau bidang input
• / bagian - berisi file Sass yang didedikasikan untuk halaman atau area tertentu pada suatu halaman (mungkin berfungsi lebih baik jika digabungkan ke dalam / komponen / folder)
• / utils - berisi utilitas pihak ketiga seperti Normalisasi yang dapat diperbarui secara dinamis dengan alat-alat seperti Bower.
• main.scss - file Sass utama dalam folder root yang mengimpor semua yang lain.

Ini hanyalah titik awal dasar dan ada banyak ruang untuk berkembang dengan ide-ide Anda sendiri.

Tetapi tidak peduli bagaimana Anda memilih untuk mengatur SCSS Anda, sangat penting bagi Anda memiliki beberapa organisasi dengan file (atau folder) terpisah untuk pustaka seperti Normalisasi yang perlu diperbarui, plus komponen dalam parsial Sass untuk proyek Anda.

Parsial Sass sangat penting untuk praktik terbaik modern. Ini sangat direkomendasikan oleh tim desain Zurb dan oleh banyak pengembang frontend profesional lainnya.

Berikut ini kutipan dari situs web Sass yang menjelaskan sebagian:

“Anda bisa membuat sebagian file Sass yang berisi potongan kecil CSS yang bisa Anda sertakan dalam file Sass lainnya. Ini cara yang bagus untuk melakukannya memodulasi CSS Anda dan membantu menjaga hal-hal lebih mudah untuk dipertahankan. Parsial hanyalah sebuah file Sass yang diberi nama dengan garis bawah utama. Anda mungkin menamakannya sesuatu seperti _partial.scss. Garis bawah ini memberi tahu Sass bahwa file tersebut hanya sebagian file dan tidak boleh dihasilkan menjadi file CSS. Parsial Sass digunakan dengan @impor direktif.”

Lihat juga postingan lain mengenai struktur file Sass:

• Bagaimana Saya Menyusun Proyek Sass Saya
• Aesthetic Sass: Arsitektur dan Organisasi Gaya
• Struktur Direktori Yang Membantu Anda Memelihara Kode Anda

Strategi Impor

Tidak cukup bisa dikatakan tentang nilai impor dan parsial Sass. Organisasi kode adalah kunci untuk mendapatkan struktur impor dan alur kerja yang hanya berfungsi.

Tempat terbaik untuk memulai adalah dengan lembar global yang berisi impor, variabel, dan campuran bersama. Banyak pengembang lebih suka memisahkan variabel dan mixin tetapi ini turun ke semantik.

Ingatlah bahwa mixin adalah cara mengimpor, atau lebih tepatnya menggandakan, kode Sass. Mereka sangat kuat tetapi tidak boleh digunakan dengan “statis” kode. Perlu diingat ada perbedaan antara mixin, extends, dan placeholder, yang semuanya digunakan dalam pengembangan Sass.

Mixin paling baik digunakan dengan nilai dinamis yang diteruskan ke mixin untuk perubahan kode. Misalnya, lihat Sass mixin ini yang menciptakan gradien latar belakang antara dua warna.

@mixin linearGradient ($ top, $ bottom) background: $ top; / * Browser lama * / latar belakang: -moz-linear-gradient (atas, $ atas 0%, $ bawah 100%); / * FF3.6 + * / latar belakang: -webkit-gradient (linear, kiri atas, kiri bawah, color-stop (0%, $ top), color-stop (100%, $ bottom)); / * Chrome, Safari4 + * / background: -webkit-linear-gradient (atas, $ atas 0%, $ bawah 100%); / * Chrome10 +, Safari5.1 + * / background: -o-linear-gradient (atas, $ atas 0%, $ bawah 100%); / * Opera 11.10+ * / background: -ms-linear-gradient (atas, $ atas 0%, $ bawah 100%); / * IE10 + * / background: linear-gradient (ke bawah, $ atas 0%, $ bawah 100%); / * W3C * / filter: progid: DXImageTransform.Microsoft.gradient (startColorstr = "# ffffff", endColorstr = "# 000000", GradientType = 0); / * IE6-9 * /

Mixin mengambil dua nilai: warna atas dan warna bawah. Anda bisa menulis mixin berbeda untuk berbagai jenis gradien yang mencakup 3 atau 4+ warna berbeda. Ini memungkinkan Anda untuk mengimpor dan mengkloning kode mixin sambil mengubah parameter untuk opsi khusus.

Contoh dari Code Responsible terlihat seperti ini:

.tombol @sertakan linearGradient (#cccccc, # 666666); 

Terkait dengan mixin adalah placeholder Sass 'yang terutama berguna dengan arahan extended. Ini memang diakui lebih kompleks daripada mixin, tetapi ini bisa menjadi cara untuk melakukannya menggabungkan penyeleksi bersama tanpa menulis ulang kode berlebih.

Sementara Sass hanya memiliki satu metode @import, saya telah menyertakan mixin dan placeholder untuk menunjukkan fleksibilitas kode yang dapat ditulis dalam satu file tetapi disertakan di mana saja.

Saat membangun struktur impor, ingatlah untuk mengikuti konsep pengkodean KERING (Jangan Ulangi Diri Sendiri).

Konvensi Penamaan

Aturan umum untuk konvensi penamaan berlaku untuk variabel, fungsi, dan mixin. Saat memberi nama apa pun di Sass, disarankan untuk melakukannya gunakan semua huruf kecil dengan tanda hubung untuk pemisahan.

Sintaks kode sas sebenarnya berdasarkan pada pedoman aturan CSS. Berikut adalah beberapa praktik terbaik yang disarankan untuk diingat:

• dua (2) spasi indentasi, tanpa tab
• idealnya, garis lebar 80 karakter atau kurang
• penggunaan ruang kosong yang berarti
• gunakan komentar untuk menjelaskan operasi CSS

Ini bukan item yang diperlukan untuk kode Sass yang valid. Namun saran ini datang dari pengembang profesional yang telah menemukan aturan-aturan ini memberikan pengalaman pengkodean yang paling seragam.

Tetapi sehubungan dengan konvensi penamaan Anda mungkin berakhir dengan dua struktur yang berbeda: satu untuk nama Sass dan satu lagi untuk nama kelas CSS. Beberapa pengembang lebih suka BEM daripada saran Sass. Tidak ada yang lebih, atau kurang, benar; hanya berbeda dengan prosedur operasi yang berbeda.

Masalahnya adalah bahwa BEM tidak terbawa dengan baik ke variabel atau campuran Sass karena mereka tidak memiliki struktur blok / elemen / pengubah (BEM). Saya pribadi lebih suka menggunakan konvensi penamaan Sass tetapi Anda bisa mencoba apa saja dari camelCase ke sintaks internal Anda sendiri.

Saat mengatur variabel dan mixin Anda disarankan membaginya berdasarkan kategori, kemudian daftar dalam urutan abjad. Ini membuat pengeditan menjadi jauh lebih mudah karena Anda tahu persis di mana menemukan sesuatu.

Misalnya, untuk mengubah warna tautan Anda akan membuka file variabel Anda (mungkin _variables.scss) dan cari bagian untuk variabel warna. Kemudian cari tautan berdasarkan nama (tautan tajuk, tautan teks, dll) dan perbarui warnanya. Sederhana!

Untuk mendapatkan gambaran tentang bagaimana Anda dapat menyusun daftar isi untuk file Sass Anda, periksa file pengaturan Foundation.

 // Yayasan untuk Pengaturan Situs // ----------------------------- // // Daftar Isi: // // 1 Global // 2. Breakpoints // 3. Kotak // 4. Tipografi Dasar // 5. Tipografi Pembantu… // 1. Global // --------- $ global-font-size: 100 %; $ global-width: rem-calc (1200); $ global-lineheight: 1,5; // dll

Praktek penamaan lain berkaitan dengan breakpoints responsif. Saat memberi nama breakpoints Sass, cobalah untuk menghindari nama spesifik perangkat. Lebih baik menulis nama seperti kecil, med, lg, dan xlg karena mereka relatif satu sama lain.

Ini lebih baik untuk hubungan internal antara breakpoint, tetapi juga bagus untuk tim di mana pengembang mungkin tidak tahu perangkat mana yang berhubungan satu sama lain.

Untuk benar-benar menuliskan nama, Anda disarankan sespesifik mungkin tanpa variabel ekstra panjang. Kamu harus mengadopsi konvensi penamaan di seluruh situs yang mudah diingat saat coding.

Berikan konvensi penamaan khusus untuk segala sesuatu seperti warna, margin, tumpukan font dan ketinggian garis. Tidak hanya nama-nama dapat dengan cepat dipanggil kembali, tetapi juga membuat pekerjaan Anda lebih mudah saat menulis nama variabel baru yang harus cocok dengan sintaks yang ada.

Tapi ada garis tipis antara spesifisitas dan konvolusi. Berlatih akan membantu Anda menemukan baris itu, dan menulis nama yang lebih mudah diingat akan memudahkan Anda menyalin kode ke proyek lain.

Nesting Dan Looping

Kedua teknik sas ini sangat berbeda dalam tindakan, namun keduanya memiliki kemampuan untuk disalahgunakan jika tidak digunakan dengan baik.

Bersarang adalah proses dari menambahkan penyeleksi yang disatukan bersama melalui lekukan untuk membuat lebih spesifik dengan lebih sedikit kode. Sass memiliki panduan bersarang yang mengilustrasikan contoh-contoh tindakan kode bersarang. Tetapi mudah terbawa dengan sarang. Jika Anda terlalu bersemangat, Anda bisa berakhir dengan kode yang terlihat seperti ini:

body div.content div.container ... body div.content div.container div.articles ... body div.content div.container div.articles> div.post ... 

Jauh terlalu spesifik dan hampir mustahil untuk ditimpa, jenis kode ini mengalahkan tujuan cascading stylesheet.

Melacak panduan SitePoint ini Anda akan menemukan tiga aturan emas untuk bersarang:

• Tidak pernah pergi lebih dari 3 level.
• Pastikan hasil CSS bersih dan dapat digunakan kembali.
• Gunakan bersarang saat masuk akal, bukan sebagai opsi default.

Pengembang Josh Broton menyarankan untuk bersarang saat diperlukan, indentasi sisanya sebagai aturan sintaksis umum.

Indentasi pemilih Anda tidak akan menyebabkan efek CSS mengalir. Tetapi Anda akan memiliki waktu yang lebih mudah membaca sekilas file Sass Anda dengan menentukan kelas mana yang berhubungan satu sama lain.

Loop juga bisa terlalu sering digunakan jika tidak diterapkan dengan benar. Tiga loop Sass adalah @untuk, @sementara, dan @setiap. Saya tidak akan menjelaskan secara terperinci tentang bagaimana mereka semua bekerja tetapi jika Anda tertarik, lihat posting ini.

Sebaliknya saya ingin menutup tujuan untuk menggunakan loop dan bagaimana mereka berfungsi di Sass. Ini harus digunakan untuk menghemat waktu menulis kode yang dapat diotomatisasi. Sebagai contoh, berikut ini cuplikan kode dari posting Clubmate yang memperlihatkan beberapa kode Sass diikuti dengan output:

/ * Kode Sass * / @untuk $ i dari 1 hingga 8 $ width: persentase (1 / $ i) .col - # $ i width: $ width;  / * output * / .col-1 width: 100%; .col-2 width: 50%; .col-3 width: 33.333%; .col-4 width: 25%;  .col-5 width: 20%; .col-6 width: 16.666%; .col-7 width: 14.285%; .col-8 width: 12.5%;

Kelas kolom ini dapat digunakan bersama dengan sistem grid. Anda bahkan dapat menambahkan lebih banyak kolom atau menghapus beberapa hanya dengan mengedit kode loop.

Loop harus tidak digunakan untuk menggandakan pemilih atau properti untuk pemilih; itulah gunanya mixin.

Juga ketika mengulang ada sesuatu yang disebut peta Sass yang menyimpan kunci: nilai pasangan data. Pengguna mahir harus memanfaatkan ini jika memungkinkan.

Tetapi loop reguler Sass sederhana dan efektif dalam memberikan output kode tanpa pengulangan. Alasan terbaik untuk menggunakan loop adalah dengan Properti CSS yang memvariasikan data output.

Berikut cara yang baik untuk memeriksa apakah loop Anda membantu: tanyakan pada diri Anda sendiri jika ada cara lain untuk menghasilkan CSS yang Anda butuhkan dengan lebih sedikit baris kode. Jika tidak maka sintaks loop mungkin merupakan ide bagus.

Jika Anda pernah bingung atau ingin umpan balik tentang nesting atau loop Sass Anda harus memposting pertanyaan di / r / sass / atau / r / css /, komunitas Reddit aktif dengan pengembang Sass yang sangat berpengetahuan luas.

Modularisasi

Praktek menulis modular Sass adalah kebutuhan mutlak untuk sebagian besar proyek (saya berpendapat, setiap proyek). Modularisasi adalah proses memecah proyek menjadi modul yang lebih kecil. Ini bisa dilakukan di Sass menggunakan sebagian.

Gagasan di balik modular Sass adalah untuk menulis file SCSS individual dengan tujuan spesifik yang menargetkan konten global (tipografi, kisi) atau elemen halaman (tab, formulir).

Definisi modul Sass cukup jelas dan memberikan saran yang sangat spesifik: mengimpor modul tidak boleh menghasilkan kode.

Gagasan output wajib untuk semua modul akan menjadi mimpi buruk untuk optimasi. Sebaliknya Anda harus membuat modul secara individual dan panggil saja yang Anda butuhkan. Modul dapat didefinisikan oleh mixin atau fungsi, tetapi dimungkinkan untuk membuat modul yang mengandung penyeleksi juga.

Namun artikel Sass Way menyarankan untuk menulis semua penyeleksi sebagai mixin dan hanya memanggil mereka sesuai kebutuhan. Apakah Anda mengadopsi ini atau tidak pada akhirnya adalah pilihan Anda. Saya pikir itu tergantung pada ukuran proyek dan kenyamanan Anda dengan menangani mixin.

Mengutip John Long dari jabatannya di The Sass Way:

“Bagi saya, modul telah menjadi unit dasar atau blok bangunan proyek Sass saya.”

Jika Anda benar-benar mencari rutinitas Sass, saya sarankan untuk sepenuhnya modular. Cobalah membangun hampir semuanya sebagai parsial modular yang dimasukkan ke dalam file CSS primer. Pada awalnya alur kerja ini bisa tampak menakutkan tetapi masuk akal pada skala yang lebih besar - terutama dengan proyek-proyek besar.

Plus, jauh lebih mudah untuk menyalin modul dari satu proyek ke proyek lain ketika mereka berada di file yang terpisah. Fleksibilitas dan kode yang dapat digunakan kembali adalah landasan pengembangan modular.

Untuk mempelajari lebih lanjut tentang modul Sass dan teknik modularisasi lihat posting ini:

• Modul CSS: Selamat Datang di Masa Depan
• Pro dan Kontra dari Modular Sass
• Organisasi CSS modular dengan SMACSS & SASS

Temukan Alur Kerja Sempurna Anda

Setiap tim dan pengembang individu memiliki praktiknya sendiri yang berfungsi paling baik. Anda harus mengadopsi praktik yang paling cocok untuk Anda secara pribadi, atau memilih untuk mengadopsi praktik yang paling cocok untuk tim Anda secara profesional.

Juga pertimbangkan untuk menggunakan Gulp atau Grunt untuk otomatisasi proyek dan meminimalkan kode Anda. Ini akan menghemat banyak tenaga kerja manual dan alat otomatisasi sekarang tidak diragukan lagi merupakan bagian dari praktik terbaik untuk pengembangan frontend modern.

Telusuri perpustakaan open source seperti SCSS Foundation di GitHub untuk mempelajari lebih lanjut tentang praktik terbaik yang dilakukan oleh perpustakaan lain.

Hal terbaik dari praktik terbaik adalah mereka benar-benar meningkatkan pekerjaan Anda sebagian besar waktu, tetapi ada banyak alternatif. Coba saja dan lihat bagaimana rasanya. Anda akan selalu belajar sehingga praktik terbaik Anda dapat berubah dengan cepat selama 5 tahun.

Satu saran terakhir yang saya miliki untuk seluruh proses Sass adalah untuk membuat keputusan dengan jelas dalam pikiran. Tulis kode yang membuat pekerjaan Anda lebih mudah. Jangan terlalu menyulitkan proyek jika ada cara yang lebih sederhana untuk melakukannya.

Sass dimaksudkan untuk meningkatkan pengalaman pengembangan CSS, jadi bekerja dengan kejelasan dan praktik terbaik untuk mendapatkan pengalaman terbaik.

Bungkus

Kemacetan dalam alur kerja Sass dapat diperbaiki dengan mengubah gaya kode dan mengikuti praktik terbaik. Saya telah menguraikan beberapa saran dalam posting ini yang diberikan dari blog Sass dan pengembang profesional.

Cara terbaik untuk mempelajari lebih lanjut adalah menerapkan praktik ini ke dalam alur kerja Anda dan lihat apa yang berhasil. Seiring waktu Anda akan menemukan bahwa beberapa kegiatan lebih bermanfaat daripada yang lain, dalam hal ini Anda harus simpan apa saja yang berhasil dan jatuhkan yang tidak.

Periksa tautan ini untuk menemukan lebih banyak tips dan praktik terbaik untuk pengembangan Sass:

• Pedoman Sass
• Visi untuk Sass Kami
• 8 Tips untuk Membantu Anda Mendapatkan yang Terbaik dari Sass
• Memperluas In Sass Tanpa Membuat Mess
• Praktik Terbaik Sass - Sarang sedalam lebih dari 3 level