वेब यूआई वास्तुकला: एक लकड़ी के अतीत, एक अजीब वर्तमान, और एक उज्ज्वल भविष्य

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

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

कम से कम किसी तरह से वर्तमान स्थिति को प्रभावित करने के लिए, आज मैं आपको बताना चाहता हूं कि एक अच्छा आर्किटेक्चर क्या है, यह वेब इंटरफेस पर कैसे लागू होता है, और सबसे महत्वपूर्ण बात यह है कि यह समय के साथ कैसे विकसित होता है।

एनबी : लेख में उदाहरण के रूप में, केवल उन रूपरेखाओं के बारे में जिन्हें लेखक ने सीधे तौर पर निपटाया है, और यहां प्रतिक्रिया और Redux पर महत्वपूर्ण ध्यान दिया जाएगा। लेकिन, इसके बावजूद, यहां वर्णित विचारों और सिद्धांतों में से कई प्रकृति में सामान्य हैं और अन्य इंटरफ़ेस विकास प्रौद्योगिकियों पर कम या ज्यादा सफलतापूर्वक अनुमान लगाया जा सकता है।

डमियों के लिए वास्तुकला

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

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

वास्तुकला की गुणवत्ता के लिए, यह आमतौर पर निम्नलिखित गुणों में व्यक्त किया जाता है:

- सम्पूर्णता : अध्ययन और संशोधन के लिए प्रणाली का पहले से उल्लेखित पूर्वसूचना (त्रुटियों का पता लगाने और सही करने की कठिनाई, कार्यक्षमता का विस्तार करना, दूसरे वातावरण या परिस्थितियों के समाधान को अपनाना)
- पुनरावृत्ति : अन्य तत्वों को प्रभावित किए बिना सिस्टम के किसी भी तत्व के कार्यान्वयन को बदलने की क्षमता
- परीक्षणशीलता : तत्व के सही संचालन को सत्यापित करने की क्षमता (तत्व को नियंत्रित करने और अपनी स्थिति का निरीक्षण करने की क्षमता)
- पोर्टेबिलिटी : अन्य प्रणालियों में एक तत्व का पुन: उपयोग करने की क्षमता
- प्रयोज्यता : अंतिम उपयोगकर्ता द्वारा संचालित होने पर सिस्टम की सुविधा की समग्र डिग्री

गुणवत्ता वास्तुकला के निर्माण के प्रमुख सिद्धांतों में से एक का अलग उल्लेख भी है: चिंताओं के पृथक्करण का सिद्धांत। यह इस तथ्य में शामिल है कि सिस्टम का कोई भी तत्व केवल एक ही कार्य के लिए जिम्मेदार होना चाहिए (आवेदन कोड के लिए संयोगवश, एकल जिम्मेदारी सिद्धांत देखें)।

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

तीन सबसे महत्वपूर्ण शब्द

इंटरफ़ेस विकास के सबसे प्रसिद्ध पैटर्न में से एक MVC (मॉडल-व्यू-कंट्रोलर) है, जिसकी मुख्य अवधारणा इंटरफ़ेस लॉजिक को तीन अलग-अलग भागों में विभाजित करना है:

1. मॉडल - डेटा प्राप्त करने, भंडारण और प्रसंस्करण के लिए जिम्मेदार है
2. दृश्य - डेटा विज़ुअलाइज़ेशन के लिए जिम्मेदार
3. नियंत्रक - मॉडल और दृश्य को नियंत्रित करता है

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



चूंकि हम विशेष रूप से वेब इंटरफेस के बारे में बात कर रहे हैं, इसलिए हमने एक और बल्कि महत्वपूर्ण तत्व का उपयोग किया है जो आमतौर पर इन पैटर्नों के कार्यान्वयन में साथ होता है - एक राउटर। इसका कार्य URL को पढ़ना और इससे जुड़े प्रेजेंटर्स को कॉल करना है।

उपरोक्त योजना निम्नानुसार काम करती है:

1. राउटर यूआरएल को पढ़ता है और संबंधित प्रस्तुतकर्ता को कॉल करता है
2-5। प्रस्तुतकर्ता मॉडल में बदल जाता है और उससे आवश्यक डेटा प्राप्त करता है।
6. प्रस्तुतकर्ता मॉडल से दृश्य में डेटा स्थानांतरित करता है, जो इसके दृश्य को लागू करता है।
7. इंटरफेस के साथ उपयोगकर्ता की बातचीत के दौरान, व्यू इस बारे में प्रस्तोता को सूचित करता है, जो हमें दूसरे बिंदु पर लौटाता है

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

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

MVC और सर्वर रेंडरिंग

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

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

- राउटर प्राप्त HTTP अनुरोध (GET / उपयोगकर्ता-प्रोफ़ाइल / 1) से डेटा पढ़ता है और संबंधित नियंत्रक (UsersController.getProfilePage (1)) को कॉल करता है
- नियंत्रक डेटाबेस से आवश्यक जानकारी प्राप्त करने के लिए मॉडल को कॉल करता है (UsersModel.get (1))
- नियंत्रक प्राप्त डेटा को View (View.render ('उपयोगकर्ता / प्रोफ़ाइल', उपयोगकर्ता)) पास करता है और उससे HTML मार्कअप प्राप्त करता है, जो इसे क्लाइंट को वापस भेज देता है

इस मामले में, दृश्य आमतौर पर इस प्रकार लागू किया जाता है:

const templates = { 'users/profile': ` <div class="user-profile"> <h2>{{ name}}</h2> <p>E-mail: {{ email }}</p> <p> Projects: {{#each projects}} <a href="/projects/{{id}}">{{name}}</a> {{/each}} </p> <a href=/user-profile/1/edit>Edit</a> </div> ` }; class View { render(templateName, data) { const htmlMarkup = TemplateEngine.render(templates[templateName], data); return htmlMarkup; } } 

NB: उपरोक्त कोड एक उदाहरण के रूप में उपयोग के लिए जानबूझकर सरल है। वास्तविक परियोजनाओं में, टेम्पलेट्स को अलग-अलग फ़ाइलों को निर्यात किया जाता है और उपयोग से पहले संकलन चरण से गुजरता है (देखें Handlebars.compile () या _.template () )।

यहां तथाकथित टेम्पलेट इंजन का उपयोग किया जाता है, जो हमें वास्तविक डेटा को प्रतिस्थापित करने के लिए टेक्स्ट टेम्प्लेट और तंत्र के सुविधाजनक विवरण के लिए उपकरण प्रदान करता है।

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

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

सर्वर उपकरण का उपयोग करके HTML मार्कअप की पीढ़ी के साथ दृष्टिकोण के लिए, कम UX के कारण, इस दृष्टिकोण को धीरे-धीरे एसपीए द्वारा प्रतिस्थापित किया जाने लगा।

बैकबोन और एमवीपी

क्लाइंट के लिए डिस्प्ले लॉजिक को पूरी तरह से लाने वाले पहले फ्रेमवर्क में से एक Backbone.js था। इसमें राउटर, प्रस्तुतकर्ता और मॉडल का कार्यान्वयन काफी मानक है, लेकिन दृश्य का नया कार्यान्वयन हमारे ध्यान के योग्य है:

 const UserProfile = Backbone.View.extend({ tagName: 'div', className: 'user-profile', events: { 'click .button.edit': 'openEditDialog', }, openEditDialog: function(event) { // ... }, initialize: function() { this.listenTo(this.model, 'change', this.render); }, template: _.template(` <h2><%= name %></h2> <p>E-mail: <%= email %></p> <p> Projects: <% _.each(projects, project => { %> <a href="/projects/<%= project.id %>"><%= project.name %></a> <% }) %> </p> <button class="edit">Edit</button> `), render: function() { this.$el.html(this.template(this.model.attributes)); } }); 

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

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

और नए दृश्य कार्यान्वयन के साथ समस्याएं समाप्त नहीं हुईं:

उपरोक्त के अलावा, एक दूसरे के दृश्य में नेस्टेड का उपयोग करना मुश्किल है। समय के साथ, Marionette.js में रीजन की मदद से इस समस्या को हल कर दिया गया, लेकिन इससे पहले, डेवलपर्स को इस सरल और अक्सर उत्पन्न होने वाली समस्या को हल करने के लिए अपने स्वयं के ट्रिक्स का आविष्कार करना पड़ा।

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

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

प्रतिक्रिया और शून्य

यह विश्वास करना कठिन है, लेकिन इसकी प्रारंभिक रिलीज के समय, React.js ने डेवलपर समुदाय के बीच बहुत संदेह पैदा किया। यह संदेह इतना बड़ा था कि लंबे समय तक आधिकारिक वेबसाइट पर निम्न पाठ पोस्ट किया गया था:

इसे पाँच मिनट दें
रिएक्ट बहुत सारे पारंपरिक ज्ञान को चुनौती देता है, और पहली नज़र में कुछ विचार पागल हो सकते हैं।

और इस तथ्य के बावजूद कि, अपने अधिकांश प्रतिद्वंद्वियों और पूर्ववर्तियों के विपरीत, रिएक्ट एक पूर्णरूपेण ढांचा नहीं था और डोम में डेटा के प्रदर्शन को सुविधाजनक बनाने के लिए सिर्फ एक छोटा पुस्तकालय था:

प्रतिक्रिया फेसबुक और इंस्टाग्राम द्वारा उपयोगकर्ता इंटरफेस बनाने के लिए एक जावास्क्रिप्ट पुस्तकालय है। कई लोग एमवीसी में वी के रूप में रिएक्ट के बारे में सोचना चुनते हैं।

मुख्य अवधारणा जो हमें प्रतिक्रिया प्रदान करती है वह एक घटक की अवधारणा है, जो वास्तव में, हमें दृश्य को लागू करने के लिए एक नया तरीका प्रदान करती है:

 class User extends React.Component { handleEdit() { // .. } render() { const { name, email, projects } = this.props; return ( <div className="user-profile"> <h2>{name}</h2> <p>E-mail: {email}</p> <p> Projects: { projects.map(project => <a href="/projects/{project.id}">{project.name}</a>) } </p> <button onClick={this.handleEdit}>Edit</button> </div> ); } } 

प्रतिक्रिया का उपयोग करने के लिए अविश्वसनीय रूप से सुखद था। इसके निर्विवाद रूप से लाभ आज तक बने हुए हैं:

1) घोषणा और प्रतिक्रिया । प्रदर्शित डेटा को बदलते समय DOM को मैन्युअल रूप से अपडेट करने की कोई आवश्यकता नहीं है।

2) घटकों की संरचना । व्यू ट्री का निर्माण और खोज पूरी तरह से बुनियादी कार्रवाई बन गई है।

लेकिन, दुर्भाग्य से, रिएक्ट में कई समस्याएं हैं। सबसे महत्वपूर्ण में से एक तथ्य यह है कि रिएक्ट एक पूर्णरूपेण ढांचा नहीं है और इसलिए, इसके कार्यान्वयन के लिए हमें किसी भी तरह की एप्लिकेशन वास्तुकला या पूर्ण-उपकरण प्रदान नहीं करता है।

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

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

यदि आपके पास एकमात्र उपकरण एक हथौड़ा है, तो सब कुछ नाखून की तरह दिखाई देने लगता है।

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

प्रतिक्रिया और Redux

रिएक्ट अनुप्रयोगों की संरचना में ऑर्डर को बहाल करना Redux की उपस्थिति और लोकप्रियकरण से बहुत सुविधाजनक था। यदि रिएक्ट एमवीपी से एक दृश्य है, तो रेडक्स ने हमें मॉडल की काफी सुविधाजनक विविधता की पेशकश की।

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

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

प्रतिक्रिया / Redux का उपयोग करते हुए आवेदन की सामान्य योजना निम्नानुसार दर्शाई जा सकती है:



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

जब कोई उपयोगकर्ता इंटरफ़ेस में एक क्रिया करता है, तो घटक बस संबंधित हैंडलर फ़ंक्शन को कॉल करता है, जो इसे प्रदर्शन के डेटा के साथ बाहर से प्राप्त होता है।

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

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

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

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

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

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

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

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

 const getModelReducer = modelName => (models = [], action) => { const isModelAction = modelActionTypes.includes(action.type); if (isModelAction && action.modelName === modelName) { switch (action.type) { case 'ADD_MODELS': return collection.add(action.models, models); case 'CHANGE_MODEL': return collection.change(action.model, models); case 'REMOVE_MODEL': return collection.remove(action.model, models); case 'RESET_STATE': return []; } } return models; }; 

खैर, एक और बात है कि मैं Redux का उपयोग करने के संदर्भ में चर्चा करना चाहूंगा कि दुष्प्रभाव का कार्यान्वयन क्या है।

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

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

 { type: 'CREATE_MODEL', payload: { model: 'reviews', attributes: { title: '...', text: '...' } } } 

... और उन पर सामान्यीकृत HTTP अनुरोध बनाना:

 POST /api/reviews { title: '...', text: '...' } 

उपरोक्त सभी युक्तियों का होशपूर्वक पालन करके, आप प्राप्त कर सकते हैं, यदि एक आदर्श वास्तुकला नहीं है, तो कम से कम इसके करीब।

उज्जवल भविष्य

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

यदि आप भविष्य में देखने की कोशिश करते हैं, तो सबसे अधिक संभावना है कि हम निम्नलिखित देखेंगे:

1. जेएसएक्स के बिना घटक दृष्टिकोण

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

2. Redux के बिना राज्य कंटेनर

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

3. लाइब्रेरी इंटरचेंजबिलिटी को बढ़ाना

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

यह सब क्यों?

यदि हम ऊपर प्रस्तुत जानकारी को सामान्य बनाने और इसे सरल और छोटे रूप में कम करने का प्रयास करते हैं, तो हमें कुछ सामान्य बिंदु मिलते हैं:

- सफल अनुप्रयोग विकास के लिए, भाषा का ज्ञान और रूपरेखा पर्याप्त नहीं है, सामान्य सैद्धांतिक चीजों पर ध्यान दिया जाना चाहिए: आवेदन वास्तुकला, सर्वोत्तम अभ्यास और डिजाइन पैटर्न।

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

और शायद यही सब मेरे लिए है। उन सभी को बहुत धन्यवाद जिन्होंने लेख को अंत तक पढ़ने की ताकत पाई। यदि आपके कोई प्रश्न या टिप्पणी हैं, तो मैं आपको टिप्पणी करने के लिए आमंत्रित करता हूं।