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

मैं इस लेख में एक बार कुछ विचारों को ठीक करना चाहता हूं, जिसे तब संदर्भित किया जा सकता है। मेरी राय में, AngularJS और विभिन्न अन्य रूपरेखाओं के बीच वास्तव में महत्वपूर्ण अंतर अलग-अलग संयोजनों में तीन चीजें हैं:

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

और यहां तीसरा बिंदु मुझे समझना सबसे मुश्किल लगता है। उसके बारे में बात करते हैं।

डेटा बाइंडिंग क्या है? मोटे तौर पर, यह एक टेम्प्लेट में डेटा का प्रदर्शन है, जिसे बनाया गया है ताकि डेटा बदलने से उनकी प्रस्तुति बदल जाए। किसी वस्तु का होना:

var myViewModel = { personName: 'Bob', personAge: 123 };

... और टेम्पलेट:

 <span>personName</span>

... हम चाहते हैं कि myViewModel परिवर्तन होने पर हम न्यूनतम भागीदारी के साथ वर्तमान स्थिति में अपडेट हो myViewModel । और इसके विपरीत, यदि यह है, उदाहरण के लिए, एक इनपुट फ़ील्ड।

और इस समस्या को हल करने के लिए, दो मौलिक रूप से अलग-अलग दृष्टिकोण हैं।

श्रोताओं को बदलें

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

 var myViewModel = { personName: ko.observable('Bob'), personAge: ko.observable(123) }; ... myViewModel.personName('Mary'); myViewModel.personAge(50);

 <span data-bind="text: personName"></span>

एक स्मार्ट और स्पष्ट समाधान। ऐसा लगता है कि जावास्क्रिप्ट में कार्यात्मक और घटना-उन्मुख प्रोग्रामिंग ऐसे कार्यों के लिए पूरी तरह से अनुकूल है, और वास्तव में, कॉलबैक के साथ काम करना हमारा सबसे मजबूत बिंदु है।

हालांकि, ऐसी समस्याएं हैं जिन्हें समान रूपरेखा द्वारा हल किया जाना है।

पहला, क्या होगा अगर किसी तरह से डेटा का एक टुकड़ा दूसरे पर निर्भर करता है? एक चर को बदलकर, हम स्वचालित रूप से यह रिपोर्ट करते हैं, लेकिन इस मामले में जो दूसरा चर बदल गया है, वह किसी का ध्यान नहीं जाएगा। कोओ में इस तरह की निर्भरता को हल करने के लिए, एक निर्भरता ट्रैकिंग तंत्र है जो अच्छी तरह से काम करता है, लेकिन एक समाधान की उपस्थिति एक समस्या के अस्तित्व को इंगित करता है।

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

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

एक साथ, इस तरह के डेटा-बाइंडिंग तंत्र एक ऐसी जटिल प्रणाली बनाता है कि अन्य लोगों ने गॉर्डियन गाँठ को काटने और मौलिक रूप से अलग दृष्टिकोण का उपयोग करने का निर्णय लिया।

गंदी जाँच

इस सिद्धांत द्वारा AngularJS काम करता है। डर्टी चेकिंग डेटा में बदलाव के लिए एक जाँच है, जितना कि दो रूबल। पहले, चर myVar 1 था, अब यह 2 है - इसलिए डेटा बदल गया है और आपको उन्हें टेम्प्लेट में पुनः तैयार करने की आवश्यकता है। सरल चर के लिए, यह = = संचालक है, जटिल चर के लिए, इसी हल्के प्रक्रियाओं। यह सबसे सरल दृष्टिकोण है, जो हमें एक विशेष "सुनने" परत के माध्यम से डेटा के साथ काम करने की आवश्यकता, और डेटा निर्भरता से जुड़ी सभी समस्याओं से बचाता है।

 var myViewModel = { personName: 'Bob', personAge: 123 }; ... myViewModel.personName = 'Mary'; myViewModel.personAge = 50;

 <span>{{personName}}</span>

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

इसके अलावा, प्रत्येक पुनरावृत्ति के डेटा को एक बार में, उसकी संपूर्णता में जांचा जाता है, और केवल कुछ भाग को नहीं। $ पचने की क्रिया के पूरा होने से पहले और बाद में, हमारे पास पूरे राज्य का एक स्थिर संस्करण है, जो बिना desync के है। यदि, डेटा निर्भरता के कारण, सत्यापन प्रक्रिया के दौरान उनका एक हिस्सा बदल गया है, तो वर्तमान सत्यापन की समाप्ति के तुरंत बाद, अगले एक को शेड्यूल किया जाएगा। और अगले चेक को फिर से पूरी तरह से प्रदर्शन किया जाएगा, मॉडल की स्थिति को पूरी तरह से अपडेट करना, निर्भरता के लिए बेहिसाब समस्याओं के साथ संभावित समस्याओं को समाप्त करना।

इस दृष्टिकोण का स्पष्ट माइनस प्रदर्शन है। हालांकि एक छोटा अपवाद है: उदाहरण के लिए, जब बैच एक बार में बड़ी मात्रा में डेटा अपडेट करता है, तो चेक केवल एक बार अंत में किया जाता है, और हर बार मॉनिटर किए गए ऑब्जेक्ट में से प्रत्येक में परिवर्तन नहीं होता है, जैसा कि पहले मामले में होता है। लेकिन सामान्य तौर पर, यह फिर भी एक ऋण है, क्योंकि केवल एक चर को बदलते समय, सभी डेटा का एक गंदा चेक किया जाता है।

आपको केवल यह समझने की आवश्यकता है कि प्रदर्शन हानि कितनी मजबूत है।

यह ध्यान देने योग्य है कि गंदा चेक करते समय कोणीय कभी भी DOM के साथ काम नहीं करता है। सभी डेटा मूल js ऑब्जेक्ट्स हैं जिनके साथ सभी आधुनिक ब्राउज़र इंजन हल्के ढंग से अधिकांश बुनियादी ऑपरेशन करते हैं। यद्यपि आप सत्यापन प्रक्रियाओं को खुद को गंदी जांच प्रक्रिया में एम्बेड कर सकते हैं, लेकिन कोणीय प्रलेखन दृढ़ता से अनुशंसा करता है कि आप उनके अंदर DOM के साथ काम नहीं करते हैं, क्योंकि यह पूरी प्रक्रिया को धीमा कर सकता है।

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

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

AngularJS और नॉकआउट के बीच महत्वपूर्ण अंतर

श्रोताओं को बदलें

गंदी जाँच

More articles: