पुस्तकालयों का उपयोग किए बिना प्रतिक्रिया अनुप्रयोगों में सामान्य राज्य को कैसे व्यवस्थित किया जाए (और mobx की आवश्यकता क्यों है)

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

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

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

लेकिन क्या सेटस्टैट या किसी अतिरिक्त पुस्तकालयों का उपयोग किए बिना प्रतिक्रिया एप्लिकेशन में प्रक्रिया को स्टोर करना और रेंडर करना संभव है और किसी भी घटक से इस डेटा तक सामान्य पहुंच प्रदान करना है?

सबसे आम जावास्क्रिप्ट वस्तुओं और उन्हें व्यवस्थित करने के लिए कुछ नियम हमारी सहायता के लिए आते हैं।

लेकिन पहले आपको यह सीखने की ज़रूरत है कि अनुप्रयोगों को इकाई प्रकारों और उनके संबंधों में कैसे विघटित किया जाए।

शुरू करने के लिए, हम एक ऐसी वस्तु को शुरू करते हैं जो वैश्विक डेटा को संग्रहीत करेगा जो पूरे अनुप्रयोग पर एक पूरे के रूप में लागू होता है - (यह स्टाइल, स्थानीयकरण, खिड़की के आकार आदि के लिए सेटिंग्स) एक एकल AppState ऑब्जेक्ट में हो सकता है और बस इस ऑब्जेक्ट को एक अलग फ़ाइल में डाल सकता है।

// src/stores/AppState.js export const AppState = { locale: "en", theme: "...", .... } 

अब किसी भी घटक में आप हमारे स्टोर के डेटा को आयात और उपयोग कर सकते हैं।

 import AppState from "../stores/AppState.js" const SomeComponent = ()=> ( <div> {AppState.locale === "..." ? ... : ...} </div> ) 

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

यहाँ एक उदाहरण है - व्यावसायिक तर्क है जिसे "उपयोगकर्ता प्रत्येक फ़ोल्डर में, प्रत्येक कार्य परियोजना में और प्रत्येक उपटैब कार्य में फ़ोल्डर, प्रोजेक्ट बना / संपादित / हटा सकता है" (यह कार्य प्रबंधक की तरह कुछ करता है) और राज्य के आरेख में दिखेगा कुछ इस तरह:

 export const AppStore = { locale: "en", theme: "...", currentUser: { name: "...", email: "" folders: [ { name: "folder1", projects: [ { name: "project1", tasks: [ { text: "task1", subtasks: [ {text: "subtask1"}, .... ] }, .... ] }, ..... ] }, ..... ] } } 

अब App का रूट कंपोनेंट इस ऑब्जेक्ट को इम्पोर्ट कर सकता है और यूजर के बारे में कुछ जानकारी दे सकता है, और फिर यह यूजर ऑब्जेक्ट को डैशबोर्ड कंपोनेंट में ट्रांसफर कर सकता है।

  .... <Dashboard user={appState.user}/> .... 

और वह फ़ोल्डर्स की सूची को प्रस्तुत कर सकता है

  ... <div>{user.folders.map(folder=><Folder folder={folder}/>)}</div> ... 

और फ़ोल्डर का प्रत्येक घटक परियोजनाओं की एक सूची प्रदर्शित करेगा

  .... <div>{folder.projects.map(project=><Project project={project}/>)}</div> .... 

और परियोजना के प्रत्येक घटक कार्यों को सूचीबद्ध कर सकते हैं

  .... <div>{project.tasks.map(task=><Task task={task}/>)}</div> .... 

और अंत में, प्रत्येक टास्क कंपोनेंट वांछित ऑब्जेक्ट को सबस्कैस कंपोनेंट में पास करके सबस्टॉक की सूची प्रस्तुत कर सकता है

  .... <div>{task.subtask.map(subtask=><Subtask subtask={subtask}/>)}</div> .... 

स्वाभाविक रूप से, एक पृष्ठ पर कोई भी सभी फ़ोल्डरों की सभी परियोजनाओं के सभी कार्यों को प्रदर्शित नहीं करेगा, उन्हें साइड पैनल (उदाहरण के लिए, फ़ोल्डरों की एक सूची), पेजों आदि द्वारा विभाजित किया जाएगा, लेकिन सामान्य संरचना लगभग समान है - माता-पिता घटक एम्बेडेड ऑब्जेक्ट्स को प्रॉप्स के साथ गुजारते हैं। डेटा। एक महत्वपूर्ण बिंदु पर ध्यान दिया जाना चाहिए - किसी भी वस्तु (उदाहरण के लिए, एक फ़ोल्डर, परियोजना, कार्य का एक वस्तु) किसी भी घटक की स्थिति के अंदर संग्रहीत नहीं किया जाता है - घटक बस इसे और अधिक सामान्य वस्तु के हिस्से के रूप में सहारा के माध्यम से प्राप्त करता है। और उदाहरण के लिए, जब प्रोजेक्ट घटक टास्क ऑब्जेक्ट ( <div>{project.tasks.map(task=><Task task={task}/>)}</div> ) पास करता है, तो इस तथ्य के कारण कि ऑब्जेक्ट एक ही ऑब्जेक्ट के अंदर जमा होते हैं आप इस कार्य ऑब्जेक्ट को हमेशा बाहर से बदल सकते हैं - उदाहरण के लिए, AppState.currentUser.folders [2] .projects [3] .tasks [4] .text = "संपादित कार्य" और फिर रूट घटक को अद्यतन करने का कारण (ReactDOM.render (<App />)। ) और इस तरह हम आवेदन की वर्तमान स्थिति प्राप्त करते हैं।

मान लीजिए कि आगे हम टास्क कंपोनेंट में "+" बटन पर क्लिक करते हुए एक नया सबटैक बनाना चाहते हैं। सब कुछ सरल है

  onClick = ()=>{ this.props.task.subtasks.push({text: ""}); updateDOM() } 

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

 export function updateDOM(){ ReactDom.render(<App/>, rootElement); } 

और इससे कोई फर्क नहीं पड़ता है कि AppState के किन हिस्सों से और किन जगहों से हम बदलते हैं (उदाहरण के लिए, आप प्रॉम्प्ट के माध्यम से एक फ़ोल्डर ऑब्जेक्ट को सबटैक घटक के लिए इंटरसैट प्रोजेक्ट के माध्यम से अग्रेषित कर सकते हैं, और यह सिर्फ फ़ोल्डर का नाम अपडेट कर सकता है (this.props.folder.name = "नया नाम) ") - इस तथ्य के कारण कि घटक प्रॉप्स के माध्यम से डेटा प्राप्त करते हैं, रूट घटक को अपडेट करने से सभी नेस्टेड घटकों को अपडेट किया जाएगा और संपूर्ण एप्लिकेशन को अपडेट किया जाएगा।

अब चलो पक्ष के साथ काम करने के लिए कुछ सुविधा जोड़ने का प्रयास करें। ऊपर दिए गए उदाहरण में, आप नोटिस कर सकते हैं कि हर बार एक नई इकाई ऑब्जेक्ट बनाते हैं (उदाहरण के लिए project.tasks.push({text: "", subtasks: [], ...}) यदि ऑब्जेक्ट में डिफ़ॉल्ट मापदंडों के साथ कई गुण हैं, तो हर बार उन्हें सूचीबद्ध करने के लिए और आप एक गलती कर सकते हैं और कुछ भूल सकते हैं, आदि। पहली बात जो मन में आती है वह एक वस्तु के निर्माण को एक फ़ंक्शन में डालती है जहां डिफ़ॉल्ट फ़ील्ड असाइन किए जाएंगे और एक ही समय में नए डेटा के साथ उन्हें फिर से परिभाषित करेंगे।

 function createTask(data){ return { text: "", subtasks: [], ... //many default fields ...data } } 

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

 class Task { text: ""; subtasks: []; constructor(data){ Object.assign(this, data) } } 

और फिर ऑब्जेक्ट बनाने से बस कुछ डिफ़ॉल्ट फ़ील्ड को ओवरराइड करने की क्षमता के साथ वर्ग का एक उदाहरण बन जाएगा

 onAddTask = ()=>{ this.props.project.tasks.push(new Task({...}) } 

इसके अलावा, आप देख सकते हैं कि इसी तरह, प्रोजेक्ट ऑब्जेक्ट्स, उपयोगकर्ताओं, सबस्कूलों के लिए कक्षाएं बनाते हुए, हमें कंस्ट्रक्टर के अंदर कोड दोहराव मिलता है।

 constructor(){ Object.assign(this,data) } 

लेकिन हम इनहेरिटेंस का लाभ उठा सकते हैं और इस कोड को बेस क्लास के कंस्ट्रक्टर में खींच सकते हैं।

 class BaseStore { constructor(data){ Object.update(this, data); } } 

इसके अलावा, आप देखेंगे कि हर बार जब हम किसी राज्य को अपडेट करते हैं, तो हम ऑब्जेक्ट के फ़ील्ड्स को मैन्युअल रूप से बदलते हैं

 user.firstName = "..."; user.lastName = "..."; updateDOM(); 

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

 class Task { update(newData){ console.log("before update", this); Object.assign(this, data); console.log("after update", this); } } //// user.update({firstName: "...", lastName: "..."}) 

खैर, प्रत्येक कक्षा में कोड की नकल न करने के लिए, हम इस अपडेट विधि को बेस क्लास में भी स्थानांतरित करते हैं।

अब आप देख सकते हैं कि जब हम कुछ डेटा को अपडेट करते हैं तो हमें अपडेटडॉम () विधि को मैन्युअल रूप से कॉल करना होगा। लेकिन सुविधा के लिए यह संभव है कि हर बार कॉल अपडेट होने पर बेस क्लास की अपडेट ({...}) विधि से कॉल आए।
यह पता चलता है कि बेस क्लास कुछ इस तरह दिखेगा

 class BaseStore { constructor(data){ Object.update(this, data); } update(data){ Object.update(this, data); ReactDOM.render(<App/>, rootElement) } } 

ठीक है, ताकि अपडेट की क्रमिक कॉल के दौरान () विधि कोई अनावश्यक अपडेट न हो, आप घटक को अगले ईवेंट लूप में अपडेट करने में देरी कर सकते हैं

 let TimerId = 0; class BaseStore { constructor(data){ Object.update(this, data); } update(data){ Object.update(this, data); if(TimerId === 0) { TimerId = setTimeout(()=>{ TimerId = 0; ReactDOM.render(<App/>, rootElement); }) } } } 

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

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

 <div>{project.tasks.map(task=><Task task={task}/>)}</div> 

कार्य के बहुत घटक को कुछ जानकारी की आवश्यकता हो सकती है जो सीधे कार्य के अंदर संग्रहीत नहीं है, लेकिन मूल वस्तु में स्थित है।

मान लीजिए कि आप सभी कार्यों को एक रंग में रंगना चाहते हैं जो परियोजना में संग्रहीत है और सभी कार्यों के लिए सामान्य है। ऐसा करने के लिए, टास्क प्रॉप्स के अलावा, प्रोजेक्ट कंपोनेंट को अपने प्रोजेक्ट प्रॉप्स <Task task={task} project={this.props.project}/> को भी ट्रांसमिट करना होगा। और अगर आपको अचानक एक फ़ोल्डर में सभी कार्यों के लिए रंग को सामान्य रंग में रंगने की आवश्यकता है, तो आपको मध्यवर्ती प्रोजेक्ट घटक के माध्यम से वर्तमान फ़ोल्डर ऑब्जेक्ट को फ़ोल्डर घटक से टास्क घटक में स्थानांतरित करना होगा।
एक नाजुक निर्भरता प्रकट होती है कि घटक को पता होना चाहिए कि उसके नेस्टेड घटकों की आवश्यकता क्या है। इसके अलावा, एक प्रतिक्रिया संदर्भ की संभावना है, हालांकि यह मध्यवर्ती घटकों के माध्यम से स्थानांतरण को सरल करेगा, अभी भी प्रदाता के विवरण और बच्चे के घटकों के लिए डेटा की आवश्यकता के ज्ञान की आवश्यकता होगी।

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

  ... const {project} = this.props; const newTask = new Task({project: this.props.project}) this.props.project.tasks.push(newTask); 

इसके अलावा, व्यावसायिक तर्क में वृद्धि के साथ, आप देख सकते हैं कि बोल्टलिंक बैकलिंक सपोर्ट से जुड़ा है (उदाहरण के लिए, नई ऑब्जेक्ट बनाते समय या उदाहरण के लिए पैरेंट ऑब्जेक्ट के लिए एक लिंक असाइन करना, जब किसी प्रोजेक्ट को एक फ़ोल्डर से दूसरे में ट्रांसफर किया जाता है, तो आपको न केवल प्रोजेक्ट को अपडेट करने की आवश्यकता होगी। फ़ोल्डर = newFolder संपत्ति और हटाना अपने आप को पिछले फ़ोल्डर के प्रोजेक्ट एरे से और प्रोजेक्ट एरे में एक नया फोल्डर जोड़ने) को दोहराना शुरू कर देता है और इसे बेस क्लास में भी ले जाया जा सकता है ताकि जब आप ऑब्जेक्ट बनाएं तो यह पेरेंट को निर्दिष्ट करने के लिए पर्याप्त हो - new Task({project: this.porps.project}) new Task({project: this.porps.project}) और बेस क्लास अपने आप project.tasks एक नई वस्तु जोड़ देगा। कार्य सरणी और यह भी कि किसी अन्य प्रोजेक्ट को कार्य स्थानांतरित करते समय यह केवल कार्य को अपडेट करने के लिए पर्याप्त होगा। अद्यतन task.update({project: newProject}) फ़ील्ड और बेस क्लास स्वचालित रूप से कार्य को हटा देगा। पिछली परियोजना से कार्यों की एक सरणी और एक नए में जोड़ा गया। लेकिन इसके लिए पहले से ही रिश्तों की घोषणा की आवश्यकता होगी (उदाहरण के लिए, स्थिर गुणों या विधियों में) ताकि आधार वर्ग को पता हो कि किन क्षेत्रों को अद्यतन करना है।

निष्कर्ष

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

सवाल यह है कि फिर, हमें राज्य और विशेष रूप से, मोबाइल के प्रबंधन के लिए पुस्तकालयों की आवश्यकता क्यों है?

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

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

एक नया आभासी होम ट्री बनाने और पिछले पेड़ के साथ बाद में पुनरावर्ती तुलना पास से अधिक प्रभावी घर नवीकरण तकनीकें हैं।

और अंत में, पुस्तकालय हैं जो एक अलग दृष्टिकोण के माध्यम से धीमी गति से अद्यतन की समस्या को हल करने की कोशिश करते हैं - अर्थात्, यह ट्रैक करने के लिए कि राज्य के कौन से हिस्से किन घटकों से जुड़े हैं और कुछ डेटा बदलते समय, केवल उन घटकों की गणना करें और अपडेट करें जो इस डेटा पर निर्भर करते हैं और शेष घटकों को स्पर्श नहीं करते हैं। Redux भी एक ऐसा पुस्तकालय है, लेकिन इसके लिए राज्य संगठन के लिए एक पूरी तरह से अलग दृष्टिकोण की आवश्यकता है। लेकिन इसके विपरीत, mobx पुस्तकालय, कुछ नया नहीं लाता है और हम आवेदन में कुछ भी बदले बिना व्यावहारिक रूप से रेंडरर का त्वरण प्राप्त कर सकते हैं - बस वर्ग के क्षेत्रों में @observable डेकोरेटर को जोड़ें और @observable डेकोरेटर को इन फ़ील्ड्स को प्रस्तुत करने वाले घटकों पर @observable जाता है और यह बना रहता है हमारे बेस क्लास के अपडेट () पद्धति में रूट कंपोनेंट के लिए केवल अनावश्यक अपडेट कोड को काटने के लिए और हमें पूरी तरह से काम करने वाला एप्लिकेशन मिलेगा, लेकिन अब राज्य के एक हिस्से या यहां तक ​​कि एक क्षेत्र को बदलने से केवल उन घटकों को अपडेट किया जाएगा। पर हस्ताक्षर किए परिपक्व जो वस्तु की एक विशेष राज्य के एक विशेष क्षेत्र के लिए (अंदर विधि () प्रस्तुत करना मोड़)।