Unlimited WordPress themes, graphics, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. OOP
Code

Dasar-Dasar AntiPatterns: Tampilan Rails

by
Length:MediumLanguages:

Indonesian (Bahasa Indonesia) translation by Ilham Saputra (you can also view the original English article)

Dalam seri ramah-pemula ini, kami melihat AntiPatterns, yang—seperti namanya—mewakili cukup banyak kebalikan dari pola desain. Mereka adalah penemuan solusi untuk masalah yang harus Anda hindari.

Dalam artikel ini kami akan fokus pada View AntiPattern utama—PHPitis—dan bekerja melalui beberapa teknik untuk menjaga pandangan Anda ramping dan jahat. Memiliki banyak kode Ruby dalam pandangan Anda tidak hanya buruk tetapi sering kali tidak perlu.

Topik

  • Rails Views
  • PHPitis
  • Extracting Helpers
  • Helpful Helpers
  • Forms
  • Partials
  • Conditional Content
  • Semantic Markup

Rails Views

Rails hadir dengan ERb (Embedded Ruby) di luar kotak, dan saya pikir tidak perlu untuk membuang di mesin rendering tampilan keren seperti Slim untuk contoh kami untuk saat ini. Jika Anda berpikir "convention over configuration" kebanyakan berlaku untuk model dan lapisan pengontrol, Anda kehilangan banyak barang yang membuat bekerja dengan Rails begitu cepat dan progresif. Merawat lapisan tampilan dengan baik tidak hanya mencakup cara Anda menyusun markup Anda, tetapi juga CSS/Sass, JavaScript, view helpers, dan templat layout Anda. Dilihat dari sudut itu, itu menjadi sedikit lebih dalam daripada yang mungkin Anda pikirkan pada awalnya. Banyaknya teknologi yang dapat terlibat dalam menciptakan pandangan Anda menunjukkan bahwa perawatan harus dilakukan untuk menjaga hal-hal tetap rapi, jelas dan fleksibel.

Karena cara kami menulis markup dan gaya jauh lebih sedikit dibatasi daripada pemodelan domain, Anda ingin ekstra hati-hati untuk menjaga hal-hal sesederhana mungkin. Perawatan harus menjadi prioritas utama Anda. Karena desain ulang atau iterasi desain bisa lebih sering daripada perubahan ekstensif pada lapisan model Anda, mempersiapkan perubahan mendapatkan makna yang sama sekali baru ketika datang ke lapisan yang menghadap pengguna Anda. Saran saya: jangan selalu membangun untuk masa depan, tetapi juga, dengan segala cara, jangan meremehkan tingkat perubahan—terutama jika Anda memiliki salah satu dari "orang-orang ide" yang tahu banyak tentang implementasi dalam tim. Apa yang saya sukai tentang pendekatan Rails terhadap pandangan dalam MVC adalah bahwa itu diperlakukan sama pentingnya, dan pelajaran yang diambil dari domain model dimasukkan ke dalam tampilan—jika memungkinkan dan bermanfaat. Kerangka kerja lain tampaknya setuju, karena mereka mengintegrasikan banyak ide ini dipelopori oleh Rails.

Karena artikel terakhir sedikit lebih luas, saya memilih topik ini sebagai selingan. Artikel-artikel berikut tentang pengontrol dan pengujian Rails lagi-lagi berukuran lebih besar. AntiPatterns untuk view tidak banyak, tetapi mereka tetap sama pentingnya. Kami akan fokus pada yang utama, PHPitis, dan bekerja melalui beberapa teknik untuk menjaga pandangan Anda ramping dan jahat. Karena tampilan adalah lapisan presentasi Anda, mungkin Anda harus sangat berhati-hati untuk tidak membuat kekacauan yang berbahaya. Ayo lakukan!

PHPitis

Mengapa kita memiliki MVC? Ya, karena pemisahan kekhawatiran sepertinya merupakan hal yang paling masuk akal untuk dilakukan. Tentu, implementasi gagasan ini sedikit berbeda di sana-sini, tetapi konsep keseluruhan dari tanggung jawab yang berbeda untuk setiap lapisan adalah motivasi inti untuk membangun aplikasi yang kuat. Memiliki banyak kode di lapisan tampilan Anda mungkin tidak asing bagi pengembang yang datang dari sisi PHP hal—meskipun saya mendengar kerangka kerja mereka sudah terjebak (sangat dipengaruhi oleh hal-hal seperti Rails?)—tetapi di Ruby-land hal ini sudah lama menjadi AntiPattern bersuara keras.

Masalah-masalah yang sudah jelas seperti mengesampingkan tanggung jawab dan duplikasi, itu hanya terasa jahat dan malas—agak bodoh juga, jujur ​​saja. Tentu, saya mengerti, ketika Anda mengembangkan banyak hal dalam kerangka kerja, bahasa atau ekosistem apa pun, mudah untuk terlibat atau mati rasa terhadap hal-hal seperti itu. Yang saya sukai dari orang-orang yang mendorong Ruby adalah bahwa hal-hal ini tampaknya memiliki bobot yang jauh lebih sedikit—yang mungkin menjadi alasan mengapa berinovasi sepertinya tidak pernah menjadi masalah dalam komunitas. Apa pun yang berhasil paling baik memenangkan argumen, dan kita dapat bergerak maju.

Jadi apakah ini seluruh bagian yang didedikasikan untuk bashing PHP? Tidak semuanya! Di masa lalu, aplikasi PHP memiliki reputasi memiliki pemisahan yang lemah antara model, tampilan dan pengontrol (mungkin ini adalah salah satu alasan utama mengapa orang merasa menulis aplikasi dengan Rails jauh lebih menarik). Memiliki file tunggal dengan kode untuk ketiga lapisan sepertinya tidak seksi. Jadi ketika kita memasukkan banyak Ruby atau kode domain ke dalam pandangan kita, itu mulai terlihat seperti gaya penataan PHP yang menakutkan—PHPitis. Hanya beberapa hal yang seburuk ini dalam hal mengembangkan aplikasi web, saya rasa. Ketika Anda peduli tentang pengembang yang bahagia dan kewarasan masa depan Anda sendiri, saya tidak bisa melihat mengapa ada orang yang menempuh jalan itu—tampaknya hanya ada rasa sakit di depan.

Rails menawarkan banyak barang untuk meminimalkan kode dalam tampilan sebanyak mungkin Anda harus mempelajari cara pembantu, tata letak, dan preprosesor untuk mencapai tampilan yang lebih bersih. Aturan praktis yang sederhana adalah menjaga logika domain dari pandangan Anda—tidak ada jalan pintas!

Harga yang harus dibayar karena malas dalam hal ini sulit ditaksir terlalu tinggi. Kode Ruby yang harus ada di lapisan presentasi harus sesederhana dan sesederhana mungkin, serta diatur secara cerdas. Hadiah Anda akan menjadi kode yang menyenangkan untuk diperluas dan dipertahankan, dan anggota tim baru juga akan lebih mudah membungkus kepala mereka di sekitar basis kode baru. Sebagai bonus, desainer aneh yang kode juga tidak akan marah dan menyembunyikan makanan busuk di salad Anda jika Anda menyimpan banyak kode Ruby dari markup mereka.

Helpful Helpers

Mengetahui berbagai metode pembantu di Rails akan secara signifikan meningkatkan kualitas lapisan presentasi Anda. Tidak hanya membersihkan dan menyuntikkan peningkatan kecepatan sesekali dalam produktivitas, tetapi lebih penting lagi membantu Anda melawan PHPitis.

Hal yang harus Anda hargai dari para pembantu ini adalah mereka mewakili ekstraksi dari kode yang biasanya dibutuhkan. Alih-alih menciptakan kembali roda, saat ragu, periksa apakah belum ada penolong yang menyelesaikan masalah Anda dalam tampilan—hal yang sama juga berlaku untuk Model dan Pengendali, tentu saja.

Ini daftar bantuan yang harus Anda perhatikan segera:

  • form_for
  • Pembantu lainnya untuk formulir.
  • fields_for
  • link_to
  • content_for
  • Dan menulis sendiri, tentu saja.

Forms

Mari kita lihat form_for terlebih dahulu. Saya tahu formulir agak membosankan dan tidak terlalu seksi untuk suatu topik, tetapi saya sangat menyarankan Anda untuk membacanya untuk membiasakan diri dengan rincian yang lebih baik. Penting untuk memahami cara kerjanya. Saya ingat sering hanya melirik mereka tanpa memberi mereka banyak perhatian. Tentu, Anda bisa membuatnya bekerja dengan sangat mudah tanpa memahami apa yang terjadi di bawah tenda. Di masa depan, saya mungkin meluangkan waktu untuk menulis artikel lengkap tentang mereka. Sementara itu, saya sangat menyarankan Anda menghabiskan sedikit waktu memeriksa dokumentasi-setidaknya Anda akan menghargai betapa nyaman Rails membuatnya untuk berurusan dengan barang formulir.

The Ugly

Contoh di bawah ini menunjukkan kepada Anda HTML bentuk kecil yang kami butuhkan untuk membuat agen. Ini hanya menerima tiga parameter sebagai input: name, number, dan licence_to_kill. Banyak kode untuk tugas kecil ini, sebenarnya. authenticity_token berasal dari Rails–ini adalah hal keamanan yang melindungi aplikasi dari "pemalsuan permintaan lintas situs".

some.html.erb

Menulis formulir dengan tangan tidak hanya panjang tetapi juga rawan kesalahan. Juga, jika kita mendekatinya dengan cara itu, kita juga harus menyelesaikan masalah dengan berbagai rute dan kelas CSS yang mungkin kita perlukan untuk membuat objek baru dan memperbarui yang sudah ada—pada dasarnya, kita perlu menduplikasi formulir buat dan edit rekaman. Seperti yang akan Anda lihat segera, Rails menemui Anda lebih dari setengahnya. Putusan: bagaimanapun Anda mengatakannya, pendekatan manualnya buruk dan kurang nyaman.

The Bad

Kita bisa menyusuri jalan berikut, yang tidak memanfaatkan konvensi dengan sempurna di Rails. Ke atas, jangan lakukan itu. Pada dasarnya ini menunjukkan bahwa Anda tidak menangani alat yang tersedia untuk keuntungan Anda dan Anda menduplikasi formulir untuk tindakan new dan edit.

some.html.erb

Apa yang terjadi di sini adalah pembangun formulir membawa model yang Anda butuhkan untuk formulir.

Di belakang layar, garis di atas akan diperluas menjadi yang berikut:

Metode form_for mengambil beberapa argumen:

  • simbol atau string untuk menentukan objek
  • url hash
  • html hash
  • namespace hash

Hash url adalah untuk menentukan opsi perutean. Itu berarti bahwa Anda dapat secara manual menentukan jalur perutean yang Anda kirimi formulir—rute yang dinamai berguna dengan ini. Gaya ini disebut "cara umum" karena Anda perlu mengkonfigurasi form_for panggilan secara manual.

Mengapa solusi ini tidak optimal? Karena kami ingin menjaga logika bisnis dari Tampilan dan Pengontrol kami sebanyak yang kami bisa. Efek sampingnya adalah kita perlu mengganti lebih sedikit komponen saat dibutuhkan.

HTML

Jika Anda melewatkannya, pendekatan ini tidak memberi kami id dan kelas untuk tag form secara otomatis. Yang untuk tag input, bagaimanapun, dibuat untuk Anda. Kami akan memperbaikinya dalam satu menit. Hanya tahu apa yang bisa Anda dapatkan secara gratis dan Anda mungkin harus menggunakan ini untuk keuntungan Anda. Jika Anda membutuhkan sesuatu yang berbeda atau namespace tambahan, Anda dapat menggunakan hash html atau hash namespace untuk menentukan sesuatu yang sedikit lebih.

some.html.erb
HTML

Tidak buruk! Sekarang tag form memiliki kelas dan id yang ditentukan—apa pun yang membuat aliran darah Anda—dan tag input diberi nama dengan mi6. Hampir sampai.

The Good

Yang ini disebut "gaya berorientasi sumber daya" dan memiliki jumlah Ruby paling sedikit yang perlu Anda tulis dalam pandangan Anda. Dengan pendekatan itu, kami ingin mengandalkan identifikasi sumber daya otomatis. Rails menggambarkan rute mana yang dibutuhkan berdasarkan objek itu sendiri. Tidak hanya itu, ia memberi Anda output HTML yang berbeda untuk membuat objek baru atau untuk mengedit yang sudah ada. Di belakang layar, Rails hanya menanyakan objek apakah sudah ada dan bertindak sesuai.

Membuat formulir dengan cara ini adalah penggunaan konvensi yang cerdas dan membantu menghindari duplikasi. Satu baris dan semua pengangkatan berat dilakukan untuk Anda.

some.html.erb

Jauh lebih baik, bukan? Sekarang kita mendapatkan apa yang kita butuhkan untuk objek yang ada dan yang baru. Selain itu, kami tidak perlu menambahkan teks ke tombol kirim kami. Rails merawatnya dan juga beradaptasi dengan objek baru atau yang sudah ada.

HTML untuk Objek Baru
HTML untuk Mengedit Objek

Saat mengedit objek, itu juga tercermin dalam output HTML dengan menambahkan id ke form id dan rute atau tindakan yang diperlukan untuk memperbarui objek tertentu.

Sepatah kata tentang sihir Rails. Ketika orang-orang berdebat dalam situasi ini bahwa Rails terlalu ajaib untuk selera mereka, saya sering berpikir bahwa ini bisa berarti bahwa mereka belum menghabiskan cukup waktu untuk mempelajari alat-alat perdagangan mereka. Setelah Anda meluangkan waktu untuk menguasai alat-alat ini, Anda akan sering mengerti mengapa penyederhanaan atau ekstraksi dilakukan, dan mereka juga tampak jauh lebih sadar dan terus terang.

Perhatian!

Contoh kode di atas menggunakan form_object sebagai parameter blok. Ini tidak disarankan praktik terbaik tetapi dilakukan untuk mengingatkan Anda apa yang diwakili objek ini dan apa yang dihasilkan dari form_for. Kebanyakan orang hanya menggunakan sebuah dataran |f| atau |form|, yang terlihat jauh lebih baik dan lebih ringkas.

By the way, hal-hal seperti label, text_field, check_box dan sejenisnya hanyalah metode pembantu yang dipanggil pada objek pembuat formulir. Ada banyak dari mereka yang mencakup hampir semua kebutuhan yang mungkin Anda temui.

some.html.erb

Ringkas dan enak dibaca, bukan?

Partials

Koleksi adalah hal lain yang kami tidak ingin terlalu bertele-tele. Memberikan parsial untuk setiap objek koleksi sangat singkat dan jelas—jika dilakukan dengan benar—sehingga saya merasa Anda memiliki sedikit alasan untuk tidak menggunakan konvensi Rails untuk mengurangi kode tampilan Ruby.

Mari kita membalikkan keadaan dengan yang ini dan mulai dengan contoh yang menunjukkan kepada Anda bagaimana Anda didorong untuk mendekati ini. Sepanjang jalan, saya akan menjelaskan apa yang dapat Anda tinggalkan juga.

The Good

app/views/agents/index.html.erb

Metode render cukup cerdas. Baris di atas adalah semua yang perlu Anda tulis untuk mengulangi koleksi. Jika Anda perlu mengubah sesuatu dalam tampilan ini, itu akan menjadi perubahan yang sangat kecil—dan karenanya menjadi penyebab kecil kesalahan.

Apa yang terjadi di sini adalah bahwa kerangka kerja dapat menentukan bagian mana yang dibutuhkannya. Melalui nama objek, ia tahu di mana harus mencari bagian—mengingat Anda mematuhi penamaan benda-benda konvensional. Cara saya melihatnya, ini adalah contoh yang bagus tentang bagaimana Rails tidak mencoba membuat Anda terkesan dengan sihir. Tim Rails bekerja keras untuk membuat hidup Anda lebih mudah dengan memotong semacam pita merah yang berulang.

app/views/agents/_agent.erb

Satu-satunya hal lain yang diperlukan untuk membuat pekerjaan ini adalah menempatkan templat parsial di jalur yang sesuai di direktori objek Anda dan mengekstrak atribut yang Anda butuhkan dari objek. Tidak perlu menulis loop sendiri. Ini cepat dan mudah, praktis dan pragmatis, saya katakan.

Ekstraksi ini pada awalnya dilakukan karena nama parsial sebagian besar waktu nama objek iterated, dan karena itu mudah untuk membuat konvensi yang menangani tugas umum ini lebih efektif.

The Bad

Oke, sekarang kita tahu bagaimana menangani ini, mari kita lihat apa yang Anda bisa dan harus hindari. Contoh di bawah ini hanya penggunaan Rails yang buruk, tetapi saya tidak akan menyebutnya jelek kali ini.

app/views/agents/index.html.erb

Anda mendapatkan hasil yang sama seperti di atas, tetapi pasti lebih banyak bertele-tele. Iterasi atas koleksi dalam tampilan tidak perlu lagi. Ketika Anda menggunakan render seperti di atas, agent parameter blok tersirat, dan Anda bisa menggunakannya tanpa each loop. Jadi jauhi kode seperti ini—itu tidak membuat Anda terlihat sangat baik (tapi tidak ada yang akan mengumpulkan kepalamu juga). Itu tidak elegan dan menambah PHPitis.

Extracting Helpers

Solusi paling jelas untuk membersihkan kode dari pandangan Anda adalah menghindari menulis atau mengekstraknya dengan cerdas. Katakanlah kami ingin mengacak nama agen kami di daftar indeks. Kita seharusnya tidak menempatkan kode ini secara langsung dalam pandangan kami. Jika kami memutuskan bahwa model tersebut juga bukan lapisan yang tepat untuk menempatkan ini, maka penolong khusus di direktori app/helpers mungkin merupakan pilihan yang tepat.

app/helpers/agents_helper.rb

Dengan mengemas ini dalam modul di dalam direktori helpers, kami sekarang memiliki akses ke metode ini dalam pandangan kami. Tolong beri pembantu khusus rumah mereka sendiri, dan jangan meletakkan semuanya di ApplicationHelper (app/helpers/application_helper.rb), yang sebenarnya dimaksudkan untuk hal-hal yang lebih 'global'.

Sekarang saya dapat mengakses lelaki kecil ini di templat parsial saya—atau tampilan apa pun—untuk memberikan koleksi agen saya.

app/views/agents/_agent.erb

Pembantu kustom Anda sendiri adalah cara yang bagus untuk menjaga pandangan Anda bersih dan sehat. Dan seperti yang Anda lihat, ini sangat cepat dan mudah sehingga ada sedikit alasan untuk menjadi terlalu malas dan tidak mengekstraknya untuk melawan PHPitis.

Conditional Content

Metode helper content_for adalah alat praktis untuk mengekstraksi konten yang tidak sesuai dengan tagihan untuk sebagian tetapi membutuhkan sedikit enkapsulasi. Ini adalah cara untuk menyimpan sedikit markup yang dapat Anda terapkan berdasarkan halaman per halaman—Anda menghasilkannya ke tata letak di mana diperlukan. Dalam ukuran, itu harus jauh lebih kecil daripada sebagian atau bahkan tata letak.

Teknik ini juga dapat menyelamatkan Anda dari langkah membuat metode Anda sendiri untuk itu. Menu navigasi atau bilah samping sering menjadi contoh di mana bantuan ini bermanfaat. Katakanlah Anda ingin memiliki tempat di menu Anda yang hanya untuk admin, tetapi Anda tidak perlu menyesuaikan seluruh tata letak. Atau Anda memiliki halaman di mana bilah sisi tidak diperlukan. Dengan content_for, Anda menyuntikkan apa yang Anda butuhkan di mana Anda membutuhkannya berdasarkan halaman per halaman. Duplikasi tidak lagi!

app/views/agents/index.html.erb
app/views/layouts/application.html.erb

Selain dari fakta bahwa header ini adalah kandidat yang baik untuk ekstraksi menjadi parsial, lihat bagian hasil :double_o_navbar. Ini adalah wilayah yang menghasilkan yang menyisipkan kode dari blok content_for. Itu hanya akan memasukkan kode jika nama simbol cocok. Di sini kami ingin hanya agen ganda yang memiliki akses ke tautan tertentu di navbar. Semua orang hanya melihat Home dan About. Pikirkan tentang tautan khusus yang perlu dilihat admin yang seharusnya tidak pernah menghadapi antarmuka publik.

Anda juga dapat menggunakan bantuan ini untuk menyisipkan id atau atribut class pada tag HTML jika diperlukan. Sekali-sekali ini berguna.

Penggunaan umum lainnya adalah mengisi <title> halaman secara dinamis dengan blok content_for.

app/views/layouts/application.html.erb
some.html.erb

Anda cukup menempatkan judul yang Anda inginkan di blok content_for dan tata letak aplikasi akan menyisipkannya untuk Anda. Anda bisa menjadi lebih pintar dengan itu, tetapi itu sudah cukup untuk saat ini. Jika Anda tidak membutuhkan judul atau lupa menambahkannya, maka logis || akan menendang dan menghasilkan default pilihan Anda. Pada contoh di atas, kita perlu memeriksa keberadaan judul atau default tidak akan berfungsi.

Yang pasti tidak ingin Anda lakukan adalah membuat variabel instan untuk hal semacam itu. Tanggung jawab tunggal, ingat?

Satu hal lagi: Anda dapat bertanya apakah halaman memiliki blok content_for.

app/views/layouts/application.html.erb

Ini dapat membantu Anda menghindari duplikasi markup yang relevan dengan mendisain halaman yang beradaptasi jika elemen ada di halaman atau tidak.

Semantic Markup

Ini adalah hal yang pasti ingin Anda hindari.

Markup di atas adalah dari dokumentasi bootstrap dan menentukan bagaimana kolom seharusnya "terlihat"-informasi yang tidak memiliki makna semantik dan sebenarnya termasuk dalam stylesheet Anda. Itulah hal-hal yang dimiliki para desainer tentang mimpi buruk.

Jadi apa masalahnya dengan itu? Ini penting karena—selain penamaan kelas yang dipertanyakan—kenaikan harga yang tidak semestinya melanggar pemisahan kekhawatiran. Markup Anda tidak boleh diganggu dengan informasi gaya; alih-alih, keduanya harus berdiri sendiri dan memungkinkan Anda beralih gaya dengan mudah—tanpa menyentuh HTML Anda. Itu tidak sesulit kedengarannya pada awalnya. Namun, ini membutuhkan sedikit disiplin.

Ketika Anda dapat menjaga informasi penataan dari markup Anda, Anda telah secara efektif mengurangi PHPitis di front lain—untuk desainer yang esensial! Juga, penggunaan div generik tanpa makna yang melekat adalah contoh lain dari markup yang buruk. HTML5 memberi Anda banyak elemen berguna yang menyampaikan lebih banyak informasi kepada diri Anda di masa depan, pengembang lain, dan mesin pencari. Penamaan seharusnya sulit, tetapi HTML5 memberi Anda banyak elemen semantik yang membuat opsi Anda lebih mudah dalam hal itu.

Pikiran terakhir

Saya harap Anda telah melihat bahwa Rails Views tidak membutuhkan banyak cinta untuk bersinar. Pengembang bisa sedikit sombong tentang lapisan front-end. Berurusan dengan markup kadang-kadang tampaknya sedikit di bawah mereka—menulis HTML, DUH! Yah, saya tidak boleh melempar batu apa pun, tapi saya menghargai lapisan presentasi yang telah disetel dengan baik. Itu membuatnya jauh lebih menyenangkan untuk bekerja dengan dan, ketika dilakukan dengan benar, jauh lebih cepat untuk membuat perubahan yang tak terhindarkan. Memilah banyak kode Ruby yang dicampur dengan markup yang ditulis dengan buruk bukanlah pengalaman yang menyenangkan dalam buku saya.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.