Ruby on Rails पैटर्न और एंटी-पैटर्न श्रृंखला की तीसरी किस्त में आपका स्वागत है। पिछले पोस्ट में, हमने सामान्य रूप से पैटर्न और एंटी-पैटर्न को कवर किया साथ ही Rails मॉडल के संबंध में। इस पोस्ट में, हम Rails व्यू से जुड़े कुछ पैटर्न और एंटी-पैटर्न पर जाने जा रहे हैं।
Rails व्यू कभी-कभी पूरी तरह से काम कर सकते हैं और तेज़ हो सकते हैं, और अन्य समय में, उनमें सभी प्रकार के मुद्दे हो सकते हैं। यदि आप अपने व्यू को कैसे संभालते हैं इस पर आत्मविश्वास बढ़ाना चाहते हैं या आप बस इस विषय पर अधिक सीखना चाहते हैं, तो यह ब्लॉग पोस्ट आपके लिए है। आइए सीधे अंदर गोता लगाएं।
जैसा कि आप शायद जानते हैं, Rails फ्रेमवर्क कन्वेंशन ओवर कॉन्फ़िगरेशन का पालन करता है। और चूंकि Rails मॉडल-व्यू-कंट्रोलर (MVC) पैटर्न पर बड़ा है, आदर्श स्वाभाविक रूप से व्यू कोड पर भी लागू होता है। इसमें आपका मार्कअप (ERB या Slim फ़ाइलें), JavaScript और CSS फ़ाइलें शामिल हैं। पहली नज़र में, आप सोच सकते हैं कि व्यू लेयर बहुत सीधा और आसान है, लेकिन ध्यान रखें कि इन दिनों, व्यू लेयर में प्रौद्योगिकियों का मिश्रण रहता है।
हम व्यू में JavaScript, HTML, और CSS का उपयोग करते हैं। ये तीन भ्रम और कोड के अव्यवस्था का कारण बन सकते हैं — जिससे कार्यान्वयन होता है जो लंबे समय में ज्यादा समझ में नहीं आता। सौभाग्य से, आज हम Rails व्यू लेयर के साथ कुछ सामान्य समस्याओं और समाधानों से गुजरने जा रहे हैं।
पावरलिफ्टिंग व्यू
यह एक गलती है जो अक्सर नहीं होती, लेकिन जब होती है, तो यह एक आंखों की चुभन होती है। कभी-कभी, लोग डोमेन तर्क या क्वेरी सीधे व्यू के अंदर डालते हैं। इससे व्यू लेयर भारी-भरकम या पावरलिफ्टिंग करता है। दिलचस्प बात यह है कि Rails वास्तव में इसे आसानी से होने देता है। जब इस बात की बात आती है तो कोई 'सेफ्टी नेट' नहीं होता, आपको व्यू लेयर में जो चाहें करने की अनुमति है।
परिभाषा के अनुसार, MVC पैटर्न का व्यू लेयर प्रस्तुति तर्क होना चाहिए। इसे डोमेन तर्क या डेटा क्वेरी से परेशान नहीं होना चाहिए। Rails में, आपको ERB फ़ाइलें (एंबेडेड Ruby) मिलती हैं जो आपको Ruby कोड लिखने की अनुमति देती हैं जो तब HTML में मूल्यांकन हो जाएगा। यदि हम एक वेबसाइट का उदाहरण मानते हैं जो इंडेक्स पेज पर गाने सूचीबद्ध करती है, तो व्यू तर्क app/views/songs/index.html.erb में होगा।
यह वर्णन करने के लिए कि "पावरलिफ्टिंग" का क्या अर्थ है और क्या नहीं करना है, आइए निम्नलिखित उदाहरण पर एक नज़र डालें:
# app/views/songs/index.html.erb <div class="songs"> <% Song.where(published: true).order(:title) do |song| %> <section id="song_<%= song.id %>"> <span><%= song.title %></span> <span><%= song.description %></span> <a href="<%= song.download_url %>">Download</a> </section> <% end %> </div>यहां एक बड़ा एंटी-पैटर्न मार्कअप में गाने लाना है। डेटा लाने की जिम्मेदारी कंट्रोलर या एक सेवा को सौंपी जानी चाहिए जिसे कंट्रोलर से बुलाया जा रहा है। मैं कभी-कभी लोगों को कंट्रोलर में कुछ डेटा तैयार करते हुए और बाद में व्यू में अधिक डेटा लाते हुए देखता हूं। यह खराब डिज़ाइन है और यह आपकी वेबसाइट को धीमा कर देता है क्योंकि आप अपने डेटाबेस को अधिक बार क्वेरी के साथ जोर दे रहे हैं।
आपको इसके बजाय कंट्रोलर एक्शन से एक @songs इंस्टेंस वेरिएबल उजागर करना चाहिए और उसे मार्कअप में कॉल करना चाहिए, जैसे:
class SongsController < ApplicationController ... def index @songs = Song.all.where(published: true).order(:title) end ... end# app/views/songs/index.html.erb <div class="songs"> <% @songs.each do |song| %> <section id="song_<%= song.id %>"> <span><%= song.title %></span> <span><%= song.description %></span> <a href="<%= song.download_url %>">Download</a> </section> <% end %> </div>ये उदाहरण पूर्ण से बहुत दूर हैं। यदि आप अपने कंट्रोलर कोड को अधिक पठनीय रखना चाहते हैं और SQL पास्ता से बचना चाहते हैं, तो मैं आपसे पिछले ब्लॉग पोस्ट को देखने का आग्रह करता हूं। साथ ही, व्यू लेयर में तर्क छोड़ने से संभावना बढ़ जाती है कि अन्य लोग इसके आधार पर अपने समाधान बनाने का प्रयास करेंगे।
Rails जो आपको देता है उसका उपयोग करें
हम इसे यहां संक्षिप्त रखेंगे। Ruby on Rails एक फ्रेमवर्क के रूप में बहुत सारे साफ हेल्पर्स के साथ आता है, विशेष रूप से व्यू के अंदर। ये निफ्टी छोटे हेल्पर्स आपको अपने व्यू लेयर को तेजी से और आसानी से बनाने की अनुमति देते हैं। Rails के एक शुरुआती उपयोगकर्ता के रूप में, आप अपने ERb फ़ाइलों के अंदर पूर्ण HTML लिखने के लिए ललचा सकते हैं जैसे:
# app/views/songs/new.html.erb <form action="/songs" method="post"> <div class="field"> <label for="song_title">Title</label> <input type="text" name="song[title]" id="song_title"> </div> <div class="field"> <label for="song_description">Description</label> <textarea name="song[description]" id="song_description"></textarea> </div> <div class="field"> <label for="song_download_url">Download URL</label> <textarea name="song[download_url]" id="song_download_url"></textarea> </div> <input type="submit" name="commit" value="Create Song"> </form>इस HTML के साथ, आपको नीचे स्क्रीनशॉट में देखे अनुसार एक नए गाने के लिए एक अच्छा फॉर्म मिलना चाहिए:
लेकिन, Rails के साथ, आपको इसकी आवश्यकता नहीं है और आपको ऐसा सादा HTML नहीं लिखना चाहिए क्योंकि Rails वहीं आपकी पीठ थपथपाता है। आप form_with व्यू हेल्पर का उपयोग कर सकते हैं जो आपके लिए HTML उत्पन्न करेगा। form_with को Rails 5.1 में पेश किया गया था और यह form_tag और form_for को बदलने के लिए है जो कुछ लोगों से परिचित हो सकते हैं। आइए देखें कि form_with हमें अतिरिक्त कोड लिखने से कैसे राहत दे सकता है:
<%= form_with(model: song, local: true) do |form| %> <div class="field"> <%= form.label :title %> <%= form.text_field :title %> </div> <div class="field"> <%= form.label :description %> <%= form.text_area :description %> </div> <div class="field"> <%= form.label :download_url do %> Download URL <% end %> <%= form.text_area :download_url %> </div> <%= form.submit %> <% end %>HTML उत्पन्न करने के अलावा, form_with एक प्रामाणिकता टोकन भी उत्पन्न करता है जो CSRF हमलों को रोकता है। इसलिए लगभग सभी मामलों में, आप नामित हेल्पर्स का उपयोग करने से बेहतर हैं क्योंकि वे Rails फ्रेमवर्क के साथ अच्छी तरह से खेल सकते हैं। यदि आपने सादे HTML फॉर्म को सबमिट करने का प्रयास किया, तो यह विफल हो जाएगा क्योंकि अनुरोध के साथ कोई मान्य प्रामाणिकता टोकन सबमिट नहीं किया गया था।
form_with, label, text_area, और submit हेल्पर्स के अलावा, Rails के साथ आउट-ऑफ-द-बॉक्स आने वाले इन व्यू हेल्पर्स का एक गुच्छा और है। वे आपके जीवन को आसान बनाने के लिए हैं और आपको उन्हें बेहतर तरीके से जानना चाहिए। "ऑल-स्टार्स" में से एक निश्चित रूप से link_to है:
<%= link_to "Songs", songs_path %>जो निम्न HTML उत्पन्न करेगा:
<a href="/songs">Songs</a>मैं प्रत्येक हेल्पर पर ज्यादा विस्तार से नहीं जाऊंगा, क्योंकि यह पोस्ट बहुत लंबी हो जाएगी और उन सभी से गुजरना आज के विषय का हिस्सा नहीं है। मैं सुझाव देता हूं कि आप Rails Action View हेल्पर्स गाइड से गुजरें और चुनें कि आपको अपनी वेबसाइट के लिए क्या चाहिए।
व्यू कोड का पुन: उपयोग और आयोजन
आइए आदर्श वेब एप्लिकेशन की कल्पना करें। आदर्श उपयोग-मामले में, कोई if-else कथन नहीं हैं, बस शुद्ध कोड जो कंट्रोलर से डेटा लेता है और इसे HTML टैग के बीच रखता है। उस तरह का एप्लिकेशन शायद हैकथॉन और सपनों में मौजूद है, लेकिन वास्तविक दुनिया के एप्लिकेशन में व्यू रेंडर करते समय शाखाओं और शर्तों का एक गुच्छा होता है।
जब पेज के कुछ हिस्सों को दिखाने का तर्क बहुत जटिल हो जाता है तो आपको क्या करना चाहिए? आप वहां से कहां जाते हैं? एक सामान्य उत्तर शायद एक आधुनिक JavaScript लाइब्रेरी या फ्रेमवर्क तक पहुंचना और कुछ जटिल बनाना होगा। लेकिन, चूंकि यह पोस्ट Rails व्यू के बारे में है, आइए उन विकल्पों को देखें जो हमारे पास उनके अंदर हैं।
आफ्टर-मार्केट (कस्टम) हेल्पर्स
मान लीजिए आप एक गाने के नीचे कॉल-टू-एक्शन (CTA) बटन दिखाना चाहते हैं। लेकिन, एक पकड़ है — एक गाने में या तो डाउनलोड URL हो सकता है या, किसी भी कारण से, यह गायब हो सकता है। हम निम्नलिखित जैसा कुछ कोड करने के लिए ललचा सकते हैं:
app/views/songs/show.html.erb ... <div class="song-cta"> <% if @song.download_url %> <%= link_to "Download", download_url %> <% else %> <%= link_to "Subscribe to artists updates", artist_updates_path(@song.artist) %> <% end %> </div> ...यदि हम उपरोक्त उदाहरण को एक अलग प्रस्तुति तर्क के रूप में देखते हैं, तो यह ज्यादा बुरा नहीं लगता, है ना? लेकिन, यदि इनमें से अधिक सशर्त रेंडर हैं, तो कोड कम पठनीय हो जाता है। यह किसी चीज के कहीं ठीक से रेंडर न होने की संभावना भी बढ़ाता है, खासकर यदि अधिक शर्तें हैं।
इनसे लड़ने का एक तरीका उन्हें एक अलग हेल्पर में निकालना है। सौभाग्य से, Rails हमें कस्टम हेल्पर्स आसानी से लिखने का एक तरीका प्रदान करता है। app/helpers में हम एक SongsHelper बना सकते हैं, जैसे:
module SongsHelper def song_cta_link content_tag(:div, class: 'song-cta') do if @song.download_url link_to "Download", @song.download_url else link_to "Subscribe to artists updates", artist_updates_path(@song.artist) end end end endयदि हम गाने का शो पेज खोलते हैं, तो हमें अभी भी वही परिणाम मिलेंगे। हालांकि, हम इस उदाहरण को थोड़ा बेहतर बना सकते हैं। उपरोक्त उदाहरण में, हमने एक इंस्टेंस वेरिएबल @song का उपयोग किया। यह उपलब्ध नहीं हो सकता है यदि हम इस हेल्पर का उपयोग उस स्थान पर करने का निर्णय लेते हैं जहां @song nil है। इसलिए इंस्टेंस वेरिएबल के रूप में बाहरी निर्भरता को काटने के लिए, हम हेल्पर में एक आर्गुमेंट पास कर सकते हैं जैसे:
module SongsHelper def song_cta_link(song) content_tag(:div, class: 'song-cta') do if song.download_url link_to "Download", song.download_url else link_to "Subscribe to artists updates", artist_updates_path(song.artist) end end end endतब, व्यू में, हम हेल्पर को नीचे की तरह कॉल कर सकते हैं:
app/views/songs/show.html.erb ... <%= song_cta_link(@song) %> ...उसके साथ, हमें व्यू में वही परिणाम मिलने चाहिए जो हमने पहले किए थे। हेल्पर्स का उपयोग करने के बारे में अच्छी बात यह है कि आप उनके लिए टेस्ट लिख सकते हैं यह सुनिश्चित करते हुए कि भविष्य में उनके संबंध में कोई रिग्रेशन नहीं होता। एक नुकसान यह है कि वे विश्व स्तर पर परिभाषित हैं और आपको यह सुनिश्चित करना होगा कि हेल्पर नाम आपके ऐप में अद्वितीय हैं।
यदि आप Rails कस्टम हेल्पर्स लिखने के बड़े प्रशंसक नहीं हैं, तो आप हमेशा Draper जेम के साथ व्यू मॉडल पैटर्न का विकल्प चुन सकते हैं। या आप यहां अपना खुद का व्यू मॉडल पैटर्न रोल कर सकते हैं, यह इतना जटिल नहीं होना चाहिए। यदि आप अपने वेब ऐप के साथ अभी शुरुआत कर रहे हैं, तो मैं कस्टम हेल्पर्स लिखकर धीरे-धीरे शुरू करने का सुझाव देता हूं और यदि वह दर्द लाता है, तो अन्य समाधानों की ओर मुड़ें।
अपने व्यू को DRY करें
जब मैंने Rails के साथ शुरुआत की तो मुझे वास्तव में जो पसंद आया वह आपके मार्कअप को DRY करने की क्षमता थी जो मुझे लगभग अविश्वसनीय लगी। Rails आपको पार्शियल बनाने की क्षमता देता है — पुन: प्रयोज्य कोड टुकड़े जिन्हें आप कहीं भी शामिल कर सकते हैं। उदाहरण के लिए, यदि आप गाने को कई स्थानों पर रेंडर कर रहे हैं, और आपके पास कई फ़ाइलों में वही कोड है, तो गाने का पार्शियल बनाना समझ में आता है।
मान लीजिए आप अपना गाना नीचे दिखाए अनुसार दिखाते हैं:
# app/views/songs/show.html.erb <p id="notice"><%= notice %></p> <p> <strong>Title:</strong> <%= @song.title %> </p> <p> <strong>Description:</strong> <%= @song.description %> </p> <%= song_cta_link %> <%= link_to 'Edit', edit_song_path(@song) %> | <%= link_to 'Back', songs_path %>लेकिन, आप इसे दूसरे पेज पर उसी मार्कअप के साथ दिखाना भी चाहते हैं। तब आप अंडरस्कोर प्रीफिक्स के साथ एक नई फ़ाइल बना सकते हैं जैसे app/views/songs/_song.html.erb।
# app/views/songs/_song.html.erb <p> <strong>Title:</strong> <%= @song.title %> </p> <p> <strong>Description:</strong> <%= @song.description %> </p> <%= song_cta_link(@song) %>और फिर जहां भी आप गाने के पार्शियल को शामिल करना चाहते हैं, आप बस निम्नलिखित करते हैं:
... <%= render "song" %> ...Rails _song पार्शियल मौजूद है या नहीं, इसका ऑटो-लुकअप करेगा और इसे रेंडर करेगा। कस्टम हेल्पर्स के उदाहरण के समान, यह सबसे अच्छा है यदि हम अपने पार्शियल में इंस्टेंस वेरिएबल @song से छुटकारा पा लेते हैं।
# app/views/songs/_song.html.erb <p> <strong>Title:</strong> <%= song.title %> </p> <p> <strong>Description:</strong> <%= song.description %> </p> <%= song_cta_link(song) %>तब, हमें पार्शियल में गाने वेरिएबल को पास करना होगा, जिससे यह अधिक पुन: प्रयोज्य और अन्य स्थानों में शामिल होने के लिए उपयुक्त हो जाता है।
... <%= render "song", song: @song %> ...अंतिम विचार
इस पोस्ट के लिए बस इतना ही। सारांश के लिए, हम कुछ पैटर्न और एंटी-पैटर्न से गुजरे जो आप Rails व्यू क्षेत्र में आ सकते हैं। यहां कुछ निष्कर्ष हैं:
- UI में जटिल तर्क से बचें (व्यू को बहुत अधिक पावरलिफ्टिंग न करने दें)
- सीखें कि Rails आपको व्यू हेल्पर्स के मामले में आउट-ऑफ-द-बॉक्स क्या देता है।
- कस्टम हेल्पर्स और पार्शियल के साथ अपने कोड को संरचित और पुन: उपयोग करें
- इंस्टेंस वेरिएबल पर बहुत अधिक निर्भर न करें।
अगले पोस्ट में, हम Rails कंट्रोलर पैटर्न और एंटी-पैटर्न को कवर करेंगे जहां चीजें काफी गड़बड़ हो सकती हैं। उसके लिए बने रहें।
अगली बार तक, चीयर्स!
P.S. यदि आप Ruby Magic पोस्ट को प्रेस से निकलते ही पढ़ना चाहते हैं, तो हमारे Ruby Magic न्यूज़लेटर की सदस्यता लें और कभी भी एक भी पोस्ट मिस न करें!
