नॉकआउट हैंड्स ऑन अनुभव

कुछ समय पहले, मैंने नॉकआउट के साथ अपने अनुभव के बारे में बात करने का वादा किया था। हम पिछले 4 महीनों में एक परियोजना में इस पुस्तकालय का उपयोग कर रहे हैं। यह ज्यादा नहीं है, लेकिन इस दौरान टीम को कुछ अनुभव प्राप्त हुए, जो मुझे लगता है, पाठकों के लिए रूचि का हो सकता है।

लेकिन सिर्फ थोड़े सिद्धांत से शुरू करें।

एमवीसी, एमवीपी और एमवीवीएम।

यदि उनमें से अधिकांश पहले दो खाकों से कम या ज्यादा परिचित हैं, तो बहुत कम लोगों ने बाद के बारे में सुना है: MVVM टेम्पलेट Microsoft में दिखाई दिया और .net डेवलपर्स के बीच वितरण प्राप्त किया, लेकिन उनमें से भी यह इतने व्यापक रूप से ज्ञात नहीं है।

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



इस तरह के परिदृश्य की मुख्य विशेषता दृश्य का छोटा जीवनकाल है - यह प्रत्येक अनुरोध के लिए बनाया गया है, यह केवल एक पास में डेटा से भरा है - और यह सब है।

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

स्वाभाविक रूप से, कोई भी यह नहीं चाहता है, हर कोई यह चाहता है - ताकि कोड में एप्लिकेशन तर्क दिखाई दे, और मार्कअप में नहीं। यह बनाए रखना, परीक्षण करना और संशोधित करना आसान बनाता है। ऐसे मामलों में वे क्या करते हैं?

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



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

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

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

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



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

जावास्क्रिप्ट में, हमारे पास इस तरह का आयोजन समर्थन नहीं है, इसलिए MVVM टेम्पलेट को लागू करने के लिए दो चीजों की आवश्यकता होती है:

1. डोम तत्वों के ViewModel क्षेत्रों के लिए बाध्यकारी गुणों के लिए तंत्र।
2. ViewModel फ़ील्ड्स के बदलते मूल्यों से संबंधित घटनाओं के समर्थन के लिए PubSub इन्फ्रास्ट्रक्चर।

नॉकआउट जे.एस.

नॉकआउट जेएस एक ऐसा ढांचा है जो इन दोनों तंत्रों को लागू करता है। संचार के लिए View-ViewModel HTML5 डेटा-विशेषताओं का उपयोग किया जाता है।

एक उदाहरण:

< div id =” customerDetails ” data-bind =” visible: currentCustomer () !== null ” >

* This source code was highlighted with Source Code Highlighter .

currentCustomer - ViewModel में फ़ील्ड। यह वास्तव में एक क्षेत्र नहीं है:

var vewModel = {
currentCustomer: ko.observable(defaultCustomer),
…
}

* This source code was highlighted with Source Code Highlighter .

जैसा कि आप देख सकते हैं, फ़ील्ड का मान ko.observable में लपेटा गया है। इस आवरण के माध्यम से, नॉकआउट मॉनिटर करता है कि फ़ील्ड मान कैसे बदलता है। यानी इसी इवेंट हैंडलर को वहां बुलाया जाता है। नुकसान, ज़ाहिर है, आपको एक विधि कॉल के माध्यम से हर जगह काम करना होगा, कोष्ठक लिखना होगा।

viewModel.currentCustomer = joeCoder;

* This source code was highlighted with Source Code Highlighter .

में बदल जाता है

viewModel.currentCustomer(joeCoder);

* This source code was highlighted with Source Code Highlighter .

आप इसकी आदत डाल सकते हैं, लेकिन कभी-कभी गटर में कोष्ठक भूल जाते हैं।

सदस्यता लेने के लिए, आपको निम्नलिखित लिखना होगा:

viewModel.currentCustomer.subscribe( function (newValue) {
// this === context <br>
}, context);

* This source code was highlighted with Source Code Highlighter .

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

ko.applyBindings(viewModel)

* This source code was highlighted with Source Code Highlighter .

इसलिए सतह पर, सब कुछ काफी सुलभ है - कोई जादू नहीं।

बेशक, अगर मामला केवल इस तक सीमित था, तो यह पहले से ही बहुत मीठा होगा। लेकिन अंकल सैंडरसन चले गए।

सबसे पहले, उन्होंने सरणियों को लपेटा: ko.observableArray। सच है, वह थोड़ा जानता है: पॉप, पुश, रिवर्स, शिफ्ट, सॉर्ट, स्प्लिस, अनशिफ्ट, स्लाइस, रिमूव, रिमूवल, इंडेक्सऑफ। यह काम के लिए काफी पर्याप्त है, लेकिन कुछ अंडरस्कोर तामझाम पर्याप्त नहीं हैं। बेशक, आप मान पढ़ सकते हैं - सरणी खुद - इसके साथ संचालन करने के लिए, और फिर इसे इसकी संपूर्णता में वापस लिखें। लेकिन यह बदसूरत निकला (क्यों, मैं आगे समझाऊंगा)। इसलिए, जो पहले से है, उससे चिपके रहना बेहतर है।

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

भरोसेमंद के साथ क्या किया जा सकता है? इसका मुख्य उद्देश्य तर्क को सरल बनाना है। अक्सर ऐसा होता है कि डेटा-बाइंड की एक कठिन स्थिति होती है। यह बहुत असुविधाजनक लग रहा है - मेरे HTML में जावास्क्रिप्ट !! 1। इस स्थिति का डीबग भी असुविधाजनक है - डिबगर विशेषता निकाय में नहीं जाएगा। इसलिए, निर्भरता के रूप में एक शर्त या इसके घटक बनाना आसान है और इसके साथ काम करना जारी रखें।

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

और क्या? JQuery-Tmpl टेम्पलेट्स के लिए समर्थन है। उस समय, यह उम्मीद की जा रही थी कि यह प्लगइन jQuery का हिस्सा बन जाएगा, हालांकि, डेवलपर्स की योजना बदल गई है। दूसरी ओर, Microsoft अब इसे या तो सक्रिय रूप से विकसित नहीं कर रहा है - एकमात्र डेवलपर अन्य परियोजनाओं पर चला गया है। इसलिए परियोजना थोड़ी स्थिर है - मेरा पूर्वानुमान: यह बीटा 1 राज्य में लगभग एक वर्ष तक रहेगा। फिर उन्हें या तो बाहर निकाल दिया जाएगा या दिमाग में लाया जाएगा।

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

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

मुझे यह ढांचा क्यों पसंद आया?

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

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

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

नॉकआउट बनाम आधार

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

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

नॉकआउट से पहले बैकबोन का मुख्य प्लस जो मैं व्यक्तिगत रूप से सिंक में देखता हूं वह सर्वर के साथ डेटा को सिंक्रनाइज़ करने की क्षमता है। हालाँकि, जब सर्वर API REST नियमों का पालन करता है, तब ही सिंक अच्छा काम करता है। कई लोग सोचते हैं, वे कहते हैं, महान, अब मैं इसे काम करूंगा। हालाँकि, वे इस तथ्य को नजरअंदाज करते हैं कि REST और JSON-over-HTTP एक ही बात नहीं है! यदि बैकबोन पहले एक के साथ बॉक्स से बाहर काम करता है - बस संसाधन का URL निर्दिष्ट करें - फिर दूसरे के साथ इसे दायर करने की आवश्यकता है। और फिर आप खुद से पूछते हैं: सिंक केवल $ .ajax को कॉल करने से बेहतर है?

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

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

यदि आप दो पुस्तकालयों की तुलना करने में रुचि रखते हैं, तो पदों की एक श्रृंखला है । यह एक साधारण परिदृश्य के लिए एक आवेदन का वर्णन करता है। लेकिन परिदृश्य अलग हैं :)

अभ्यास

चलो बेहतर है कि आपको उस रेक के बारे में बताएं जिस पर आपको कदम रखना है, और उन क्षणों के लिए जो कठिनाई पैदा करते हैं।

1. मॉडल से ViewModel का अंतर।

हर किसी को फर्क महसूस नहीं होता। एक सरल नियम:

• मॉडल प्रश्न का उत्तर देता है "मेरे आवेदन में क्या है और यह क्या कर सकता है?"
• ViewModel - प्रश्न "मैं पृष्ठ पर क्या दिखा रहा हूं?"

मैं ऐसा क्यों कर रहा हूं? और इस तथ्य से कि कई लोग मॉडल के रूप में ViewModel को देखना शुरू कर रहे हैं। यहां उनके पास कई सवाल हैं। उदाहरण के लिए: प्रस्तुतकर्ता में माल की सूची, हाइलाइट किए गए उत्पाद और चयनित उत्पाद के सूचकांक को इंगित किया जा सकता है। तुरंत कोई ऐसा व्यक्ति है जो कहता है कि चयनित उत्पाद और सूचकांक को संग्रहीत करना आवश्यक नहीं है - वे कहते हैं, डेटा डुप्लिकेट है। हालाँकि, मॉडल के विपरीत, यह हमारे लिए मायने नहीं रखता कि क्या ViewModel में कोई अतिरेक है। अगर यह हमें एप्लिकेशन कोड को सरल बनाने की अनुमति देता है, तो क्यों नहीं?

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

तो मेरी आपको सलाह: पूरे पृष्ठ के लिए एक ViewModel का उपयोग करें - सब कुछ बस काम करेगा। एक जोखिम है कि वस्तु बड़ी हो जाएगी, लेकिन कोई भी आपको कई बार कोड लिखने में परेशान नहीं करता है

_.extend(ViewModel, {
// <br>
})

* This source code was highlighted with Source Code Highlighter .

इस तरह के ब्लॉक मॉड्यूल में कार्यक्षमता को तोड़ा जा सकता है।

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

क्लाइंट पर एक मॉडल भी है, और आपको इसे पेन के साथ लिखना होगा - बैकबोन के विपरीत, नॉकआउट आपको इसमें मदद नहीं करेगा। दूसरी ओर, यह इतना डरावना नहीं है, और आपकी सामान्य समझ और स्वच्छता के सामान्य नियम आपकी मदद करेंगे। दो बातें याद रखें: घटनाओं और प्रतिरूपकता। यदि अजाक्स कोड आपके लिए एक समस्या बन जाता है, तो AmplifyJS की ओर देखें ।

3. दुर्भाग्य से, यहां तक ​​कि उन दुर्लभ मामलों में भी जब नॉकआउट हमें मॉडलिंग में मदद करना चाहता है, यह बहुत अच्छी तरह से काम नहीं करता है।

Ko.toJSON पद्धति यह नहीं जानती है कि तिथियों के साथ कैसे काम किया जाए , और उन्हें अशक्त लिखा जाए। इस के आसपास तरीके हैं, लेकिन वे सभी थोड़े अनाड़ी हैं। सबसे सरल है JSON.stringify (दिनांक ()) मान के साथ एक और भरोसेमंद संपत्ति को जोड़ना है - बस एक स्ट्रिंग होगी जो सर्वर को भेजी जा सकती है। लेकिन बदसूरत! - प्रत्येक तिथि के लिए दो फ़ील्ड, और मार्शलिंग केवल एक दिशा में काम करते हैं। इसलिए, हम दूसरे तरीके से गए: हमने सिर्फ ViewModel के लिए अपना स्वयं का क्रॉलर लिखा, जो ध्यान से तारीखों को संभालता है। सौभाग्य से, ko एक अप्रचलित विधि प्रदान करता है, जो एक साधारण वस्तु देता है। यह, हालांकि, शीर्ष स्तर पर ही काम करता है, इसलिए तब आपको परिणामी वस्तु के सभी गुणों को दरकिनार करना होगा, जब तक कि वेधशाला कहीं और न रहें।

4. टेम्प्लेटिंग के बावजूद, कभी-कभी आपको अन्य तरीकों का उपयोग करके एक डोम बनाना पड़ता है।

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

items.pop()

* This source code was highlighted with Source Code Highlighter .

लेकिन हम चाहेंगे कि यह वहीं हो

items().pop()

* This source code was highlighted with Source Code Highlighter .

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

5. नॉकआउट पारंपरिक व्यवसाय परिदृश्यों में बहुत अच्छी तरह से काम करता है।

प्रपत्र, डेटा आउटपुट, टेबल - यदि यह ठीक है कि आपका आवेदन क्या करता है, तो यह आपको 100% सूट करेगा।

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

नॉकआउट और बैकबोन

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

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

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

बैकबोन भी, कहीं भी नहीं जा रहा है, रूबीवादियों, NodeJS प्रोग्रामर और जावास्क्रिप्ट समुदाय के पूरे एवांट-गार्ड के बीच इसमें बहुत रुचि है। तो उनमें से किसी को चुनना आप सुनिश्चित कर सकते हैं - आप नहीं खोएंगे!