Ember.js (भाग एक, सैद्धांतिक) का एनाटॉमी

Ember.js सीखना मुश्किल है। हालांकि ऐसा भी नहीं है। Ember.js अवधारणाओं को सीखना और समझना मुश्किल है। यह मुझे लगता है कि किसी भी Ember.js प्रशिक्षण पाठ्यक्रम को इन शब्दों के साथ शुरू करना चाहिए।

मैं एक डेवलपर हूं जो रूबी के साथ रेल पर काम कर रहा हूं (इससे पहले मैंने .NET और पायथन में प्रोग्राम किया था)। यह मेरे लिए जादू को समझने के लिए काफी समस्याग्रस्त था जो एम्बर का काम करता है। कभी-कभी मैं अन्य नौसिखिया डेवलपर्स के साथ संवाद करता हूं, जिन्होंने एम्बर के मार्ग को शुरू किया है (या उकेरने की कोशिश कर रहे हैं) - उनकी सभी समस्याएं शुरू होती हैं, क्योंकि वे यह नहीं समझते हैं कि यह रूपरेखा कैसे काम करती है।

हां, एक तरफ आधिकारिक दस्तावेज है जिसमें इस ढांचे के सभी पहलुओं का विस्तार से वर्णन किया गया है। लेकिन उसके पास अवधारणा की कमी है; एक नौसिखिया डेवलपर के लिए, ये सिर्फ बेतरतीब ढंग से बिखरे हुए जानकारी के टुकड़े हैं। प्रलेखन से, उदाहरण के लिए, आप पता लगा सकते हैं कि हमारे पास नियंत्रक, मॉडल और विचार (नियंत्रक, मॉडल, दृश्य) के शस्त्रागार में हैं। लेकिन यह पता लगाने के लिए कि वे किस चीज के लिए जिम्मेदार हैं और वे कैसे काम करते हैं, शुरुआत करने वाले को पहले एक-दो दर्जन बार रेक पर कदम रखने की पेशकश की जाती है। साथ ही, Ember.js के नियंत्रकों, मॉडलों और विचारों पर भार हमें घटकों, टेम्प्लेट, राउटर और पथ (घटक, टेम्प्लेट, राउटर, मार्ग) जैसे मोटिव ऑब्जेक्ट्स की पूरी पलटन प्रदान करता है।

लेकिन सबसे पहली बात। आइए हम याद रखें कि यह एमवीसी (मॉडल-व्यू-कंट्रोलर) ढांचा नहीं है, यह याद करके एम्बर.जेएस के साथ अपना प्रशिक्षण शुरू करें; इसके बारे में भूल जाओ। हां, Ember.js में नियंत्रक, मॉडल और टेम्पलेट दृश्य हैं, लेकिन यह वह जगह है जहां एमवीसी रूपरेखा के साथ इसकी समानता समाप्त होती है। Ember.js उपयोगकर्ता के ब्राउज़र में चल रहे अनुप्रयोगों को लिखने के लिए एक रूपरेखा है।

निम्नलिखित आरेख पर एक नज़र डालें, यह विस्तार से वर्णन करता है कि एम्बर में लिखे एक मानक आवेदन में अनुरोध का जीवन चक्र:



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

तो कल्पना कीजिए कि Ember.js में लिखे गए एप्लिकेशन से जानकारी मिलती है कि एड्रेस बार में पता बदल दिया गया है। राउटर इस जानकारी को स्वीकार करता है और यह पता लगाने की कोशिश करता है कि इसके साथ आगे क्या करना है।

यूएफओ (एक मामूली गीतात्मक विषयांतर): Ember.js दो सिद्धांतों पर काम करता है। अधिवेशन पर नियम और यदि Ember.js को अपेक्षित वस्तु नहीं मिलती है, तो वह इसे अपने आंतरिक नियमों के आधार पर बनाता है। यहां यह Ember.js कोड जनरेटर के काम करने के तरीके पर ध्यान देने योग्य है। आप शायद अन्य रूपरेखाओं में जनरेटर से परिचित हैं: वे कोड के साथ एक फ़ाइल बनाते हैं और इसे आपकी डिस्क पर सहेजते हैं। अन्य रूपरेखाओं के विपरीत, Ember.js में कोड जनरेटर केवल एक ऑब्जेक्ट बनाता है जब उसे इसकी आवश्यकता होती है और इसे मेमोरी में रखता है। ऑब्जेक्ट के अनावश्यक हो जाने के बाद, Ember.js इसे नष्ट कर देता है - यह सिद्धांत आपको टेम्पलेट कोड के लिए अनावश्यक समर्थन से मुक्त करता है।

चलिए जारी रखते हैं। मान लें कि उपयोगकर्ता ने / पोस्ट पथ का अनुरोध किया है। इस क्वेरी के आधार पर, राउटर श्रृंखला में अगली वस्तु को उसके नाम से खोजने की कोशिश करेगा - पथ। जैसा कि आप शायद पहले से ही अनुमान लगा चुके हैं, Ember.js एक रूट प्रकार की वस्तु की तलाश करेंगे, जिसे PostRoute कहा जाता है। नियंत्रक को मॉडल प्रदान करने के लिए Ember.js का मार्ग जिम्मेदार है।

Ember.js PostModel नामक मॉडल की खोज करेगा। मॉडल आपके भंडारण और व्यावसायिक तर्क में संग्रहीत वस्तुओं की डेटा संरचना का वर्णन करता है। आप मॉडल को एक वर्ग के रूप में कल्पना कर सकते हैं जिसमें से Ember.js डेटा युक्त ऑब्जेक्ट बनाता है। एक डेटा वेयरहाउस एक अमूर्त तकनीकी परत है जो मॉडल और आपके सर्वर के बीच बैठता है। Ember.js सर्वर से लेने के बाद डेटा भंडार में संग्रहीत किया जाता है।

पथ डेटा लेने के बाद, यह नियंत्रक को देता है। इस मामले में नियंत्रक को पोस्टकंट्रोलर कहा जाएगा। यह ध्यान देने योग्य है कि नियंत्रक और मॉडल के बीच कोई सीधा संबंध नहीं है; वे एक दूसरे और नियंत्रक के बारे में नहीं जानते हैं, सिद्धांत रूप में, कोई फर्क नहीं पड़ता कि आप उसे किस मॉडल को देते हैं। नियंत्रक सिर्फ एक डेटा डेकोरेटर है - यह उपयोगकर्ता को देने से पहले उन्हें संसाधित करता है।

फिर Ember.js नियंत्रक से संसाधित डेटा लेता है और इसे टेम्पलेट को देता है। लेकिन एक और वस्तु है जो नियंत्रक और टेम्पलेट के बीच स्थित है - दृश्य। यह दृश्य है, जिसे हमारे मामले में PostView कहा जाएगा, Ember.js को बताता है कि इस अनुरोध के लिए किस टेम्पलेट का उपयोग किया जाना चाहिए। नियमों के अनुसार, Ember.js पोस्ट नामक एक टेम्पलेट का उपयोग करेगा।

प्रतिक्रिया

उपयोगकर्ता हमारे एप्लिकेशन (पोक बटन, ड्रैग एंड ड्रॉप एलीमेंट्स और डर्टी डेवलपर्स को यूजर के लिए उपलब्ध अन्य तरीकों से इंटरैक्ट कर सकते हैं)। Ember.js एप्लिकेशन के साथ दो प्रकार के उपयोगकर्ता सहभागिता के बीच अंतर करता है। पहला तथाकथित है नेटिव ब्राउज़र ईवेंट - क्लिक, ड्रैग, ड्रॉप, माउसइंटर, माउज़रलेव इत्यादि। दूसरा तरीका ऐसी घटनाएं हैं जिनका एक नाम है। दूसरे प्रकार की घटना मूल रूप से उस तत्व पर क्लिक करके चालू होती है जिस पर यह घटना निश्चित रूप से होती है।

तो क्या अंतर है, आप पूछें? खैर, या आप पूछना चाहते थे। पहले प्रकार की घटनाओं को विशेष रूप से दृश्य द्वारा नियंत्रित किया जाता है; Ember.js कोई फर्क नहीं पड़ता कि उपयोगकर्ता किस बटन पर क्लिक करता है, मुख्य तथ्य यह है कि क्लिक हुआ। एक विशिष्ट तत्व पर क्लिक करने के बाद ही दूसरा प्रकार काम करता है और नियंत्रक द्वारा संसाधित किया जाता है। यदि नियंत्रक ईवेंट को हैंडल नहीं कर सकता है, तो Ember.js ईवेंट को रूट (रूट ऑब्जेक्ट) में संसाधित करने का प्रयास करता है और उसके बाद ही कोई त्रुटि रिपोर्ट करता है।

पैटर्न संरचना

शुरुआती लोगों को पता चलने के बाद सब कुछ और भी भ्रामक लगने लगता है कि अन्य वस्तुओं को एम्बर.जैस टेम्प्लेट में एम्बेड किया जा सकता है, जिससे एक पूरा चक्र दोहराया जा सकता है। वास्तव में, चिंता की कोई बात नहीं है।

फिलहाल, आप पहले से ही जानते हैं कि टेम्पलेट का एक संदर्भ है - मॉडल, नियंत्रक और दृश्य।

चलो आंशिक पैटर्न के साथ शुरू करते हैं। यह सबसे आसान ऑब्जेक्ट है जिसे आप अपने टेम्प्लेट में डाल सकते हैं (हालाँकि ऑब्जेक्ट शायद आंशिक टेम्पलेट के लिए बहुत बड़ा नाम है)। Ember.js सिर्फ आपके द्वारा निर्दिष्ट टेम्पलेट लेता है और इसे मूल टेम्पलेट में प्रस्तुत करता है; यह माता-पिता के संदर्भ का उपयोग करेगा - अर्थात एक आंशिक टेम्पलेट में, आपके पास मॉडल, नियंत्रक और अभिभावक दृश्य तक पहुंच होगी। सीधे शब्दों में कहें, सभी घटनाओं को माता-पिता के दृष्टिकोण और नियंत्रक द्वारा नियंत्रित किया जाएगा।

दृश्य और घटक एक-दूसरे से काफी मिलते-जुलते हैं (सच में, दृश्य घटक का मूल वर्ग है)। दृश्य और घटक दोनों का अपना टेम्पलेट है। दृश्य और घटक के पीछे अपनी वस्तु है। अंतर दो प्रमुख बिंदुओं में है। सबसे पहले, घटना प्रसंस्करण - घटक स्वयं पंजीकृत घटनाओं को संसाधित करता है, और दृश्य बस उन्हें मूल टेम्पलेट में देता है, जो बदले में उन्हें नियंत्रक को देता है। दूसरे, पर्यावरण - घटक पूरी तरह से अलग है और केवल उन वस्तुओं के साथ काम कर सकता है जो आप उसे देते हैं; बदले में, मूल टेम्पलेट के लिए उपलब्ध सभी वस्तुओं तक पहुंच होती है। मूल टेम्पलेट के संदर्भ के संदर्भ में, दृश्य में मॉडल और नियंत्रक तक पहुंच होती है, लेकिन इसका अपना दृष्टिकोण होता है। घटक अधिक पृथक है और किसी भी चीज की पहुंच नहीं है।

अंतिम तत्व एक रेंडर है। यह टेम्प्लेट में उपलब्ध सभी वस्तुओं में से सबसे जटिल है। जब आप किसी टेम्प्लेट में रेंडर कहते हैं, तो आपको इसे दो मापदंडों के साथ प्रदान करने की आवश्यकता होती है - टेम्प्लेट और मॉडल का नाम। Ember.js को टेम्प्लेट मिल जाएगा और टेम्प्लेट के नाम के आधार पर नियंत्रक और दृश्य मिल जाएगा। फिर वह मॉडल को कंट्रोलर को देगा और कंट्रोलर मॉडल को प्रोसेस करने के बाद, Ember.js इसे टेम्प्लेट में डालेगा। सीधे शब्दों में कहें, एक रेंडर की मदद से, आप एक ही पृष्ठ पर एक दूसरे से पूरी तरह से अलग संदर्भ के साथ कई टेम्पलेट्स एकत्र कर सकते हैं; रेंडर में पेरेंट टेम्प्लेट के संदर्भ तक पहुंच नहीं है (इसके बजाय, रेंडर का अपना संदर्भ है) और सभी घटनाओं को दृश्य और रेंडर नियंत्रक का उपयोग करके संसाधित किया जाएगा।

मुझे आशा है कि आपने Ember.js के सैद्धांतिक परिचय का आनंद लिया है। यदि Ember.js आपकी रुचि है, तो आप आधिकारिक गाइड को पढ़कर इससे परिचित हो सकते हैं । आप मेरी पुस्तक की मदद से परिचितों को भी जारी रख सकते हैं, जिनमें से एक अध्याय का विस्तारित अनुवाद यह लेख है।