फाइबर आर्किटेक्चर को फिर से शुरू करने के लिए

नमस्कार, हेब्र! मैं आपके ध्यान में एंड्रयू क्लार्क के लेख "रिएक्ट फाइबर आर्किटेक्चर" का अनुवाद लाता हूं।

प्रविष्टि

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

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

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

इस लेख को पढ़ने से पहले, हम अनुशंसा करते हैं कि आप प्रतिक्रिया के मूल सिद्धांतों से खुद को परिचित करें:

• प्रतिक्रिया घटकों, तत्वों, और उदाहरणों
• सुलह
• प्रतिक्रिया - मूल सैद्धांतिक अवधारणा
• डिजाइन सिद्धांतों

सिंहावलोकन

सामंजस्य क्या है?

सुलह एक रिएक्ट एल्गोरिथ्म है जिसका उपयोग उन तत्वों को निर्धारित करने के लिए एक तत्व के पेड़ को दूसरे से अलग करने के लिए किया जाता है जिन्हें प्रतिस्थापित करने की आवश्यकता होगी।

एक अद्यतन डेटा में एक परिवर्तन है जो रिएक्ट एप्लिकेशन को प्रस्तुत करने के लिए उपयोग किया जाता है। यह आमतौर पर सेटस्टेट विधि को कॉल करने का परिणाम है; घटक के प्रतिपादन का अंतिम परिणाम।

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

सामान्य तौर पर, प्रत्येक परिवर्तन के लिए पूरे एप्लिकेशन को प्रस्तुत करना केवल सबसे पारंपरिक अनुप्रयोगों में काम करता है। वास्तविक दुनिया में, यह प्रतिकूल रूप से प्रदर्शन को प्रभावित करता है। अधिनियम में अनुकूलन शामिल हैं जो प्रदर्शन के एक विशाल हिस्से को प्रभावित किए बिना एक पूर्ण प्रतिपादन दृश्य बनाते हैं। इनमें से अधिकांश अनुकूलन में सामंजस्य नामक एक प्रक्रिया शामिल है।

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

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

मुख्य अवधारणाएँ:

• विभिन्न प्रकार के घटक काफी अलग-अलग पेड़ों की पीढ़ी का सुझाव देते हैं। रिएक्ट उनकी तुलना करने की कोशिश नहीं करेगा, लेकिन बस पुराने पेड़ को पूरी तरह से बदल देगा।
• सूचियाँ कुंजियों का उपयोग करके प्रतिष्ठित हैं। कुंजी "लगातार, पूर्वानुमान और अद्वितीय होनी चाहिए।"

सुलह बनाम रेंडरिंग

DOM ट्री एक ऐसा वातावरण है जिसे React ड्रा कर सकता है, बाकी को देशी Native और Android Views के लिए React Native का उपयोग करके जिम्मेदार ठहराया जा सकता है (इसीलिए Virtual Dom थोड़ा अनुचित नाम है)।

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

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

फाइबर सामंजस्य एल्गोरिथ्म का पुन: डिज़ाइन किया गया कार्यान्वयन है। इसका प्रतिपादन के लिए एक अप्रत्यक्ष संबंध है, जबकि नई वास्तुकला के सभी लाभों का समर्थन करने के लिए प्रतिपादन तंत्र (रेंडर) को बदला जा सकता है।

नियोजन एक प्रक्रिया है जो निर्धारित करती है कि काम कब पूरा होना चाहिए।

कार्य - किसी भी गणना को निष्पादित किया जाना चाहिए। कार्य आमतौर पर अपडेट का परिणाम होता है (उदाहरण के लिए, कॉलिंग सेटस्टेट)।

रिएक्ट आर्किटेक्चर के सिद्धांत इतने अच्छे हैं कि उन्हें केवल इस उद्धरण के साथ वर्णित किया जा सकता है:

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

मुख्य अवधारणाएँ:

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

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

फाइबर क्या है?

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

और इसलिए!

हमने फाइबर आर्किटेक्चर के उस प्राथमिक लक्ष्य को प्राप्त कर लिया है - जिससे रिएक्ट प्लानिंग का लाभ उठा सके। विशेष रूप से, हमें इसमें सक्षम होना चाहिए:

• काम रोक दें और बाद में उस पर लौट आएं।
• विभिन्न प्रकार के कामों को प्राथमिकता दें।
• पहले किए गए काम का फिर से उपयोग करें।
• यदि अब इसकी आवश्यकता नहीं है, तो कार्य रद्द करें।

यह सब करने के लिए, हमें सबसे पहले काम को इकाइयों में विभाजित करना होगा। एक मायने में, यह फाइबर है। फाइबर काम की एक इकाई का प्रतिनिधित्व करता है।

आगे जाने के लिए, आइए, प्रतिक्रिया के मूल सिद्धांत पर जाएं "फ़ंक्शन डेटा के रूप में घटक" , जिसे अक्सर व्यक्त किया जाता है:

v = f(d) 

इसके साथ यह निम्नानुसार है कि एक रिएक्ट एप्लिकेशन को प्रस्तुत करना एक फ़ंक्शन को कॉल करने जैसा है, जिसके शरीर में अन्य कार्यों के लिए कॉल होते हैं, और इसी तरह। तंतुओं के बारे में सोचते समय यह उपमा उपयोगी है।

जिस तरह से कंप्यूटर मूल रूप से प्रोग्राम के निष्पादन क्रम की जांच करते हैं उसे कॉल स्टैक कहा जाता है। जब फ़ंक्शन पूरा हो जाता है, तो स्टैक में नया स्टैक कंटेनर जोड़ा जाता है। यह स्टैक कंटेनर एक फ़ंक्शन द्वारा किए गए कार्य का प्रतिनिधित्व करता है।

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

क्या यह अच्छा नहीं होगा यदि हम यूजर इंटरफेस के कुछ हिस्सों को प्रदर्शित करने के लिए कॉल स्टैक के व्यवहार को अनुकूलित कर सकें? अगर हम मैन्युअल रूप से कंटेनरों में हेरफेर करने के लिए कॉल स्टैक को तोड़ सकते हैं तो क्या यह अच्छा होगा?

यह रिएक्ट फाइबर की कॉलिंग है। फाइबर रिएक्ट घटकों के अनुरूप एक नया स्टैक कार्यान्वयन है। आप एक सिंगल फाइबर को वर्चुअल स्टैक कंटेनर के रूप में सोच सकते हैं।

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

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

अगले भाग में, हम तंतुओं की संरचना को देखते हैं।

फाइबर संरचना

विशेष रूप से, एक "फाइबर" एक जावास्क्रिप्ट ऑब्जेक्ट है जिसमें एक घटक, इसके इनपुट और आउटपुट के बारे में जानकारी होती है।

फाइबर स्टैक कंटेनर के अनुरूप है, लेकिन यह घटक के सार के अनुरूप भी है।

यहाँ "फाइबर" के कुछ महत्वपूर्ण गुण हैं (यह सूची संपूर्ण नहीं है):

टाइप और की

प्रकार और कुंजी फाइबर के साथ-साथ रिएक्ट तत्वों की सेवा करते हैं। वास्तव में, जब एक फाइबर बनाया जाता है, तो इन दोनों क्षेत्रों को सीधे इसे कॉपी किया जाता है।

फाइबर का प्रकार उस घटक का वर्णन करता है जिससे वह मेल खाती है। घटकों की संरचना के लिए, प्रकार एक घटक का एक कार्य या वर्ग है। सेवा घटकों (div, span) के लिए, प्रकार एक स्ट्रिंग है।

वैचारिक रूप से, एक प्रकार एक फ़ंक्शन है जिसका निष्पादन स्टैक कंटेनर द्वारा ट्रैक किया जाता है।

प्रकार के साथ, कुंजी का उपयोग पेड़ों की तुलना करते समय यह निर्धारित करने के लिए किया जाता है कि क्या फाइबर का पुन: उपयोग किया जा सकता है।

बच्चा और सहोदर

ये क्षेत्र अन्य तंतुओं की ओर इशारा करते हैं, तंतुओं की पुनरावर्ती संरचना का वर्णन करते हैं।

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

 function Parent() { return <Child /> } 

पैरेंट फाइबर चाइल्ड चाइल्ड से मेल खाती है।

रिश्तेदार (या पड़ोसी) फ़ील्ड का उपयोग किया जाता है यदि रेंडर कई बच्चों को प्रदान करता है (फाइबर में एक नई सुविधा):

 function Parent() { return [<Child1 />, <Child2 />] } 

बाल तंतुओं में एक प्रमुख रूप से जुड़ी हुई सूची है, जो पहला बच्चा है। तो इस उदाहरण में, चाइल्ड पैरेंट चाइल्ड 1 है, और चाइल्ड 1 के रिश्तेदार चाइल्ड 2 हैं।

फ़ंक्शंस के साथ हमारे सादृश्य पर लौटते हुए, आप एक बाल फाइबर के बारे में सोच सकते हैं, जिसे अंत में एक फ़ंक्शन कहा जाता है (टेल-फ़ंक्शन कहा जाता है)।

विकिपीडिया उदाहरण:

 function foo(data) { a(data); return b(data); } 

इस उदाहरण में, टेल-फ़ंक्शन फ़ंक्शन बी है।

वापसी मूल्य (वापसी)

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

यदि एक फाइबर में कई बाल फाइबर होते हैं, तो प्रत्येक बच्चे के फाइबर की वापसी मूल फाइबर होती है। ऊपर के उदाहरण में, चाइल्ड 1 और चाइल्ड 2 से रिटर्न फाइबर पेरेंट है।

वर्तमान और कैश्ड गुण (लंबित लंबित और मेमोरोपप्रॉप्स)

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

जब इनपुट प्रतीक्षा गुण कैश हो जाते हैं, तो इसका मतलब है कि पिछले फाइबर आउटपुट को बिना किसी गणना के पुन: उपयोग किया जा सकता है।

वर्तमान कार्य की प्राथमिकता (लंबित कार्यभार)

प्राथमिकता निर्धारण कार्य की मात्रा फाइबर द्वारा प्रदर्शित की जाती है। React ReactPyeritylevel में प्राथमिकता स्तर मॉड्यूल में अलग-अलग प्राथमिकता स्तर और वे क्या दर्शाते हैं, शामिल हैं।

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

 function matchesPriority(fiber, priority) { return fiber.pendingWorkPriority !== 0 && fiber.pendingWorkPriority <= priority } 

यह कार्य केवल दृष्टांत उद्देश्यों के लिए है; यह रिएक्ट फाइबर डेटाबेस का हिस्सा नहीं है।

शेड्यूलर प्राथमिकता क्षेत्र का उपयोग कार्य की अगली इकाई को खोजने के लिए करता है। हम इस एल्गोरिथ्म पर अगले भाग में चर्चा करेंगे।

वैकल्पिक (या जोड़ी)

अद्यतन (फ्लश) फाइबर - इसका मतलब है कि स्क्रीन पर इसका आउटपुट प्रदर्शित करना।

विकास में फाइबर (काम-में-प्रगति) - फाइबर जो अभी तक नहीं बनाया गया है; दूसरे शब्दों में, यह एक स्टैक कंटेनर है जिसे अभी तक वापस नहीं किया गया है।

किसी भी समय, घटक के सार में फाइबर के लिए दो से अधिक राज्य नहीं होते हैं जो मेल खाती है: वर्तमान स्थिति में फाइबर, अद्यतन फाइबर या विकास में फाइबर।

वर्तमान फाइबर का विकास फाइबर द्वारा किया जाता है, और फिर, बदले में, फाइबर को अपडेट किया जाता है।

अगला फाइबर राज्य क्लोनफाइबर फ़ंक्शन का उपयोग करके आलसी बनाया जाता है। लगभग हमेशा एक नई वस्तु बनाते समय, क्लोनफाइबर संसाधनों की लागत को कम करते हुए, फाइबर के एक विकल्प (जोड़ी) को फिर से उपयोग करने का प्रयास करता है।

आपको एक कार्यान्वयन विवरण के रूप में स्टीम फ़ील्ड (या वैकल्पिक) के बारे में सोचना चाहिए, लेकिन यह प्रलेखन में इतनी बार पॉप होता है कि इसका उल्लेख करना असंभव नहीं था।

निष्कर्ष एक सेवा तत्व है (या सेवा तत्वों का एक सेट); पत्ती नोड्स प्रतिक्रिया अनुप्रयोगों। वे प्रत्येक प्रदर्शन वातावरण के लिए विशिष्ट हैं (उदाहरण के लिए, एक ब्राउज़र में यह 'div', 'span', आदि)। JSX में, उन्हें लोअरकेस टैग नामों के रूप में दर्शाया गया है।

नीचे पंक्ति: मैं नए रिएक्ट v16.0 वास्तुकला की सुविधाओं की कोशिश करने की सलाह देता हूं