🧖🏽 👼🏻 👨‍🎨 जेएस फ्रेमवर्क चुनने के नियम 💰 👩🏿‍🤝‍👨🏻 🉐

टीएल, डॉ

यह लेख TOP-3 सूची से JS चौखटे पर चर्चा नहीं करता है।
जब एक गैर-टॉप -3 जेएस फ्रेमवर्क पर विकसित हो रहा है, तो आपको विकास की शुरुआत में उम्मीद से अधिक तकनीकी मुद्दों के परिमाण को हल करना होगा
कहानी वास्तविक घटनाओं पर आधारित है।

कहानी एक मिनी-प्रोजेक्ट के साथ शुरू हुई, जिसे मूल रूप से बैकबोन.जेएस और मैरियनेट.जेएस लाइब्रेरी के आधार पर विकसित किया गया था। ये, निश्चित रूप से, महान पुस्तकालय हैं, जिन्होंने एकल-पृष्ठ अनुप्रयोगों के विकास का इतिहास शुरू किया है। लेकिन पहले से ही उस समय वे व्यावहारिक मूल्य की तुलना में ऐतिहासिक होने की अधिक संभावना रखते थे। मैं केवल इस तथ्य का उल्लेख कर रहा हूं कि एक सरल तालिका प्रदर्शित करने के लिए इसे बनाना आवश्यक था: 1) मॉडल के विवरण के साथ एक मॉड्यूल, 2) संग्रह के विवरण के साथ एक मॉड्यूल, 3) एक दृश्य मॉडल की परिभाषा के साथ एक मॉड्यूल, 4) एक दृश्य संग्रह की परिभाषा के साथ एक मॉड्यूल, 4) एक तालिका पंक्ति टेम्पलेट। 5) टेबल टेम्पलेट; 6) नियंत्रक मॉड्यूल। एक छोटे से अनुप्रयोग में लगभग 10 इकाइयाँ होना - बहुत प्रारंभिक चरण में आपके पास पहले से ही पचास से अधिक छोटे मॉड्यूल थे। और यह सिर्फ शुरुआत है। लेकिन अब उस बारे में नहीं है।

कुछ बिंदु पर, आवेदन के छह महीने बाद, यह अभी भी खोज परिणामों में दिखाई नहीं दिया। परियोजना में prerender.io को जोड़ना (जो तब phantom.js इंजन का उपयोग करता था) ने मदद की, लेकिन अपेक्षा के अनुरूप नहीं। बादलों ने आवेदन और मेरे ऊपर इकट्ठा करना शुरू कर दिया, जिसके बाद मुझे एहसास हुआ कि मुझे आज बहुत जल्दी और कुशलता से कुछ करने की जरूरत है। मैंने जो लक्ष्य निर्धारित किया वह था: सर्वर रेंडरिंग पर स्विच करना। Backbone.js और marionettejs के साथ, यह लगभग असंभव है। किसी भी स्थिति में, बैकबोन.जेएस पर रेंडर प्रोजेक्ट, जिसे स्पाइक बीरेम (आइसोमॉर्फिक / सार्वभौमिक अनुप्रयोगों के विचार के लेखक) के निर्देशन में विकसित किया गया था, ने 2015 में 58 योगदानकर्ताओं और 4,184 लाइक्स को इकट्ठा किया, जिसे githin.com पर रोका गया था, और स्पष्ट रूप से एक दिन के ब्लिट्ज के लिए अभिप्रेत नहीं था। । मैंने विकल्प की तलाश शुरू कर दी। मैंने टॉप -3 जेएस फ्रेमवर्क को तुरंत विचार से बाहर कर दिया, क्योंकि मेरे पास उनके विकास के लिए समय नहीं था। एक छोटी खोज के बाद, मुझे तेजी से बढ़ते हुए जेएस फ्रेमवर्क दंगा.जेएस github.com/riot/riot मिला , जिसकी वर्तमान में github.com पर 13,704 लाइक्स हैं, और, जैसा कि मुझे उम्मीद थी, यह अच्छी तरह से पहले तक पहुंच सकता है स्थिति (जो, हालांकि, ऐसा नहीं हुआ)।

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

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

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

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

रूटिंग में निम्नलिखित समस्या थी। दंगा में चोट मारना। Js बॉक्स से लगभग बाहर आता है github.com/riot/route - कम से कम एक ही डेवलपर से। इससे उन्हें परेशानी से मुक्त ऑपरेशन की उम्मीद थी। लेकिन कुछ बिंदु पर मैंने देखा कि कुछ पृष्ठ अप्रत्याशित रूप से अतिभारित हैं। यही है, एक बार एक नए मार्ग पर संक्रमण एकल-पृष्ठ एप्लिकेशन मोड में हो सकता है, और दूसरी बार उसी संक्रमण ने संपूर्ण HTML दस्तावेज़ को ओवरलोड कर दिया, जैसा कि एक क्लासिक वेब एप्लिकेशन के साथ काम करते समय होता है। इस मामले में, निश्चित रूप से, आंतरिक स्थिति खो गई थी अगर इसे अभी तक सर्वर पर सहेजा नहीं गया था। (वर्तमान में, इस पुस्तकालय का विकास रोक दिया गया है और इसका उपयोग दंगा के साथ नहीं किया जाता है। 4.0)

सिस्टम का एकमात्र घटक जो अपेक्षित रूप से काम करता था, वह न्यूनतम प्रवाह जैसा राज्य प्रबंधक github.com/jimsparkman/RiotControl था । सच है, इस घटक के साथ काम करने के लिए, राज्य परिवर्तनों के श्रोताओं को नियुक्त करना और रद्द करना आवश्यक था, जितना हम चाहते हैं।

इस लेख का प्रारंभिक विचार यह था: दंगा.जेएस ढांचे के साथ अपने स्वयं के अनुभव के उदाहरण से, उन कार्यों को, जिन्हें डेवलपर को हल करना होगा, जिन्होंने निर्णय लिया (निर्णय लिया) जेएस फ्रेमवर्क पर एक आवेदन विकसित करने के लिए टॉप -3 सूची से नहीं। हालाँकि, तैयारी की प्रक्रिया में, मैंने अपनी स्मृति में दंगा.जज दस्तावेज से कुछ पेजों को रिफ्रेश करने का फैसला किया, और इसलिए मैंने सीखा कि दंगा.जस 4.0 का एक नया संस्करण जारी किया गया था, जो पूरी तरह से (खरोंच से) फिर से डिजाइन किया गया था, जो दंगा डेवलपर के लेख में पाया जा सकता है। js on medium.com: medium.com/@gianluca.guarini/every-revolution-begins-with-a-riot-js-first-6c6a4b090ee इस लेख से मुझे पता चला कि सभी मुख्य समस्याएं जो मुझे चिंतित करती थीं, और जिनसे मैं इस लेख में बात करने जा रहा था, उन्हें समाप्त कर दिया गया है। विशेष रूप से, riot.js संस्करण 4.0 में:

कंपाइलर पूरी तरह से फिर से लिखा गया है (या यों कहें, यह पहली बार लिखा गया था क्योंकि इंजन पहले नियमित भावों पर काम करता था) - यह प्रभावित हुआ, विशेष रूप से, त्रुटि संदेशों की सूचना सामग्री
सर्वर रेंडरिंग के अलावा, हाइड्रेट क्लाइंट पर जोड़ा गया था - यह आखिरकार हमें डबल रेंडरिंग के बिना सार्वभौमिक अनुप्रयोग लिखना शुरू करने की अनुमति देता है (सर्वर पर पहली बार और क्लाइंट पर हाइड्रेट की कमी के कारण वहीं) पुराने संस्करणों में कार्य करता है।
हॉट ओवरलोडिंग घटकों के लिए अतिरिक्त प्लगइन github.com/riot/hot-reload
और कई अन्य उपयोगी परिवर्तन

यह विज्ञापन नहीं है, सिर्फ पृष्ठभूमि है। वास्तव में, मेरे निष्कर्ष उपयोग के लिए सिफारिशों के संदर्भ में बहुत अस्पष्ट होंगे, और सामान्य रूप से लेख एक विशिष्ट ढांचे या पुस्तकालय के लिए समर्पित नहीं है, लेकिन उन कार्यों के लिए जिन्हें विकास प्रक्रिया के दौरान हल करने की आवश्यकता है।

दुर्भाग्य से, दंगा.जॉर्स डेवलपर्स द्वारा किए गए काम का अभी तक समुदाय द्वारा ठीक से मूल्यांकन नहीं किया गया है। उदाहरण के लिए, सर्वर छह महीने के लिए लाइब्रेरी github.com/riot/ssr प्रदान करता है, जो अपने विकास की शुरुआत के बाद से तीन सह-योगदानकर्ताओं और github.com पर तीन लाइक्स एकत्र करता है (सभी पसंद योगदानकर्ताओं द्वारा नहीं किए जाते हैं, हालांकि एक योगदानकर्ता के समान है)।

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

तो यहाँ हम चलते हैं। उदाहरण के लिए, github.com/gothinkster/realworld एप्लिकेशन का कार्यान्वयन किया गया था। इस परियोजना के बारे में Habré पर एक से अधिक बार चर्चा की गई है। जो लोग उससे परिचित नहीं हैं, उनके लिए मैं संक्षेप में उनके विचार का वर्णन करूंगा। इस परियोजना के डेवलपर्स विभिन्न प्रोग्रामिंग भाषाओं और फ्रेमवर्क (या उनके बिना) की मदद से एक ही समस्या को हल करते हैं: एक ब्लॉग इंजन का विकास, मध्यम.कॉम के सरलीकृत संस्करण के समान कार्यक्षमता में। यह वास्तविक अनुप्रयोगों की जटिलता के बीच एक समझौता है जिसे हमें दैनिक आधार और todo.app पर विकसित करना है, जो हमें हमेशा पुस्तकालय या ढांचे के साथ काम की सराहना करने की अनुमति नहीं देता है। यह परियोजना डेवलपर्स द्वारा सम्मानित की जाती है। उपरोक्त की पुष्टि में, मैं कह सकता हूं कि रिच हैरिस (sveltejs के प्रमुख डेवलपर) github.com/sveltejs/realworld से भी एक कार्यान्वयन है।

विकास का वातावरण

बेशक आप लड़ाई में भाग लेने के लिए तैयार हैं, लेकिन अपने आसपास के डेवलपर्स के बारे में सोचें। इस मामले में, इस सवाल पर ध्यान दें कि आपके सहयोगी किस विकास के माहौल में काम करते हैं। यदि आपके साथ काम करने जा रहे ढांचे के लिए मुख्य विकास वातावरण और प्रोग्राम कोड संपादकों के लिए कोई प्लगइन्स नहीं हैं, तो आप समर्थित होने की संभावना नहीं है। उदाहरण के लिए, मैं विकास के लिए एटम संपादक का उपयोग करता हूं। उसके लिए एक दंगा-टैग प्लगइन github.com/riot/syntax-highlight/tree/legacy है , जो पिछले तीन वर्षों से अपडेट नहीं किया गया है। और उसी रिपॉजिटरी में उदात्त github.com/riot/syntax-highlight के लिए एक प्लगइन है - यह चालू है और riot.js 4.0 के वर्तमान संस्करण का समर्थन करता है।

हालाँकि, riot.js घटक एक HTML दस्तावेज़ का एक मान्य टुकड़ा है जिसमें JS कोड स्क्रिप्ट तत्व के मुख्य भाग में समाहित है। तो सब कुछ बस काम करता है यदि आप * .ri विस्तार के लिए एक HTML दस्तावेज़ प्रकार जोड़ते हैं। बेशक, यह एक मजबूर निर्णय है, अन्यथा इसे आगे जारी रखने के लिए बस असंभव होता।

हमें एक टेक्स्ट एडिटर में सिंटैक्स हाइलाइटिंग मिला है, और अब हमें अधिक उन्नत कार्यक्षमता की आवश्यकता है, जिसे हम एस्लिंट से प्राप्त करने के लिए उपयोग किया जाता है। हमारे मामले में, घटकों का JS कोड स्क्रिप्ट तत्व के शरीर में समाहित है, मैं HTML दस्तावेज़ से JS कोड निकालने के लिए एक प्लगइन ढूंढने और खोजने की उम्मीद कर रहा था - github.com/BenoitZugmeyer/eslint.plugin-html । उसके बाद, मेरा अनुगामी विन्यास इस तरह दिखने लगा:

{ "parser": "babel-eslint", "plugins": [ "html" ], "settings": { "html/html-extensions": [".html", ".riot"] }, "env": { "browser": true, "node": true, "es6": true }, "extends": "standard", "globals": { "Atomics": "readonly", "SharedArrayBuffer": "readonly" }, "parserOptions": { "ecmaVersion": 2018, "sourceType": "module" }, "rules": { } }

सिंटैक्स हाइलाइटिंग और एस्लिंट के लिए प्लग-इन की उपस्थिति शायद पहली बात नहीं है कि एक डेवलपर जेएस फ्रेमवर्क का चयन करते समय सोचने लगता है। इस बीच, इन उपकरणों के बिना, आप परियोजना से "अच्छे" कारणों के लिए सहयोगियों और उनके सामूहिक पलायन का विरोध कर सकते हैं। यद्यपि एकमात्र और सही मायने में वैध कारण यह है कि वे पूर्ण डेवलपर शस्त्रागार के बिना काम करने में असहज हैं। दंगों के मामले में, समस्या को कोलंबस विधि द्वारा हल किया गया था। इस अर्थ में कि वास्तव में riot.js के लिए कोई प्लगइन्स नहीं हैं, लेकिन riot.js टेम्पलेट सिंटैक्स की ख़ासियत के कारण, जो एक नियमित HTML दस्तावेज़ के टुकड़े की तरह दिखता है, हम एक HTML दस्तावेज़ के साथ काम करने के लिए आवश्यक कार्यक्षमता के 99% को कवर करते हैं।

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

प्रोजेक्ट असेंबली

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

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

1. एक विकास मोड और एक कामकाजी अनुप्रयोग की उपस्थिति
डेवलपर मोड में:
2. परियोजना संकलन त्रुटियों के बारे में जानकारीपूर्ण संदेश (स्रोत फ़ाइल का नाम, स्रोत फ़ाइल में लाइन संख्या, त्रुटि का विवरण)
3. रनटाइम त्रुटियों के बारे में जानकारीपूर्ण संदेश (स्रोत फ़ाइल का नाम, स्रोत फ़ाइल में लाइन नंबर, त्रुटि का विवरण)
4. संशोधित मॉड्यूल का त्वरित आश्वासन
5. ब्राउज़र में घटकों का गर्म अधिभार
ऑपरेटिंग मोड में:
6. फ़ाइल नाम में संस्करण की उपस्थिति (उदाहरण के लिए 4a8ee185040ac59496a2.main.js)
7. एक या एक से अधिक मॉड्यूल में छोटे मॉड्यूल का लेआउट (हिस्सा)
8. कोड गतिशील आयात का उपयोग करके विखंडू में टूट रहा है

Riot.js संस्करण 4.0 में, github.com/riot/webpack-loader मॉड्यूल दिखाई दिया, जो पूरी तरह से दिए गए चेकलिस्ट से मेल खाता है। मैं विधानसभा कॉन्फ़िगरेशन की सभी विशेषताओं को सूचीबद्ध नहीं करूंगा। केवल एक चीज जिस पर मैं ध्यान दूंगा, वह यह है कि इस परियोजना के तहत मैं एक्सप्रेस के लिए मॉड्यूल का उपयोग करता हूं। जेएस: वेबपैक-देव-मिडलवेयर और वेबपैक-हॉट-मिडलवेयर, जो आपको टाइपसेटिंग के समय से तुरंत एक पूरी तरह कार्यात्मक सर्वर पर काम करने की अनुमति देते हैं। यह, विशेष रूप से, सार्वभौमिक / आइसोमॉर्फिक वेब अनुप्रयोगों के विकास की अनुमति देता है। मैं इस तथ्य पर आपका ध्यान आकर्षित करता हूं कि मॉड्यूल हॉट ओवरलोड मॉड्यूल केवल एक वेब ब्राउज़र के लिए मान्य है। उसी समय, सर्वर साइड पर प्रदान किया गया घटक अपरिवर्तित रहता है। इसलिए, इसके परिवर्तनों को सुनना आवश्यक है, और सही समय पर, सर्वर द्वारा कैश किए गए सभी कोड को हटा दें और परिवर्तित मॉड्यूल के कोड को लोड करें। यह लंबे समय तक कैसे करें, इसलिए मैं केवल कार्यान्वयन के लिए एक लिंक प्रदान करूंगा: github.com/apapacy/realworld-riotjs-effector-universal-hot/blob/master/src/dev/server.js

मार्ग

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

आइए इतिहास में एक छोटा सा भ्रमण करें। इंटरनेट की भोर में, URL / URI ने सर्वर पर होस्ट की गई फ़ाइल के नाम से मिलान किया। हम एक ही बार में इतिहास के कई पन्नों को पलट देते हैं और हम मॉडल 2 (एमवीसी) आर्किटेक्चर के आगमन के बारे में जानेंगे। इस वास्तुकला में, एक फ्रंट कंट्रोलर दिखाई देता है, जो रूटिंग का कार्य करता है। मैंने सोचा कि पहले नियंत्रक से अलग ब्लॉक में रूटिंग फ़ंक्शन का चयन करने का फैसला किसने किया, जो तब कई नियंत्रकों में से एक को एक अनुरोध भेजता है और अभी तक इसका जवाब नहीं मिला है। ऐसा लगता है कि उन्होंने यह सब एक ही बार में करना शुरू कर दिया।

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

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

... एसपीए एप्लिकेशन बनाना आसान बनाता है। निम्नलिखित विशेषताएं शामिल हैं

नेस्टेड मार्ग / दृश्य
मॉड्यूलर राउटर कॉन्फ़िगरेशन
मार्ग पैरामीटर, क्वेरी, वाइल्डकार्ड तक पहुंच
Vue.js पर आधारित संक्रमण एनीमेशन देखें
सुविधाजनक नेविगेशन नियंत्रण
लिंक के लिए सक्रिय सीएसएस वर्ग का स्वत: प्रत्यय
IE9 में ऑटो-स्विच के साथ HTML5 इतिहास मोड या हैश
कस्टम स्क्रॉल व्यवहार

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

यूनिवर्सल / आइसोमॉर्फिक वेब अनुप्रयोगों के लिए वेब क्लाइंट साइड और वेब सर्वर साइड दोनों पर समान काम करना चाहिए;
किसी भी (मेरे चुने हुए) ढांचे के साथ या इसके बिना काम करना चाहिए।

और मुझे ऐसी लाइब्रेरी मिली, यह github.com/kriasoft/universal-router है । यदि हम इस लाइब्रेरी के विचार का संक्षेप में वर्णन करते हैं, तो यह उन मार्गों को कॉन्फ़िगर करता है जो इनपुट पर URLs का एक स्ट्रिंग लेते हैं और आउटपुट पर एक अतुल्यकालिक फ़ंक्शन को कॉल करते हैं, जो पार्स किए गए URL को वास्तविक पैरामीटर के रूप में पास करता है। ईमानदारी से, मैं पूछना चाहता था: क्या यह सब है? और फिर सभी को इसके साथ कैसे काम करना चाहिए? और तब मुझे मध्यम.कॉम मध्यम. com/@ippei.tanaka/universal-router-history-react-97ec79464573 पर एक लेख मिला, जिसमें एक बहुत अच्छा विकल्प प्रस्तावित किया गया था, जिसके अपवाद के साथ शायद पुर्नलेखन () इतिहास विधि, जो मुझे जरूरत है और जिसे मैंने अपने कोड से हटा दिया है। परिणामस्वरूप, क्लाइंट साइड पर राउटर का संचालन निम्नानुसार परिभाषित किया गया है:

 const routes = new UniversalRouter([ { path: '/sign-in', action: () => ({ page: 'login', data: { action: 'sign-in' } }) }, { path: '/sign-up', action: () => ({ page: 'login', data: { action: 'sign-up' } }) }, { path: '/', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'home' } }) }, { path: '/feed', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, { path: '/feed/page/:page', action: (req) => ({ page: 'home', data: { req, action: 'feed' } }) }, ... { path: '(.*)', action: () => ({ page: 'notFound', data: { action: 'not-found' } }) } ]) const root = getRootComponent() const history = createBrowserHistory() const render = async (location) => { const route = await router.resolve(location) const component = await import(`./riot/pages/${route.page}.riot`) riot.register(route.page, component.default || component) root.update(route, root) } history.listen(render)

अब history.push () पर कोई भी कॉल राउटिंग शुरू करेगा। एप्लिकेशन के अंदर नेविगेट करने के लिए, आपको एक घटक बनाने की ज़रूरत है जो मानक HTML तत्व को लपेटता है (एंकर), अपने डिफ़ॉल्ट व्यवहार को रद्द करने के लिए नहीं भूलना:

 <navigation-link href={ props.href } onclick={ action }> <slot/> <script> import history from '../history' export default { action (e) { e.preventDefault() history.push(this.props.href) if (this.props.onclick) { this.props.onclick.call(this, e) } e.stopPropagation() } } </script> </navigation-link>

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

प्रारंभ में, मैंने प्रोजेक्ट में mobx लाइब्रेरी को शामिल किया। सब कुछ उम्मीद के मुताबिक काम किया। सिवाय इसके कि यह कार्य के अनुरूप नहीं था - अध्ययन जो मैंने लेख की शुरुआत में निर्धारित किया था। इसलिए मैंने github.com/zerobias/effector पर स्विच किया। यह एक बहुत शक्तिशाली परियोजना है। यह 100% रिडक्स कार्यक्षमता (केवल बड़े ओवरहेड के बिना) और 100% mobx कार्यक्षमता देता है (हालांकि इस मामले में यह थोड़ा अधिक कोड करने के लिए आवश्यक होगा, लेकिन डेकोरेटर के बिना मोबेक्स के साथ तुलना में अभी भी कम है)

स्टोर का विवरण कुछ इस तरह दिखता है:

 import { createStore, createEvent } from 'effector' import { request } from '../agent' import { parseError } from '../utils' export default class ProfileStore { get store () { return this.profileStore.getState() } constructor () { this.success = createEvent() this.error = createEvent() this.updateError = createEvent() this.init = createEvent() this.profileStore = createStore(null) .on(this.init, (state, store) => ({ ...store })) .on(this.success, (state, data) => ({ data })) .on(this.error, (state, error) => ({ error })) .on(this.updateError, (state, error) => ({ ...state, error })) } getProfile ({ req, author }) { return request(req, { method: 'get', url: `/profiles/${decodeURIComponent(author)}` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } follow ({ author, method }) { return request(undefined, { method, url: `/profiles/${author}/follow` }).then( response => this.success(response.data.profile), error => this.error(parseError(error)) ) } }

यह लाइब्रेरी पूर्ण-विकसित रीड्यूसर का उपयोग करती है (इन्हें इफ़ेक्टर (जेएस डॉक्यूमेंटेशन में कहा जाता है) कहा जाता है, जिनमें बहुत से लोगों के पास मोबक्स की कमी होती है, लेकिन रिडक्स की तुलना में बहुत कम कोडिंग प्रयास के साथ। लेकिन मुख्य बात यह भी नहीं है। Redux और mobx की कार्यक्षमता का 100% प्राप्त करने के बाद, मैंने कार्यक्षमता का केवल दसवां हिस्सा उपयोग किया है जो प्रभावकारक .js में निहित है। जिससे हम यह निष्कर्ष निकाल सकते हैं कि जटिल परियोजनाओं में इसका उपयोग डेवलपर्स के फंड को काफी समृद्ध कर सकता है।

परीक्षण

यह करें

निष्कर्ष

तो, काम पूरा हो गया है। परिणाम रिपॉजिटरी github.com/apapacy/realworld-riotjs-effector-universal-hot में और इस लेख पर Habré में प्रस्तुत किया गया है।
अब realworld-riot-effector-universal-hot-pnujtmugam.now.sh पर डेमो साइट

और अंत में मैं विकास के अपने छापों को साझा करूंगा। Riot.js संस्करण 4.0 पर विकसित करना काफी सुविधाजनक है। कई निर्माणों को रिएक्ट की तुलना में लिखना आसान है। बाद के घंटों और सप्ताहांत में कट्टरता के बिना विकसित होने में ठीक दो सप्ताह लगे। लेकिन ... एक छोटा लेकिन ... चमत्कार फिर से नहीं हुआ। रिएक्ट में सर्वर रेंडरिंग 20-30 गुना तेज है। निगम फिर से जीते। हालांकि, दो दिलचस्प रूटिंग और राज्य प्रबंधक पुस्तकालयों का परीक्षण किया गया था।

apapacy@gmail.com
17 जून 2019