StateController। इंटरफेस के विकास में एक घटना मॉडल। भाग 1

परिचय

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

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

एकल पृष्ठ दृष्टिकोण मुद्दे

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

एक और दृष्टिकोण जिसमें संशोधन की आवश्यकता थी वह मॉड्यूल के निर्माण के लिए मॉडल था। मैंने HTML के संबंध में MVC से दूर होने की कोशिश की, क्योंकि इसमें बहुत ही संदिग्ध दक्षता के साथ महत्वपूर्ण मात्रा में काम करने की आवश्यकता थी। मॉड्यूल को शिथिल रूप से जोड़ा जाना चाहिए, एक दूसरे के साथ सीधे संचार का कोई साधन नहीं होना चाहिए। डेटा कहाँ स्टोर करें? इसके लिए HTML का उपयोग क्यों न करें! DOM डेटा संरचनाओं के साथ काम करने के लिए स्मार्ट और सुविधाजनक उपकरण प्रदान करता है, वास्तव में, एक तैयार मॉडल है।

यह "धागे" को खोजने के लिए बना रहा, जिसके साथ यह सब एक साथ सिलना चाहिए। मेरे लिए एकमात्र विकल्प इवेंट मॉडल का उपयोग करना था। इस तरह से StateController v2 के बारे में आया।

ईवेंट मॉडल कैसे काम करता है?

यह दो मुख्य घटकों पर बनाया गया है: हैंडलर और इवेंट जनरेटर। घटनाओं को स्वयं अवैयक्तिक और नाम दिया जा सकता है। एक अवैयक्तिक घटना का एक उदाहरण एक फ़ंक्शन या विधि कॉल है
foo(1)

आप इस फ़ंक्शन को कॉल करते हैं क्योंकि आपको कुछ कार्रवाई करने या परिणाम प्राप्त करने की आवश्यकता होती है। यद्यपि हम औपचारिक रूप से इस घटना को "एक क्रिया प्रदर्शन" या "एक परिणाम प्राप्त करें" के रूप में नाम दे सकते हैं, हालांकि यह कहीं भी स्पष्ट रूप से प्रकट नहीं होता है। एक हैंडलर एक फ़ंक्शन या विधि है जिसे कहा जाता है।

नामित घटना का एक उदाहरण click । सब कुछ स्पष्ट, परिचित, परिचित है। जनरेटर एक निश्चित घटना को आग लगाता है जिसके लिए कुछ हैंडलर प्रतिक्रिया देते हैं।

आवेदन की संरचनात्मक घटना मॉडल

जेएस क्लासिक MVC से दूर होने की इच्छा, कमजोर अंतर-मॉड्यूल संचार की आवश्यकता के साथ मिलकर, मुझे निम्नलिखित निष्कर्षों की ओर ले गई:

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

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

हैंडलर वाहक के रूप में नोड्स
DOM ट्री के अंतिम नोड्स को किए गए कार्यों के लिए "जिम्मेदारी" को शिफ्ट करने से, हमें एक और अमूर्तता - स्क्रिप्ट मिलती है। किसी विशिष्ट नोड से बेहतर कोई नहीं जानता कि कुछ मामलों में क्या करना है। इस प्रकार, DOM दस्तावेज़ की संरचना कार्य के तर्क को वहन करती है। यहां घटना और चयनात्मक ढांचे के मॉडल के दृष्टिकोण में सबसे बुनियादी अंतर है।

डेवलपर्स जो एक चयनात्मक दृष्टिकोण के साथ काम करते हैं, का तर्क लगभग निम्नलिखित है: आवश्यक नोड्स का चयन करें और उनके साथ कार्यों का एक विशिष्ट सेट करें। घटना के दृष्टिकोण का तर्क: किसी को निश्चित कार्यों का प्रदर्शन करना चाहिए, क्योंकि सिस्टम ने स्थिति बदल दी है।

यह बहुत अलग नहीं है, आप कहते हैं। आइए निम्नलिखित समस्या का समाधान करें। हमारे पास फॉर्म के तीन तत्व हैं: पंजीकरण पता (ra) , निवास का पता (la) , चेकबॉक्स "निवास का पता पंजीकरण पते के साथ मेल खाता है" (ch) । डिफ़ॉल्ट रूप से, चेकबॉक्स चिह्नित स्थिति में है, निवास का पता छिपा हुआ है। यदि उपयोगकर्ता अनियंत्रित होता है, तो हम उसे निवास के पते के साथ क्षेत्र दिखाते हैं। जब आप चेकबॉक्स बंद करते हैं, तो इनपुट फॉर्म न केवल छिपा होता है, बल्कि उपयोगकर्ता इनपुट से भी साफ हो जाता है। कुछ भी जटिल नहीं है।

एक चयनात्मक तकनीक का उपयोग करके एक सार कार्यान्वयन कुछ इस तरह दिखाई देगा:

1. ch पर एक click हैंडलर ch जो 2 करेगा
2. यदि राज्य की जाँच की जाती है, तो 3, अन्यथा 5
3. ला दिखाओ
4. निकास
5. ला को छिपाओ
6. साफ ला
7. निकास

इवेंट विधि का उपयोग करते हुए एक सार कार्यान्वयन इस तरह दिखेगा:

1. ch पर click ईवेंट हैंडलर ch जो 2 करेगा
2. यदि राज्य की checked जाती checked , तो 3, अन्यथा 5
3. आग equal_data घटना
4. निकास
5. not_equal_data ईवेंट को आग not_equal_data
6. निकास

1. equal_data हैंडलर को la पर equal_data , जो 2 करेगा
2. नोड छिपाएँ
3. स्पष्ट रूप
4. निकास

1. la पर एक not_equal_data हैंडलर not_equal_data जो 2 करेगा
2. नोड दिखाएँ
3. निकास

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

घटना के दृष्टिकोण से सकारात्मक क्षण

परीक्षण का समय कम हो जाता है, क्योंकि संपादन करते समय, काम का मूल तर्क नहीं टूटता है, केवल हैंडलर जोड़े जाते हैं, और इसके विपरीत, हैंडलर स्क्रिप्ट परिवर्तनों पर निर्भर नहीं होते हैं।

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

नकारात्मक क्षण

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

ऐसे कार्य हैं जो आसानी से चयनात्मक विधि द्वारा हल किए जा सकते हैं, लेकिन इस तथ्य से नहीं कि यह घटना दृष्टिकोण के साथ समान रूप से सामने आएगा।

अगले लेख में मैं व्यावहारिक कार्यान्वयन के करीब जाऊंगा।
भाग २

आपका ध्यान के लिए धन्यवाद!