‼️ 😜 🧜🏻 आधुनिक फ्रंट एंड आर्किटेक्चर (भाग 2) ⚡️ 🌀 👆🏼

लेख " समकालीन फ्रंट-एंड आर्किटेक्चर " का दूसरा भाग , जो डेटा धाराओं के वितरण के संदर्भ में सामने के छोर की वास्तुकला पर चर्चा करता है। यहां से शुरू करें

कार्यान्वयन

DOM (DOM-infused एल्गोरिदम) द्वारा उत्पन्न एल्गोरिदम

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

मुझे नहीं लगता कि यह जानबूझकर था, लेकिन jQuery ने DOM API को इस हद तक सरल कर दिया है कि इसे सामान्य प्रोग्रामिंग लैंग्वेज API से अलग करना मुश्किल था। यह, बदले में, डेवलपर्स को व्यापार तर्क ( मॉडल ) के साथ डोम एपीआई स्तर ( दृश्य ) को शाब्दिक रूप से मिश्रण करने की अनुमति देता है ।

एक बार फिर, हम अभी भी उसी सर्वर-साइड MVC के संदर्भ में हैं। यह सिर्फ एक सीक्वल है। नियंत्रण का कोई वास्तविक उलटा नहीं है। दृश्य / पृष्ठों पर सामान्य नियंत्रण अभी भी सर्वर-साइड कोड द्वारा निर्धारित किया जाता है।

ऊपर दिए गए कोड स्निपेट में, मॉडल, प्रस्तुति और प्रस्तुतकर्ता / नियंत्रक किसी तरह से एक अखंड कोड संरचना में संयुक्त होते हैं। यह वह स्थिति है जब मॉडल में केवल एक संपत्ति होती है। एक सर्वर ब्राउज़ चक्र (एसपीए की तरह) के बिना एक वेब एप्लिकेशन बनाने की कोशिश करने की कल्पना करें। किसी भी सुविधाजनक तरीके से यह सब संभालना असंभव होगा। DOM के साथ बातचीत करने का कोड बाकी एप्लिकेशन लॉजिक द्वारा दर्ज किया गया है, और इसलिए इसे DOM-infused एल्गोरिथ्म के रूप में जाना जाता है (मुझे यकीन नहीं है कि आधिकारिक तौर पर ऐसा कोई शब्द है)

Backbone.js - MV *

जैसा कि हमने देखा है, jQuery में, जब अनुप्रयोग विकसित होते हैं, तो हमारे कोड को संरचना और व्यवस्थित करने का तरीका स्पष्ट रूप से अनुपस्थित है। यह वह जगह है जहाँ Backbone.js अगले विकासवादी समाधान के रूप में दिखाई दिया। यह क्लाइंट-साइड एमवीसी शैली के लाभों को लाने वाले पहले पुस्तकालयों में से एक था।

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

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

, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

इस तरह एमवी * या मॉडल-व्यू-जो भी ("जो भी") पैदा होता है। एक विस्तृत चर्चा के लिए, यह दृढ़ता से अनुशंसा की जाती है कि आप Addi Osmani के ब्लॉग को देखें।

पिछले jQuery की तुलना में, Backbone ने अधिक संरचित कोड बनाने में मदद की।

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

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

नॉकआउट.जेएस - फ्रंट एंड के लिए डेटा बाइंडिंग

Knockout.js बुनियादी टेम्पलेट्स का उपयोग करने का हमारा नवीनतम उदाहरण है। इसका उद्देश्य जावास्क्रिप्ट के लिए MVVM - Model-View-ViewModel को लागू करना है। और इसलिए यह है। हालांकि बैकबोन ने संगठन और कोड संरचना की समस्या से निपटा है, नॉकआउट डिक्लेरेटिव डेटा बाइंडिंग का उपयोग करके दृश्य परत का एक कुशल कार्यान्वयन है । घोषणात्मक बाइंडिंग के लाभ किसी भी घोषित प्रोग्रामिंग निर्माणों के समान हैं:

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

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

यह अक्सर माना जाता है कि मॉडल के साथ, नॉकआउट सर्वर की तरफ है। ViewModel केवल Ajax या इसके समकक्ष का उपयोग करके सर्वर-साइड मॉडल का अनुरोध करता है।

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

यहां से शुरू होता है एंगुलर 1, ऑरेलिया, एम्बर.जेएस आदि का क्रांतिकारी आंदोलन।

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

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

कोणीय 1 - मुझे नियंत्रण दें

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

यह तब था और अब सही जावास्क्रिप्ट पुस्तकालयों को चुनने और सामने वाले के लिए सही तकनीक स्टैक बनाने के लिए एक मुश्किल काम बना हुआ है। कोणीय 1 बस एक सरल लेकिन अधिक सामंजस्यपूर्ण विकल्प प्रदान किया। ऐसा ही Ember.js और अन्य समान प्रणालियों के बारे में कहा जा सकता है, लेकिन Angular 1 की प्रयोज्यता उस समय के अपने विकल्पों की तुलना में एक अलग गुणात्मक स्तर पर थी।

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

फ्रेमवर्क या लाइब्रेरी?

पिछले समाधान एक ढांचे की तुलना में अधिक पुस्तकालय थे। कोणीय 1 एक शक के बिना एक अच्छी तरह से परिभाषित संरचना है। प्लेटफ़ॉर्म और लाइब्रेरी के बीच एक आवश्यक विशिष्ट कारक IOC है - इनवर्टर ऑफ़ कंट्रोल। इसके अलावा, एक ढांचे के रूप में कोणीय 1 को योग्य बनाने के लिए, हम नोट कर सकते हैं:

अच्छी तरह से परिभाषित MVVMs: कोणीय 1 में स्पष्ट मॉडल, दृश्य और ViewModel ऑब्जेक्ट हैं।
(DI): Angular 1 DI, Model. Angular 1 (Service). , .
(data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
मॉड्यूलर प्रणाली: कोणीय 1 एक विशिष्ट ढांचा प्रणाली का परिचय देता है। मॉड्यूल लगभग हर भाषा के लिए कोड के आयोजन का आधार है। जावास्क्रिप्ट में 2015 तक एक मॉड्यूलर प्रणाली नहीं थी (2018 तक ब्राउज़रों ने इसका समर्थन नहीं किया)। संगठन के मामले में कोणीय अपने समय से बहुत आगे है।

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

नेमस्पेस टकराहट: हालांकि डीआई महान था, यह सेवा लोकेटर पैटर्न का उपयोग करके लागू किया गया था जो वैश्विक नामस्थान का उपयोग करता था। इससे सेवाओं का उपसर्ग लगभग अनिवार्य हो गया।
. , , , . React . -, .
. , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

कई अन्य छोटे मुद्दे थे। एंगुलर 2, या सिर्फ एंगुलर, इस हद तक एक पूरी सफलता थी कि यह बिल्कुल नए ढांचे की तरह दिखता था। मुझे उनके बीच कुछ भी सामान्य नहीं लगता, सिवाय नाम और कुछ अवधारणाओं के।

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

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