🅾️ 💭 👨🏽‍⚕️ रज्जु। इसे घोषित रूप से करने की कोशिश की जा रही है 🙏🏿 🔛 🦔

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

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

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

थोड़ा सा इतिहास

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

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

लेकिन यहां, खुशी नहीं हुई। संभवतः सबसे अच्छी स्थिति मेरे सहकर्मी की राय को प्रतिबिंबित करेगी, जो निर्मित पुस्तकालय का उपयोग करना था। उन्होंने दस्तावेज़ीकरण में उदाहरणों को देखा, और कहा: "पुस्तकालय शांत है। सुंदर, गतिशील है। लेकिन अब मैं इस सब से एक आवेदन कैसे कर सकता हूं?" और वह सही था। यह पता चला कि एक घटक बनाना कई घटकों को एक साथ संयोजित करने और उन्हें मूल रूप से काम करने के समान नहीं है।

तब से काफी समय बीत चुका है। और जब एक बार फिर मुझे विचारों और विचारों को एक साथ लाने की इच्छा से दौरा किया गया, तो मैंने थोड़ा अलग करने का फैसला किया और नीचे से ऊपर तक नहीं, बल्कि ऊपर से नीचे तक गया।

आवेदन प्रबंधन == राज्य प्रबंधन

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

एक स्पष्ट समस्या है - मॉडल के कई मूल्यों के लिए, दस्तावेज़ के लिए कई विकल्पों का वर्णन करना आवश्यक है। दो दृष्टिकोण आमतौर पर यहां उपयोग किए जाते हैं:

टेम्पलेट्स। हम अपनी पसंदीदा मार्कअप भाषा का उपयोग करते हैं और इसे ब्रांचिंग और लूपिंग निर्देशों के साथ पूरक करते हैं।
समारोह। हम अपने कार्यों में हमारी शाखाओं और हमारी पसंदीदा प्रोग्रामिंग भाषा में छोरों का वर्णन करते हैं।

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

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

createFromConfig({ data: { name: 'Alice' }, tag: 'div', class: 'clickable box', onClick: function () { alert('Click') } })

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

आवेदन संरचना और विकृति

शब्द "घटक" बहुत अस्पष्ट हो गया है, विशेष रूप से तथाकथित की उपस्थिति के बाद कार्यात्मक घटक। जैसा कि हम आवेदन की संरचना पर जाते हैं, मैं घटक को एक संरचनात्मक तत्व कहूंगा।

बहुत जल्दी, मैं इस नतीजे पर पहुंचा कि संरचनात्मक तत्व (घटक) कोई दस्तावेज तत्व नहीं है, बल्कि कुछ इकाई है, जो:

डेटा और दस्तावेज़ (बंधन और घटनाओं) को जोड़ती है
अन्य समान संस्थाओं (वृक्ष संरचना) से जुड़े

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

प्रबंधन द्वारा, मैं परिवर्तनशीलता और चक्रीयता की उपस्थिति को समझता हूं।

भिन्नता (यदि-अन्य)

आइए देखें कि चोरदा में कार्ड घटक के उदाहरण का उपयोग करके आप प्रदर्शन विकल्पों को कैसे नियंत्रित कर सकते हैं:

 const isHeaderOnly = true const card = new Html({ $header: { /*  */ }, $footer: { /*  */ }, components: {header: true, footer: !isHeaderOnly} //    })

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

चक्र (के लिए)

डेटा के साथ काम करना जिसकी मात्रा केवल रनटाइम पर जानी जाती है, उसे सूचियों पर पुनरावृत्ति की आवश्यकता होगी।

 const drinks = ['Coffee', 'Tea', 'Milk'] const html = new Html({ html: 'ul', css: 'list', defaultItem: { html: 'li', css: 'list-item' }, items: drinks })

आइटम विकल्प का मूल्य क्रमशः ऐरे है, हमें घटकों का एक क्रमबद्ध सेट मिलता है। भंडारण के लिए वस्तुओं को बाँधना, जैसे कि घटकों के मामले में , डेटा पर नियंत्रण स्थानांतरित करेगा।

पेड़ के पदानुक्रम में संरचनात्मक तत्व एक दूसरे से जुड़े होते हैं। यदि हम पिछले उदाहरणों को जोड़ते हैं, तो कार्ड के शरीर में सूची को प्रदर्शित करने के लिए हमें निम्नलिखित मिलते हैं:

 //   const state = { struct: { header: true, footer: false, }, drinks: ['Coffee', 'Tea', 'Milk'] } //  const card = new Html({ $header: { /*  */ }, $content: { html: 'ul', css: 'list', defaultItem: { html: 'li', css: 'list-item' }, items: state.drinks }, $footer: { /*  */ }, components: state.struct })

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

जब हमारे लिए सब कुछ पहले से ही ईजाद हो चुका होता है

सामान्य तौर पर, मैं इस तथ्य के पक्ष में हूं कि दस्तावेज़ रेंडरिंग सिस्टम को ब्राउज़र स्तर पर लागू किया जाना चाहिए (यद्यपि कम से कम एक ही VDOM)। और हमारा काम केवल इसे ध्यान से घटक पेड़ से जोड़ना होगा। आखिरकार, लाइब्रेरी की गति चाहे कितनी भी बढ़ जाए, ब्राउज़र के पास वैसे भी अधिक होता है।

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

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

VDOM को संरचनात्मक तत्वों से जोड़ने के लिए, आपको लेआउट जैसी चीज़ की आवश्यकता होती है। इसे एक संरचनात्मक तत्व का दस्तावेज़ फ़ंक्शन कहा जा सकता है। जो महत्वपूर्ण है वह एक शुद्ध कार्य है।

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

 function orderedByKeyLayout (h, type, props, components) { return h(type, props, components.sort((a, b) => a.key - b.key).map(c => c.render())) } const html = new Html({ $header: {}, $content: {}, $footer: {}, layout: orderedByKeyLayout //     })

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

प्रतिक्रिया की चुटकी

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

डेटा के साथ काम करते समय, मुझे दो चीजें पसंद नहीं थीं:

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

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

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

घटक पेड़ पर प्रासंगिक डेटा कैसे वितरित किया जाता है, इसका एक उदाहरण:

 const html = new Html({ //     scope: { drink: 'Coffee' }, $component1: { scope: { cups: 2 }, $content: { $myDrink: { //      ,    drinkChanged: function (v) { //    drink   text this.opt('text', v) } }, $numCups: { cupsChanged: function (v) { this.opt('text', v + ' cups') } } } }, $component2: { scope: { drink: 'Tea' //      drink }, drinkChanged: function (v) { //    drink   text this.opt('text', v) } } }) //    // <div> // <div> // <div> // <div>Coffee</div> // <div>2 cups</div> // </div> // </div> // <div>Tea</div> // </div>

समझने में सबसे कठिन क्षण यह है कि प्रत्येक घटक का अपना संदर्भ है, और संरचना के शीर्ष पर घोषित नहीं है, जैसा कि हम आमतौर पर टेम्पलेट्स के साथ काम करते समय करते हैं।

ओवरलोड के विकल्पों के बारे में क्या?

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

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

आइए देखें कि कॉर्डा में विन्यास के साथ कक्षाएं कैसे काम करती हैं।

 //      class Card extends Html { config () { return { css: 'box', $header: {}, $content: {}, $footer: {} } } } const html = new Html({ css: 'panel', $card: { as: Card, $header: { //       title $title: { css: 'title', text: 'Card title' } } } })

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

Chorda में, एक वर्ग अनिवार्य रूप से विन्यास के लिए एक कंटेनर है और एक विशेष प्रकार की अशुद्धता की भूमिका निभाता है।

एक और ढांचा क्यों?

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

फिलहाल, चोरदा सक्रिय विकास में है। मुख्य दिशाएं पहले से ही दिखाई दे रही हैं, लेकिन विवरण लगातार बदल रहे हैं।

अंत तक पढ़ने के लिए धन्यवाद। मुझे समीक्षा करने में खुशी होगी।