रूबी ऑन रेल्स पैटर्न और एंटी-पैटर्न देखें

रूबी ऑन रेल्स पैटर्न और एंटी-पैटर्न श्रृंखला की तीसरी किस्त में आपका स्वागत है। पिछली पोस्टों में, हमने सामान्य रूप से और साथ ही रेल मॉडल के संबंध में पैटर्न और विरोधी पैटर्न को कवर किया था। इस पोस्ट में, रेल के विचारों से जुड़े कुछ पैटर्न और विरोधी पैटर्न पर जाने वाले हैं।

रेल के विचार कभी-कभी पूरी तरह से काम कर सकते हैं और तेज हो सकते हैं, और अन्य समय में, उनके पास सभी प्रकार के मुद्दे हो सकते हैं। यदि आप अपने विचारों को कैसे संभालते हैं, इस पर विश्वास बढ़ाना चाहते हैं या आप इस विषय पर अधिक जानना चाहते हैं, तो यह ब्लॉग पोस्ट है तुम। आइए सीधे अंदर जाएं।

जैसा कि आप शायद जानते हैं, रेल ढांचा विन्यास पर सम्मेलन का पालन करता है। और चूंकि मॉडल-व्यू-कंट्रोलर (एमवीसी) पैटर्न पर रेल बड़ा है, इसलिए आदर्श रूप से व्यू कोड पर भी लागू होता है। इसमें आपका मार्कअप (ईआरबी या स्लिम फाइलें), जावास्क्रिप्ट और सीएसएस फाइलें शामिल हैं। पहली नज़र में, आप सोच सकते हैं कि व्यू लेयर काफी सीधी और आसान है, लेकिन ध्यान रखें कि आजकल व्यू लेयर में तकनीकों का मिश्रण है।

हम दृश्य में JavaScript, HTML और CSS का उपयोग करते हैं। ये तीनों कोड के भ्रम और अव्यवस्था का कारण बन सकते हैं - जिससे कार्यान्वयन हो सकता है जो लंबे समय में ज्यादा मायने नहीं रखता है। सौभाग्य से, आज हम Rails View लेयर के साथ कुछ सामान्य समस्याओं और समाधानों को समझने जा रहे हैं।

पावरलिफ्टिंग दृश्य

यह एक गलती है जो अक्सर नहीं होती है, लेकिन जब ऐसा होता है, तो यह दुख की बात है। कभी-कभी, लोग डोमेन लॉजिक या क्वेरी को सीधे व्यू के अंदर रखने की प्रवृत्ति रखते हैं। इससे व्यू लेयर हैवी-लिफ्टिंग या पावरलिफ्टिंग करती है। मजे की बात यह है कि रेल वास्तव में इसे आसानी से होने देता है। जब इसकी बात आती है तो कोई 'सुरक्षा जाल' नहीं होता है, आपको व्यू लेयर में जो कुछ भी आप चाहते हैं उसे करने की अनुमति है।

परिभाषा के अनुसार, एमवीसी पैटर्न की व्यू लेयर में प्रेजेंटेशनलॉजिक होना चाहिए। इसे डोमेन लॉजिक या क्वेरी डेटा से परेशान नहीं किया जाना चाहिए। रेल में, आपको ईआरबी फाइलें (एंबेडेड रूबी) मिलती हैं जो आपको रूबी कोड लिखने की अनुमति देती हैं, जिसका मूल्यांकन 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 पास्ता से बचना चाहते हैं, तो मैं आपसे पिछले ब्लॉग पोस्ट को देखने का आग्रह करता हूं। साथ ही, व्यू लेयर में तर्क को छोड़ने से संभावना बढ़ जाती है कि अन्य लोग इससे अपना समाधान बनाने का प्रयास करेंगे।

रेल जो आपको देती है उसका उपयोग करें

हम इसे यहां छोटा रखेंगे। एक ढांचे के रूप में रेल पर रूबी बहुत सारे साफ-सुथरे सहायकों के साथ आता है, खासकर दृश्य के अंदर। ये छोटे सहायक आपको जल्दी और आसानी से अपना व्यू लेयर बनाने की अनुमति देते हैं। रेल के शुरुआती उपयोगकर्ता के रूप में, आप अपनी ईआरबी फाइलों के अंदर पूर्ण एचटीएमएल लिखने का लुत्फ उठा सकते हैं:

# 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 के साथ, आपको एक नए गाने के लिए एक अच्छा फॉर्म मिलना चाहिए जैसा कि नीचे स्क्रीनशॉट में देखा गया है:

लेकिन, रेल के साथ, आपको इसकी आवश्यकता नहीं है और आपको सादा HTML नहीं लिखना चाहिए क्योंकि रेल की आपकी पीठ वहीं है। आप form_with . का उपयोग कर सकते हैं सहायक देखें जो आपके लिए HTML उत्पन्न करेगा। form_with रेल 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 एक प्रामाणिकता टोकन भी उत्पन्न करता है जो सीएसआरएफ हमलों को रोकता है। तो लगभग सभी मामलों में, आप नामित सहायकों को बेहतर तरीके से बंद कर रहे हैं क्योंकि वे रेल ढांचे के साथ अच्छी तरह से खेल सकते हैं। यदि आप एक सादा HTML फॉर्म जमा करने का प्रयास करते हैं, तो यह असफल हो जाएगा क्योंकि अनुरोध के साथ सबमिट किया गया नोवेलिड प्रामाणिकता टोकन था।

इसके अलावा form_with , label , text_area , और submit हेल्पर्स, इनमें से कई व्यू हेल्पर्स हैं जो रेल के साथ आउट-ऑफ-द-बॉक्स आते हैं। वे आपके जीवन को आसान बनाने के लिए हैं और आपको उन्हें बेहतर तरीके से जानना चाहिए। "ऑल-स्टार्स" में से एक निश्चित रूप से link_to है :

<%= link_to "Songs", songs_path %>

जो निम्नलिखित HTML उत्पन्न करेगा:

<a href="/songs">Songs</a>

मैं प्रत्येक सहायक के बारे में अधिक विस्तार में नहीं जाउंगा, क्योंकि यह पोस्ट बहुत लंबी होगी और उन सभी के माध्यम से जाना आज के विषय का हिस्सा नहीं है। मेरा सुझाव है कि आप रेल एक्शन व्यू हेल्पर्स गाइड के माध्यम से जाएं और अपनी वेबसाइट के लिए आपको जो चाहिए उसे चुनें।

व्यू कोड का पुन:उपयोग और व्यवस्थित करना

आइए सही वेब एप्लिकेशन की कल्पना करें। सही उपयोग के मामले में, कोई और कथन नहीं है, केवल शुद्ध कोड है जो नियंत्रक से डेटा लेता है और इसे HTML टैग के बीच रखता है। उस तरह का एप्लिकेशन शायद हैकाथॉन और सपनों में मौजूद है, लेकिन वास्तविक दुनिया के अनुप्रयोगों में दृश्य प्रस्तुत करते समय शाखाओं और शर्तों का एक समूह होता है।

जब किसी पृष्ठ के कुछ हिस्सों को दिखाने का तर्क बहुत जटिल हो जाए तो आपको क्या करना चाहिए? आपका वहां से कहां को जाना होता है? एक सामान्य उत्तर शायद आधुनिक जावास्क्रिप्ट लाइब्रेरी या ढांचे तक पहुंचना और कुछ जटिल बनाना होगा। लेकिन, चूंकि यह पोस्ट Rails Views के बारे में है, आइए उन विकल्पों को देखें जो हमारे अंदर हैं।

आफ्टर-मार्केट (कस्टम) हेल्पर्स

मान लें कि आप किसी गीत के नीचे कॉल-टू-एक्शन (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) %>
 
...

इसके साथ ही हमें दृष्टि में वही परिणाम मिलना चाहिए जो हमने पहले किया था। सहायकों का उपयोग करने के बारे में अच्छी बात यह है कि आप यह सुनिश्चित करने के लिए परीक्षण लिख सकते हैं कि भविष्य में उनके संबंध में कोई भी प्रतिगमन न हो। एक नुकसान यह है कि वे विश्व स्तर पर परिभाषित हैं और आपको यह सुनिश्चित करना होगा कि आपके ऐप में सहायक नाम अद्वितीय हैं।

यदि आप रेल कस्टम हेल्पर्स लिखने के बहुत बड़े प्रशंसक नहीं हैं, तो आप ड्रेपर रत्न के साथ एक व्यू मॉडल पैटर्न को हमेशा ऑप्ट-इन कर सकते हैं। या आप यहां अपना खुद का व्यू मॉडल पैटर्न रोल कर सकते हैं, यह इतना जटिल नहीं होना चाहिए। यदि आप अभी अपने वेब ऐप से शुरुआत कर रहे हैं, तो मेरा सुझाव है कि कस्टम हेल्पर्स लिखकर धीरे-धीरे शुरुआत करें और अगर इससे दर्द होता है, तो अन्य समाधानों की ओर मुड़ें।

अपने विचारों में सुधार करें

जब मैंने रेल के साथ शुरुआत की तो मुझे वास्तव में जो पसंद आया, वह आपके मार्कअप को आसानी से सुखाने की क्षमता थी कि यह मेरे लिए लगभग अविश्वसनीय था। रेल आपको आंशिक - पुन:प्रयोज्य कोड टुकड़े बनाने की क्षमता देता है जिसे आप कहीं भी शामिल कर सकते हैं। उदाहरण के लिए, यदि आप कई स्थानों पर गाने प्रस्तुत कर रहे हैं, और आपके पास कई फाइलों में एक ही कोड है, तो गाने को आंशिक बनाना समझ में आता है।

मान लें कि आप अपना गाना नीचे दिखाए अनुसार दिखाते हैं:

# 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" %>
 
...

रेल एक ऑटो-लुकअप करेगी कि क्या _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 आपको सबसे अलग क्या देता है।
• कस्टम हेल्पर्स और पार्टिकल के साथ अपने कोड की संरचना और पुन:उपयोग करें
• इंस्टेंस वैरिएबल पर बहुत अधिक निर्भर न रहें।

अगली पोस्ट में, हम रेल कंट्रोलर पैटर्न और एंटी-पैटर्न को कवर करेंगे जहां चीजें बहुत गड़बड़ हो सकती हैं। उसके लिए बने रहें।

अगले एक तक, चीयर्स!

पी.एस. यदि आप रूबी मैजिक की पोस्ट प्रेस से छूटते ही पढ़ना चाहते हैं, तो हमारे रूबी मैजिक न्यूजलेटर की सदस्यता लें और एक भी पोस्ट मिस न करें!