Memulai Dengan Pipeline Aset, Bagian 1

() translation by (you can also view the original English article)

Dalam artikel pertama dari seri baru ini di Saluran Saluran Aset di Rails, saya ingin membahas beberapa konsep tingkat tinggi yang berguna untuk sepenuhnya memahami apa yang ditawarkan oleh Pipeline Aset dan apa yang dilakukannya di bawah kap mesin. Hal-hal utama yang dikelolanya untuk Anda adalah rangkuman, minifikasi, dan preprocessing aset. Sebagai seorang pemula, Anda perlu membiasakan diri dengan konsep-konsep ini sedini mungkin.

Topik

Pipeline Aset?
Organisasi
Penggabungan & Kompresi?
Bahasa Tingkat Tinggi

Pipeline Aset?

Pipeline Aset tidak persis berita untuk orang-orang dalam bisnis, tetapi untuk pemula itu bisa sedikit sulit untuk mencari tahu dengan cepat. Pengembang tidak benar-benar menghabiskan banyak waktu untuk hal-hal front-end, terutama ketika mereka mulai. Mereka sibuk dengan banyak bagian yang bergerak yang tidak ada hubungannya dengan HTML, CSS, atau bit JS yang sering rusak.

Saluran Pipa Aset dapat membantu dengan mengelola penggabungan, pelemahan, dan pra-pemrosesan aset—misalnya, aset yang ditulis dalam bahasa tingkat tinggi seperti CoffeeScript atau Sass.

Ini adalah langkah penting dalam proses pembangunan untuk aplikasi Rails. Pipeline Aset dapat memberi Anda dorongan tidak hanya dalam kualitas dan kecepatan tetapi juga kenyamanan. Setelah menyiapkan alat build yang Anda sesuaikan sendiri mungkin memberi Anda beberapa opsi lagi untuk menyelaraskan kebutuhan Anda, tetapi itu dilengkapi dengan overhead yang mungkin memakan waktu untuk pemula—bahkan mungkin mengintimidasi. Dalam hal ini, kita dapat berbicara tentang Pipeline Aset sebagai solusi yang menumbuhkan kenyamanan atas konfigurasi.

Hal lain yang seharusnya tidak diremehkan adalah organisasi. Pipa menawarkan kerangka kerja yang solid untuk menempatkan aset Anda. Pada proyek-proyek yang lebih kecil, hal ini mungkin tidak tampak penting, tetapi proyek yang lebih besar mungkin tidak akan pulih dengan mudah dari arah yang salah pada subjek seperti ini. Ini mungkin bukan contoh paling umum di dunia, tetapi bayangkan saja proyek seperti Facebook atau Twitter memiliki organisasi yang buruk untuk aset CSS dan JS mereka. Tidak sulit membayangkan bahwa ini akan memunculkan masalah dan orang-orang yang harus bekerja dan membangun dasar semacam itu tidak akan memiliki waktu yang mudah untuk mencintai pekerjaan mereka.

Seperti banyak hal di Rails, ada pendekatan konvensional tentang bagaimana menangani aset. Hal ini memudahkan untuk membuat onboard orang baru dan untuk menghindari pengembang dan desainer terlalu terobsesi untuk membawa adonan mereka sendiri ke pesta.

Ketika Anda bergabung dengan tim baru, Anda ingin dapat mencapai kecepatan dengan cepat dan menyentuh tanah. Perlu mencari tahu saus khusus tentang bagaimana orang lain mengatur aset mereka tidak benar-benar membantu dengan itu. Dalam kasus ekstrim, ini bahkan dapat dianggap sebagai pemborosan dan dapat membakar uang secara tidak perlu. Tapi jangan terlalu dramatis di sini.

Jadi artikel ini adalah untuk para pemula di antara Anda, dan saya sarankan untuk segera melihat salurannya dan mendapatkan pegangan yang baik tentang topik ini, bahkan jika Anda tidak berharap untuk bekerja di markup atau hal-hal front-end banyak di masa depan . Ini adalah aspek penting dalam Rails dan bukan masalah besar. Ditambah anggota tim Anda, terutama perancang yang menghabiskan separuh hidup mereka di direktori ini, akan memasukkan hal-hal yang kurang lucu dalam kopi Anda jika Anda memiliki beberapa kesamaan yang tidak bertentangan satu sama lain.

Organisasi

Anda memiliki tiga opsi untuk menempatkan aset Anda. Pembagian ini lebih bersifat logis. Mereka tidak mewakili batasan atau batasan teknis apa pun. Anda dapat menempatkan aset di salah satu dari mereka dan melihat hasil yang sama. Tetapi untuk organisasi yang lebih pintar, Anda harus memiliki alasan yang kuat untuk menempatkan konten di tempat yang tepat.

app/assets

app/assets/
├── images
├── javascripts
│   └── application.js
└── stylesheets
    └── application.css

Folder app/assets untuk aset yang khusus untuk aplikasi ini—file gambar, JS, dan CSS yang dibuat khusus untuk proyek tertentu.

lib/assets

1	lib/assets/

Folder lib/assets, di sisi lain, adalah rumah untuk kode Anda sendiri yang dapat Anda gunakan kembali dari proyek ke proyek—hal-hal yang mungkin telah Anda tarik sendiri dan ingin Anda ambil dari satu proyek ke proyek berikutnya—khususnya, aset yang Anda dapat berbagi antar aplikasi.

vendor/assets

1	vendor/assets/
2	├── javascripts
3	└── stylesheets

vendor/assets adalah langkah luar yang lain. Ini adalah rumah untuk aset yang Anda gunakan kembali dari sumber eksternal lain—plugin dan kerangka kerja dari pihak ketiga.

Ini adalah tiga lokasi di mana Sprocket akan mencari aset. Di dalam direktori di atas, Anda diharapkan untuk menempatkan aset Anda dalam folder /images, /stylesheet dan /javascripts. Tetapi ini lebih merupakan hal konvensional; setiap aset dalam folder */assets akan dilalui. Anda juga dapat menambahkan subdirektori sesuai kebutuhan. Rel tidak akan mengeluh dan mengkompilasi file mereka.

Ada cara mudah untuk melihat jalur pencarian dari pipeline aset. Saat Anda menyalakan konsol Rails dengan rails console, Anda dapat memeriksanya dengan perintah berikut:

Terminal

1	Rails.application.config.assets.paths

Apa yang akan Anda dapatkan adalah array dengan semua direktori aset yang tersedia dan ditemukan oleh Sprocket—alias jalur pencarian.

=> ["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts"]

Hal yang menyenangkan tentang semua ini mudah untuk dilewatkan. Ini adalah aspek dari mengadakan konvensi. Itu berarti bahwa pengembang—dan perancang juga, sebenarnya—dapat memiliki harapan tertentu tentang di mana harus mencari file dan di mana menempatkannya. Itu bisa menjadi penghemat waktu (suara Trump) yang sangat besar. Ketika seseorang baru bergabung dengan sebuah proyek, mereka memiliki gagasan yang baik bagaimana cara menavigasi proyek segera.

Itu tidak hanya nyaman, tetapi juga dapat mencegah ide-ide yang dipertanyakan atau menciptakan kembali roda sepanjang waktu. Ya, konvensi konfigurasi dapat terdengar sedikit membosankan di kali, tetapi itu adalah hal yang kuat tetap. Itu membuat kami fokus pada hal yang penting: kerja itu sendiri dan kolaborasi tim yang baik.

Jalur aset yang disebutkan tidak diatur di batu. Anda dapat menambahkan jalur khusus juga. Buka config/application.rb dan tambahkan jalur khusus yang ingin Anda kenali dengan Rails. Mari kita lihat cara menambahkan custom_folder.

config.application.rb

module TestApp
  class Application < Rails::Application
    config.assets.paths << Rails.root.join("custom_folder")
  end
end

Ketika Anda sekarang memeriksa kembali jalur pencarian, Anda akan menemukan folder kustom Anda menjadi bagian dari jalur pencarian untuk jalur pipa aset. Ngomong-ngomong, sekarang akan menjadi objek terakhir yang ditempatkan dalam array:

Terminal

1	Rails.application.config.assets.paths

Output

["/Users/example-user/projects/test-app/app/assets/images", "/Users/example-user/projects/test-app/app/assets/javascripts", "/Users/example-user/projects/test-app/app/assets/stylesheets", "/Users/example-user/projects/test-app/vendor/assets/javascripts", "/Users/example-user/projects/test-app/vendor/assets/stylesheets", "/usr/local/lib/ruby/gems/2.3.0/gems/turbolinks-2.5.3/lib/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/jquery-rails-4.1.1/vendor/assets/javascripts", "/usr/local/lib/ruby/gems/2.3.0/gems/coffee-rails-4.1.1/lib/assets/javascripts", #<Pathname:/Users/example-user/projects/test-app/custom_folder>]

Penggabungan & Kompresi?

Mengapa kita membutuhkan barang itu? Singkat cerita, Anda ingin aplikasi memuat lebih cepat. Periode! Sesuatu yang membantu dengan itu Selamat datang. Tentu saja Anda dapat pergi tanpa mengoptimalkannya, tetapi itu memiliki terlalu banyak kelebihan yang tidak bisa diabaikan. Mengompresi ukuran file dan menggabungkan beberapa file aset ke dalam file “master” tunggal yang diunduh oleh klien seperti browser juga tidak banyak berfungsi. Hal ini sebagian besar ditangani oleh jaringan pipa.

Mengurangi jumlah permintaan untuk merender halaman sangat efektif dalam mempercepat pekerjaan. Alih-alih memiliki kemungkinan 10, 20, 50 atau berapa pun jumlah permintaan sebelum peramban selesai mendapatkan aset Anda, Anda berpotensi hanya memiliki satu untuk setiap aset CSS dan JS. Hari ini adalah hal yang menyenangkan untuk dimiliki, tetapi pada titik tertentu ini adalah pengubah permainan. Perbaikan semacam ini dalam pengembangan web tidak boleh diabaikan karena kita berurusan dengan milidetik sebagai satu unit.

Banyak permintaan bisa bertambah banyak. Dan setelah semua, pengalaman pengguna adalah yang paling penting untuk proyek yang sukses. Membuat pengguna menunggu sedikit tambahan itu sebelum mereka dapat melihat konten yang ditampilkan di halaman Anda dapat menjadi pemecah masalah besar. Kesabaran bukanlah sesuatu yang bisa kita harapkan dari pengguna kami.

Pembaruan itu keren karena menghilangkan hal-hal yang tidak perlu dalam file Anda—whitespace dan komentar, pada dasarnya. File-file kompresi ini tidak dibuat dengan keterbacaan manusia dalam pikiran. Mereka murni untuk konsumsi mesin. File-file tersebut akan terlihat agak samar dan sulit dibaca meskipun itu masih semua kode CSS dan JS yang valid—hanya tanpa spasi yang berlebihan untuk membuatnya mudah dibaca dan dimengerti oleh manusia.

Kompresi JS sedikit lebih terlibat. Peramban web tidak membutuhkan pemformatan itu. Itu memungkinkan kami mengoptimalkan aset ini. Masalah yang diambil dari bagian ini adalah bahwa jumlah permintaan yang berkurang dan ukuran file yang diperkecil mempercepat segalanya dan harus ada dalam kantong trik Anda. Rel memberi Anda fungsi ini di luar kotak tanpa pengaturan tambahan.

Bahasa Tingkat Tinggi

Anda mungkin sudah pernah mendengar tentang mereka, tetapi sebagai pemula Anda mungkin tidak akan cepat mengetahui mengapa Anda harus belajar bahasa lain—terutama jika Anda masih sibuk belajar menulis HTML dan CSS klasik. Bahasa-bahasa ini diciptakan untuk mengatasi kekurangan yang ingin dikuasai para pengembang. Mereka kebanyakan membahas masalah yang tidak ingin ditangani oleh pengembang setiap hari. Pembangunan yang digerakkan oleh kemalasan klasik, saya kira.

"Bahasa tingkat tinggi" terdengar lebih mewah daripada mungkin—mereka adalah rad. Kami berbicara tentang Sass, CoffeeScript, Haml, Slim, Jade, dan hal-hal seperti itu. Bahasa-bahasa ini memungkinkan kita menulis dengan sintaks yang ramah pengguna yang bisa lebih mudah dan efisien untuk digunakan. Semuanya harus dikompilasi selama proses pembuatan.

Saya menyebutkan ini karena ini dapat terjadi di belakang layar tanpa Anda sadari. Itu berarti mengambil aset ini dan mengubahnya menjadi CSS, HTML, dan JS sebelum dikerahkan dan dapat dirender oleh peramban.

Sass

Sass adalah singkatan dari "Syntactically Awesome Style Sheets" dan jauh lebih kuat daripada CSS murni. Ini memungkinkan kami menulis stylesheet yang lebih cerdas yang memiliki beberapa alat pemrograman yang dipanggang. Apa yang sedang kita bicarakan di sini, tepatnya? Anda dapat mendeklarasikan variabel, aturan sarang, fungsi tulis, membuat mixin, mengimpor parsial dengan mudah, dan banyak hal lain yang diinginkan programmer saat bermain dengan gaya.

Ini telah berkembang menjadi alat yang sangat kaya sekarang dan sangat bagus untuk mengatur stylesheet—untuk proyek besar saya bahkan akan menyebutnya penting. Akhir-akhir ini, saya tidak yakin apakah saya tidak akan tinggal jauh dari aplikasi besar yang tidak menggunakan alat seperti Sass—atau kerangka kerja sentris non-Ruby apa pun yang ditawarkan dalam hal itu.

Untuk masalah Anda saat ini, ada dua versi sintaks Sass yang perlu Anda ketahui. Versi Sassy CSS, alias SCSS, adalah yang lebih banyak digunakan. Ini tetap lebih dekat ke CSS biasa tetapi menawarkan semua pengembang ekstensi mewah dan desainer datang untuk mencintai bermain dengan stylesheet. Ini menggunakan ekstensi file .scss dan terlihat seperti ini:

SCSS

#main p {
  color: #00ff00;
  width: 97%;
  .redbox {
    background-color: #ff0000;
    color: #000000;
  }
}

Secara visual, itu tidak berbeda dari CSS—itulah mengapa itu adalah pilihan yang lebih populer, terutama di kalangan desainer yang saya pikir. Salah satu aspek SCSS yang benar-benar keren dan berguna, dan Sass secara umum, adalah aspek bersarang. Ini adalah strategi yang efektif untuk menciptakan gaya yang mudah dibaca tetapi juga mengurangi banyak pada deklarasi berulang.

SCSS

#main {
  color: blue;
  font-size: 0.3em;
  a {
    font: {
      weight: bold;
      family: serif;
    }
    &:hover {
      background-color: #eee;
    }
  }
}

Bandingkan contoh di atas dengan masing-masing versi CSS. Terlihat bagus untuk menurunkan gaya ini dengan bersarang, bukan?

CSS

#main {
  color: blue;
  font-size: 0.3em;
}

#main a {
  font-weight: bold;
  font-family: serif;
}

#main a:hover {
  background-color: #eee;
}

Sintaks Sass yang menjorok memiliki ekstensi file .sass. Yang satu ini memungkinkan Anda menghindari berurusan dengan semua kurung kurawal konyol dan titik koma yang ingin dihindari oleh setan malas.

Bagaimana cara melakukannya? Tanpa tanda kurung, Sass menggunakan indentasi, spasi pada dasarnya, untuk memisahkan sifat-sifatnya. Itu cukup rad dan terlihat sangat keren juga. Untuk melihat perbedaannya, saya akan menunjukkan Anda kedua versi secara berdampingan.

.sass

#main
  color: blue
  font-size: 0.3em
  a
    font:
      weight: bold
      family: serif
    &:hover
      background-color: #eee

.scss

#main {
  color: blue;
  font-size: 0.3em;
  a {
    font: {
      weight: bold;
      family: serif;
    }
    &:hover {
      background-color: #eee;
    }
  }
}

Cukup bagus dan kompak, ya? Tetapi kedua versi perlu diproses sebelum berubah menjadi CSS yang valid yang dapat dipahami oleh browser. The Asset Pipeline yang mengurusnya untuk Anda. Jika Anda memukul browser dengan sesuatu seperti Sass, mereka tidak akan tahu apa yang sedang terjadi.

Saya pribadi lebih memilih sintaks indentasi. Sintaksis Whitespace sensitif ini kurang populer daripada sintaks SCSS, yang mungkin tidak menjadikannya pilihan ideal untuk proyek-proyek selain yang pribadi Anda. Mungkin sebaiknya Anda memilih pilihan paling populer di antara tim Anda, terutama dengan desainer yang terlibat. Menegakkan whitespace hipness dengan orang-orang yang telah menghabiskan bertahun-tahun menjinakkan semua kurung kurawal dan titik koma di luar sana tampaknya seperti ide yang buruk.

Kedua versi memiliki trik pemrograman yang sama di lengan baju mereka. Mereka sangat baik dalam membuat proses penulisan gaya jauh lebih menyenangkan dan efektif. Untung bagi kami bahwa Rails and the Asset Pipeline membuatnya mudah bekerja dengan salah satu dari ini—cukup banyak di luar kotak.

Slim & Haml

Argumen serupa dapat dibuat tentang manfaat menggunakan sesuatu seperti Slim dan Haml. Mereka sangat berguna untuk membuat markup yang lebih kompak. Ini akan dikompilasi menjadi HTML yang valid, tetapi file yang Anda tangani jauh lebih berkurang.

Anda dapat menghindarkan diri dari kesulitan menulis tag penutup dan menggunakan singkatan keren untuk nama-nama tag dan semacamnya. Semburan singkat markup ini lebih mudah untuk skim dan membaca. Secara pribadi, saya tidak pernah menjadi penggemar berat Haml, tetapi Slim tidak hanya mewah dan nyaman, tetapi juga sangat cerdas. Bagi orang-orang yang menyukai sintaks Sass indentasi, saya pasti akan merekomendasikan bermain dengan itu. Mari kita lihat sekilas:

Slim

#content
  .left.column
    h2 Welcome to our site!
    p= print_information
  .right.column
    = render :partial => "sidebar"

Haml

#content
  .left.column
    %h2 Welcome to our site!
    %p= print_information
  .right.column
    = render :partial => "sidebar"

Keduanya menghasilkan ERB-enhanced HTML in Rails berikut:

<div id="content">
  <div class="left column">
    <h2>Welcome to our site!</h2>
    <p>
      <%= print_information %>
    </p>
  </div>
  <div class="right column">
    <%= render :partial => "sidebar" %>
  </div>
</div>

Di permukaan, perbedaannya tidak terlalu besar, tetapi saya tidak pernah mengerti mengapa Haml ingin saya menulis semua % ekstra ini untuk menambahkan tag. Slim menemukan solusi yang menyingkirkan ini, dan oleh karena itu saya salut tim! Bukan rasa sakit yang besar, tapi yang menjengkelkan. Perbedaan lainnya berada di bawah kap mesin dan tidak berada dalam lingkup bagian ini hari ini. Hanya ingin membangkitkan selera Anda.

Seperti yang Anda lihat, kedua preprocessors secara signifikan mengurangi jumlah yang perlu Anda tulis. Ya, Anda perlu belajar bahasa lain, dan itu sedikit aneh pada mulanya. Pada saat yang sama, saya merasa bahwa pemecatan banyak kekacauan itu sangat berharga. Juga, setelah Anda tahu cara menulis ERB-flavored HTML, Anda akan dapat mengambil salah satu dari preprosesor ini dengan cepat. Tidak ada ilmu roket—hal yang sama berlaku untuk Sass, omong-omong.

Jika Anda tertarik, ada dua permata berguna untuk menggunakan salah satu dari mereka di Rails. Bantulah diri Anda dan periksa mereka ketika Anda bosan menulis semua pembuka dan penutup yang membosankan ini.

1	gem "slim-rails"
2
3	gem "haml-rails"

CoffeeScript

CoffeeScript adalah bahasa pemrograman seperti yang lain, tetapi memiliki rasa Ruby untuk menulis JavaScript Anda. Melalui preprocessing, ini dikompilasi menjadi JavaScript lama polos yang dapat ditangani oleh browser. Argumen singkat untuk bekerja dengan CoffeeScript adalah membantu mengatasi beberapa kekurangan yang JS bawa-bawa. Dokumentasi mengatakan bahwa itu bertujuan untuk mengekspos "bagian-bagian yang baik dari JavaScript dengan cara yang sederhana". Cukup adil! Mari kita lihat sekilas contoh singkat dan melihat apa yang kita hadapi:

JavaScript

$( document ).ready(function(){
  var $on = 'section';
  $($on).css({
    'background':'none',
    'border':'none',
    'box-shadow':'none'
  });
}); 

Di CoffeeScript, orang ini akan terlihat seperti ini:

CoffeeScript

$(document).ready ->
  $on = 'section'
  $($on).css
    'background': 'none'
    'border': 'none'
    'box-shadow': 'none'
  return

Hanya sedikit lebih baik tanpa semua curlies dan titik koma, bukan? CoffeeScript mencoba untuk menjaga beberapa bit yang menjengkelkan di JavaScript, memungkinkan Anda mengetik lebih sedikit, membuat kode sedikit lebih mudah dibaca, menawarkan sintaks yang lebih ramah, dan berhubungan lebih menyenangkan dengan kelas menulis. Mendefinisikan kelas merupakan nilai tambah yang besar untuk sementara waktu, terutama bagi orang-orang yang datang dari Ruby yang tidak terlalu suka berurusan dengan JavaScript murni. CoffeeScript menggunakan pendekatan serupa untuk Ruby dan memberi Anda sepotong gula sintaksis yang bagus. Kelas terlihat seperti ini, misalnya:

Class

class Agent
  constructor: (@firstName, @lastName) ->

  name: ->
    "#{@first_name} #{@last_name}"

  introduction: (name) ->
    "My name is #{@last_name},  #{name}"

Bahasa ini cukup populer di tanah Ruby untuk sementara waktu. Saya tidak yakin bagaimana tingkat adopsi saat ini, tetapi CoffeeScript adalah rasa default JS di Rails. Dengan ES6, JavaScript sekarang juga mendukung kelas—satu alasan besar untuk tidak menggunakan CoffeeScript dan bermain dengan JS biasa. Saya pikir CoffeeScript masih membaca lebih baik, tetapi banyak alasan kurang kosmetik untuk menggunakannya telah diatasi dengan ES6 hari ini. Saya pikir ini masih alasan yang baik untuk mencobanya, tapi itu bukan apa yang Anda datang di sini. Saya hanya ingin memberi Anda hidangan pembuka lain dan memberikan sedikit konteks tentang mengapa Saluran Pipa Aset memungkinkan Anda bekerja di CoffeeScript di luar kotak.

Pikiran Akhir

Pipeline Aset telah terbukti jauh melampaui harapan saya ketika diperkenalkan. Pada saat itu benar-benar membuat cukup percikan dan mengatasi rasa sakit yang serius bagi pengembang. Hal ini tentu saja, tentu saja, dan telah memantapkan dirinya sebagai alat tanpa gesekan dan mudah yang meningkatkan kualitas aplikasi Anda.

Yang paling saya sukai adalah betapa sedikit kerumitan yang melibatkannya untuk berhasil. Jangan salah paham, alat seperti Gulp dan Grunt juga mengesankan. Pilihan untuk kustomisasi banyak. Saya tidak bisa menghilangkan perasaan nyaman yang diberikan Rails ketika saya tidak harus berurusan dengan penyiapan apa pun sebelum memulai. Konvensi bisa sangat kuat, terutama whey mereka menghasilkan sesuatu yang mulus dan bebas masalah.