परमाणुओं ने फ्लक्स को कैसे स्थिर किया

रिकॉइल ने परमाणु मॉडल को रिएक्ट दुनिया में पेश किया। इसकी नई शक्तियाँ तीव्र सीखने की अवस्था और विरल सीखने के संसाधनों की कीमत पर आई हैं।

और बाद में इस नए मॉडल के विभिन्न पहलुओं को सरल बनाया, कई नई सुविधाओं की पेशकश की और इस अद्भुत नए प्रतिमान की सीमाओं को आगे बढ़ाया।

अन्य लेख इन उपकरणों के बीच के अंतरों पर ध्यान केंद्रित करेंगे। यह लेख एक बड़ी विशेषता पर ध्यान केंद्रित करेगा जो तीनों में समान है:

उन्होंने फ्लक्स को ठीक किया।

विषयसूची

• फ्लक्स
• निर्भरता के पेड़
• सिंगलटन मॉडल
• बुनियादी बातों पर वापस
• डेमेटर का कानून
• नायकों
• ज़ेडक्स
• परमाणु मॉडल
• निष्कर्ष

फ्लक्स

यदि आप फ्लक्स को नहीं जानते हैं, तो यहां एक त्वरित सार है:

Redux के अलावा, सभी फ्लक्स-आधारित लाइब्रेरी मूल रूप से इस पैटर्न का अनुसरण करती हैं: एक ऐप में कई स्टोर होते हैं। केवल एक डिस्पैचर है जिसका काम उचित क्रम में सभी स्टोर्स को कार्रवाई खिलाना है। इस "उचित क्रम" का अर्थ है गतिशील रूप से स्टोर के बीच निर्भरताओं को छाँटना।

उदाहरण के लिए, एक ई-कॉमर्स ऐप सेटअप लें:

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

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

फ्लक्स इन निर्भरताओं को पसंद नहीं करता है। से:

फ्लक्स एप्लिकेशन के भीतर वस्तुओं को अत्यधिक विघटित किया जाता है, और बहुत दृढ़ता से का पालन करते हैं, यह सिद्धांत है कि सिस्टम के भीतर प्रत्येक वस्तु को सिस्टम में अन्य वस्तुओं के बारे में जितना संभव हो उतना कम पता होना चाहिए।

इसके पीछे की थ्योरी पुख्ता है। 100%। सू ... फ्लक्स का यह मल्टी-स्टोर फ्लेवर क्यों मर गया?

निर्भरता के पेड़

अच्छी तरह से पता चला है, पृथक राज्य कंटेनरों के बीच निर्भरता अपरिहार्य है। वास्तव में, कोड मॉड्यूलर और DRY रखने के लिए, आपको अक्सर अन्य स्टोर्स का उपयोग करना चाहिए ।

फ्लक्स में, ये निर्भरताएँ ऑन-द-फ्लाई बनाई जाती हैं:

 // This example uses Facebook's own `flux` library PromosStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for CartStore to update first: dispatcher.waitFor([CartStore.dispatchToken]) // now send the request sendPromosRequest(UserStore.userId, CartStore.items).then(promos => { dispatcher.dispatch({ actionType: 'promos-fetched', promos }) }) } if (payload.actionType === 'promos-fetched') { PromosStore.setPromos(payload.promos) } }) CartStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for UserStore to update first: dispatcher.waitFor([UserStore.dispatchToken]) if (UserStore.canBuy(payload.item)) { CartStore.addItem(payload.item) } } })

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

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

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

इस ई-कॉमर्स ऐप में किसी दिन ऑर्डर हिस्ट्री, शिपिंग कैलक्यूलेटर, डिलीवरी एस्टीमेट, केले होर्डेड आदि के लिए स्टोर हो सकते हैं। एक बड़े ऐप में आसानी से सैकड़ों स्टोर हो सकते हैं। आप प्रत्येक स्टोर में निर्भरताओं को अप-टू-डेट कैसे रखते हैं? आप दुष्प्रभावों को कैसे ट्रैक करते हैं? शुद्धता के बारे में क्या? डिबगिंग के बारे में क्या? क्या केले वास्तव में एक बेरी हैं?

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

सिंगलटन मॉडल

हम सभी जानते हैं कि कैसे Redux दिन बचाने के लिए दहाड़ता हुआ आया। इसने सिंगलटन मॉडल के पक्ष में कई स्टोरों की अवधारणा को छोड़ दिया। अब सब कुछ बिना किसी "निर्भरता" के सब कुछ एक्सेस कर सकता है।

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

बाद में Redux के कुख्यात बॉयलरप्लेट को सरल बनाया। तब ज़ुस्टैंड ने कुछ डिबगिंग पावर की कीमत पर कुछ फुलाना हटा दिया। ये सभी उपकरण रिएक्ट की दुनिया में बेहद लोकप्रिय हो गए हैं।

मॉड्यूलर राज्य के साथ, निर्भरता के पेड़ इतने स्वाभाविक रूप से जटिल हो जाते हैं कि सबसे अच्छा समाधान हम सोच सकते थे, "मुझे लगता है कि ऐसा मत करो।"

और यह काम कर गया! यह नया सिंगलटन दृष्टिकोण अभी भी अधिकांश ऐप्स के लिए काफी अच्छा काम करता है। फ्लक्स सिद्धांत इतने ठोस थे कि बस निर्भरता दुःस्वप्न को हटाकर इसे ठीक कर दिया।

या किया?

बुनियादी बातों पर वापस

सिंगलटन दृष्टिकोण की सफलता से यह सवाल उठता है कि फ्लक्स पहले स्थान पर क्या प्राप्त कर रहा था? हम कभी एक से अधिक स्टोर क्यों चाहते थे?

मुझे इस पर कुछ प्रकाश डालने की अनुमति दें।

कारण #1: स्वायत्तता

कई दुकानों के साथ, राज्य के टुकड़े अपने स्वायत्त, मॉड्यूलर कंटेनरों में टूट जाते हैं। इन स्टोर्स को आइसोलेशन में टेस्ट किया जा सकता है। इन्हें ऐप्स और पैकेज के बीच आसानी से साझा भी किया जा सकता है।

कारण #2: कोड विभाजन

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

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

कारण #3: मानकीकृत आदिम

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

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

कारण #4: मापनीयता

सिंगलटन मॉडल आश्चर्यजनक रूप से अच्छा प्रदर्शन करता है। Redux ने यह साबित कर दिया है। हालाँकि, इसके चयन मॉडल में विशेष रूप से एक कठिन ऊपरी सीमा होती है। मैंने में इस पर कुछ विचार लिखे हैं। कैशिंग पर अधिकतम नियंत्रण लेते हुए भी एक बड़ा, महंगा चयनकर्ता पेड़ वास्तव में खींचना शुरू कर सकता है।

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

कारण # 5: विनाश

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

कारण # 6: कोलोकेशन

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

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

कारण सारांश

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

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

फ्लक्स वास्तव में एक शक्तिशाली राज्य प्रबंधक के रूप में विकसित हो सकता था अगर किसी ने अपनी देवी का नाम डेमेटर नहीं रखा होता। मैं गंभीर हूं! ... ठीक है, मैं नहीं हूँ। लेकिन अब जब आप इसका जिक्र करते हैं, तो शायद डेमेटर का कानून करीब से देखने का हकदार है:

डेमेटर का कानून

यह तथाकथित "कानून" वास्तव में क्या है? से:

• प्रत्येक इकाई को अन्य इकाइयों के बारे में केवल सीमित ज्ञान होना चाहिए: केवल इकाइयां "निकटता से" वर्तमान इकाई से संबंधित हैं।
• प्रत्येक इकाई को केवल अपने मित्रों से ही बात करनी चाहिए; अजनबियों से बात मत करो।

यह कानून ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग को ध्यान में रखकर बनाया गया था, लेकिन इसे कई क्षेत्रों में लागू किया जा सकता है, जिसमें रिएक्ट स्टेट मैनेजमेंट भी शामिल है।

मूल विचार एक स्टोर को इससे रोकना है:

• दूसरे स्टोर के कार्यान्वयन विवरण के साथ स्वयं को कसकर जोड़ना।
• उन स्टोर्स का उपयोग करना जिनके बारे में उसे जानने की आवश्यकता नहीं है ।
• उस स्टोर पर निर्भरता स्पष्ट रूप से घोषित किए बिना किसी अन्य स्टोर का उपयोग करना।

केले के संदर्भ में, एक केले को दूसरे केले को छीलना नहीं चाहिए और किसी दूसरे पेड़ के केले से बात नहीं करनी चाहिए। हालाँकि, यह दूसरे पेड़ से बात कर सकता है यदि दो पेड़ पहले एक केले की फोन लाइन बनाते हैं।

यह चिंताओं को अलग करने को प्रोत्साहित करता है और आपके कोड को मॉड्यूलर, DRY और SOLID रहने में मदद करता है। ठोस सिद्धांत! तो फ्लक्स क्या गायब था?

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

 PromosStore.dispatchToken = dispatcher.register(payload => { if (payload.actionType === 'add-to-cart') { // wait for CartStore to update first: dispatcher.waitFor([CartStore.dispatchToken]) // now send the request sendPromosRequest(UserStore.userId, CartStore.items).then(promos => { dispatcher.dispatch({ actionType: 'promos-fetched', promos }) }) } if (payload.actionType === 'promos-fetched') { PromosStore.setPromos(payload.promos) } })

PromosStore में कई निर्भरताएँ अलग-अलग तरीकों से घोषित की गई हैं - यह CartStore से प्रतीक्षा करती है और पढ़ती है और यह UserStore से पढ़ती है। इन निर्भरताओं को खोजने का एकमात्र तरीका प्रोमोस्टोर के कार्यान्वयन में स्टोर्स की तलाश करना है।

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

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

इस कहानी के नायकों के विपरीत:

नायकों

2020 में, ठोकर खाकर सामने आया। शुरुआत में थोड़ा अनाड़ी होने के बावजूद, इसने हमें एक नया पैटर्न सिखाया जिसने फ्लक्स के मल्टी-स्टोर दृष्टिकोण को पुनर्जीवित किया।

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

परमाणु मॉडल का जन्म हुआ।

 // a Recoil atom const greetingAtom = atom({ key: 'greeting', default: 'Hello, World!', })

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

मौके पर पहुंचे और तेजी से फॉलोअर्स हासिल कर लिए।

 // a Jotai atom const greetingAtom = atom('Hello, World!')

Recoil के आकार का एक छोटा अंश होने के अलावा, Jotai ने अपने WeakMap-आधारित दृष्टिकोण के कारण बेहतर प्रदर्शन, चिकना API और कोई मेमोरी लीक की पेशकश नहीं की।

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

 // a (better?) Jotai atom const greetingAtom = atom('Hello, World!') greetingAtom.debugLabel = 'greeting'

कुछ सम्माननीय उल्लेख और हैं। इन पुस्तकालयों ने परमाणु मॉडल के पीछे के सिद्धांत का अधिक पता लगाया है और इसके आकार और गति को सीमित करने की कोशिश की है।

परमाणु मॉडल तेज है और बहुत अच्छी तरह से मापता है। लेकिन अभी हाल तक, कुछ चिंताएँ थीं जिन्हें किसी भी परमाणु पुस्तकालय ने अच्छी तरह से संबोधित नहीं किया था:

• सीखने की अवस्था। परमाणु अलग हैं। हम इन अवधारणाओं को रिएक्ट देवों के लिए कैसे स्वीकार्य बना सकते हैं?

  
  

• देव एक्स और डिबगिंग। हम परमाणुओं को खोजने योग्य कैसे बनाते हैं? आप अद्यतनों को कैसे ट्रैक करते हैं या अच्छी प्रथाओं को कैसे लागू करते हैं?

  
  

• मौजूदा कोडबेस के लिए इंक्रीमेंटल माइग्रेशन। आप बाहरी स्टोर कैसे एक्सेस करते हैं? आप मौजूदा तर्क को कैसे बरकरार रखते हैं? आप एक पूर्ण पुनर्लेखन से कैसे बचते हैं?

  
  

• प्लगइन्स। हम परमाणु मॉडल को एक्स्टेंसिबल कैसे बनाते हैं? क्या यह हर संभव स्थिति को संभाल सकता है?

  
  

• डिपेंडेंसी इंजेक्शन। परमाणु स्वाभाविक रूप से निर्भरताओं को परिभाषित करते हैं, लेकिन क्या उन्हें परीक्षण के दौरान या विभिन्न वातावरणों में बदल दिया जा सकता है?

  
  

• डेमेटर का कानून। हम कार्यान्वयन विवरण कैसे छिपाते हैं और बिखरे हुए अद्यतनों को कैसे रोकते हैं?

यह वह जगह है जहाँ मैं अंदर आता हूँ। देखिए, मैं एक और परमाणु पुस्तकालय का मुख्य निर्माता हूँ:

ज़ेडक्स

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

 // a Zedux atom const greetingAtom = atom('greeting', 'Hello, World!')

मैं यहाँ ज़ेडक्स की विशेषताओं के बारे में गहराई से नहीं जाऊँगा - जैसा कि मैंने कहा, यह लेख इन परमाणु पुस्तकालयों के बीच के अंतरों पर ध्यान केंद्रित नहीं करेगा।

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

फ्लक्स की अंतिम विचारधाराओं को अंततः पुनर्जीवित किया गया है - न केवल पुनर्जीवित किया गया, बल्कि सुधार किया गया! - परमाणु मॉडल के लिए धन्यवाद।

तो वास्तव में परमाणु मॉडल क्या है ?

परमाणु मॉडल

इन परमाणु पुस्तकालयों में कई अंतर हैं - उनके पास "परमाणु" के अर्थ की अलग-अलग परिभाषाएँ भी हैं। आम सहमति यह है कि परमाणु छोटे, अलग-थलग, स्वायत्त राज्य के कंटेनर होते हैं जो एक डायरेक्टेड एसाइक्लिक ग्राफ के माध्यम से प्रतिक्रियात्मक रूप से अपडेट होते हैं।

मुझे पता है, मुझे पता है, यह जटिल लगता है, लेकिन जब तक मैं इसे केले के साथ समझाता हूं तब तक प्रतीक्षा करें।

मैं मजाक कर रहा हूं! यह वास्तव में बहुत आसान है:

ग्राफ के माध्यम से रिकोषेट अपडेट करता है। इतना ही!

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

कई स्टोर चाहने के लिए मैंने जो 6 कारण दिए, वे वास्तव में परमाणु मॉडल के इतने शक्तिशाली होने के कारण हैं:

1. स्वायत्तता - परमाणुओं का परीक्षण किया जा सकता है और पूरी तरह से अलगाव में उपयोग किया जा सकता है।
2. कोड विभाजन - एक परमाणु आयात करें और उसका उपयोग करें! किसी अतिरिक्त विचार की आवश्यकता नहीं है।
3. मानकीकृत आदिम - कुछ भी स्वत: एकीकरण के लिए एक परमाणु को उजागर कर सकता है।
4. मापनीयता - अद्यतन राज्य वृक्ष के केवल एक छोटे से हिस्से को प्रभावित करते हैं।
5. विनाश - बस एक परमाणु का उपयोग करना बंद करो और उसकी सारी अवस्था कचरा एकत्र हो जाती है।
6. कोलोकेशन - परमाणु स्वाभाविक रूप से अपनी स्थिति, दुष्प्रभाव और अद्यतन तर्क को परिभाषित करते हैं।

सरल एपीआई और मापनीयता ही परमाणु पुस्तकालयों को हर रिएक्ट ऐप के लिए एक उत्कृष्ट विकल्प बनाती है। रेडक्स की तुलना में अधिक शक्ति और कम बॉयलरप्लेट? क्या यह एक सपना है?

निष्कर्ष

क्या यात्रा है! रिएक्ट राज्य प्रबंधन की दुनिया विस्मित करना बंद नहीं करती है, और मुझे खुशी है कि मैंने एक सवारी की।

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

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

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

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

इसमें 10 साल लग गए, लेकिन फ्लक्स द्वारा पेश किया गया ठोस सीएस सिद्धांत आखिरकार परमाणु मॉडल की बदौलत रिएक्ट ऐप्स को बड़े पैमाने पर प्रभावित कर रहा है। और यह आने वाले कई सालों तक ऐसा करना जारी रखेगा।