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

यदि आपने पहले से ही एक से अधिक स्थानों पर उपयोग किया जाने वाला कोड लिखा है, तो आप इस स्थिति से परिचित हैं:

1. आप एक पुन: प्रयोज्य कोड टुकड़ा बनाते हैं (यह एक फ़ंक्शन, रिएक्ट घटक, रिएक्ट हुक, आदि हो सकता है) और इसे साझा करें (खुले स्रोत में सहयोग या प्रकाशन के लिए)।
2. कोई आपको नई कार्यक्षमता जोड़ने के लिए कहता है। आपका कोड प्रस्तावित कार्यक्षमता का समर्थन नहीं करता है, लेकिन यदि आपने एक छोटा सा परिवर्तन किया है तो यह हो सकता है।
3. आप इस नई सुविधा को चालू रखने के लिए अपने कोड और उससे जुड़े तर्क में एक नया तर्क / प्रस्ताव / विकल्प जोड़ें।
4. चरण 2 और 3 को कई बार दोहराएं (या कई, कई बार)।
5. अब आपका पुन: प्रयोज्य कोड उपयोग और रखरखाव के लिए कठिन है।

क्या वास्तव में कोड का उपयोग और बनाए रखने के लिए एक बुरा सपना है? ऐसे कई पहलू हैं जो आपके कोड को समस्याग्रस्त बना सकते हैं:

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

नतीजतन, हर कोई पीड़ित है। यह ध्यान देने योग्य है कि अंतिम कार्यक्रम का कार्यान्वयन विकास का एक अनिवार्य हिस्सा है। लेकिन यह बहुत अच्छा होगा यदि हम अपने अमूर्त के कार्यान्वयन के बारे में अधिक सोचते हैं ( "एएचए प्रोग्रामिंग" के बारे में पढ़ें)। क्या कोई तरीका है जिससे हम पुन: प्रयोज्य कोड के साथ समस्याओं को कम कर सकते हैं और अभी भी अमूर्त उपयोग करने के लाभों को प्राप्त कर सकते हैं?

नियंत्रण उलटा

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

... पारंपरिक प्रोग्रामिंग में, उपयोगकर्ता कोड जो प्रोग्राम के उद्देश्य को व्यक्त करता है, सामान्य समस्याओं को हल करने के लिए पुन: प्रयोज्य पुस्तकालयों में कहा जाता है, लेकिन नियंत्रण उलटा होने के साथ, यह एक ऐसा वातावरण है जो कस्टम या कार्य-विशिष्ट कोड को कॉल करता है

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

कोड में प्रबंधन का व्युत्क्रम क्या है?

आरंभ करने के लिए, यहां एक बहुत ही विवादित उदाहरण दिया गया है:

 //   Array.prototype.filter   function filter(array) { let newArray = [] for (let index = 0; index < array.length; index++) { const element = array[index] if (element !== null && element !== undefined) { newArray[newArray.length] = element } } return newArray } // : filter([0, 1, undefined, 2, null, 3, 'four', '']) // [0, 1, 2, 3, 'four', ''] 

अब इस अमूर्त में नए उपयोग के मामलों को जोड़कर "अमूर्तता का एक जीवन चक्र" खेलें और इन नए उपयोग के मामलों का समर्थन करने के लिए इसे "माइंडलेस इम्प्रूव" करें:

 //   Array.prototype.filter   function filter( array, { filterNull = true, filterUndefined = true, filterZero = false, filterEmptyString = false, } = {}, ) { let newArray = [] for (let index = 0; index < array.length; index++) { const element = array[index] if ( (filterNull && element === null) || (filterUndefined && element === undefined) || (filterZero && element === 0) || (filterEmptyString && element === '') ) { continue } newArray[newArray.length] = element } return newArray } filter([0, 1, undefined, 2, null, 3, 'four', '']) // [0, 1, 2, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], {filterNull: false}) // [0, 1, 2, null, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], {filterUndefined: false}) // [0, 1, 2, undefined, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], {filterZero: true}) // [1, 2, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], {filterEmptyString: true}) // [0, 1, 2, 3, 'four'] 

इसलिए, हमारा कार्यक्रम केवल छह उपयोग मामलों के साथ काम करता है, लेकिन वास्तव में हम कार्यों के किसी भी संभावित संयोजन का समर्थन करते हैं, और 25 ऐसे संयोजन हैं (यदि मैंने सही गणना की है)।

सामान्य तौर पर, यह काफी सरल अमूर्तता है। लेकिन इसे सरल बनाया जा सकता है। अक्सर ऐसा होता है कि एब्सट्रैक्शन जिसमें नई कार्यक्षमता जोड़ी गई थी, का उपयोग उन मामलों के लिए बहुत सरल किया जा सकता है जो वास्तव में इसका समर्थन करते हैं। दुर्भाग्य से, जैसे ही अमूर्त कुछ का समर्थन करना शुरू करता है (उदाहरण के लिए, { filterZero: true, filterUndefined: false } ) को निष्पादित करना, हम इस कार्यक्षमता को इस तथ्य के कारण दूर करने से डरते हैं कि यह उस पर निर्भर कोड को तोड़ सकता है।

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

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

 //   Array.prototype.filter   function filter(array, filterFn) { let newArray = [] for (let index = 0; index < array.length; index++) { const element = array[index] if (filterFn(element)) { newArray[newArray.length] = element } } return newArray } filter( [0, 1, undefined, 2, null, 3, 'four', ''], el => el !== null && el !== undefined, ) // [0, 1, 2, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], el => el !== undefined) // [0, 1, 2, null, 3, 'four', ''] filter([0, 1, undefined, 2, null, 3, 'four', ''], el => el !== null) // [0, 1, 2, undefined, 3, 'four', ''] filter( [0, 1, undefined, 2, null, 3, 'four', ''], el => el !== undefined && el !== null && el !== 0, ) // [1, 2, 3, 'four', ''] filter( [0, 1, undefined, 2, null, 3, 'four', ''], el => el !== undefined && el !== null && el !== '', ) // [0, 1, 2, 3, 'four'] 

बहुत बढ़िया! यह बहुत आसान हो गया। हमने फ़ंक्शन पर नियंत्रण बदल दिया, filter फ़ंक्शन से फ़ंक्शन को filter करने वाले फ़ंक्शन तक कौन सा तत्व नए सरणी में आता है, यह तय करने के लिए जिम्मेदारी दे रहा है। ध्यान दें कि filter फ़ंक्शन अभी भी अपने आप में एक उपयोगी अमूर्त है, लेकिन अब यह अधिक लचीला है।

लेकिन क्या इस अमूर्तता का पिछला संस्करण इतना बुरा था? शायद नहीं। लेकिन जब से हमने नियंत्रण को बदल दिया है, हम अब और अधिक अनूठे उपयोग मामलों का समर्थन कर सकते हैं:

 filter( [ {name: 'dog', legs: 4, mammal: true}, {name: 'dolphin', legs: 0, mammal: true}, {name: 'eagle', legs: 2, mammal: false}, {name: 'elephant', legs: 4, mammal: true}, {name: 'robin', legs: 2, mammal: false}, {name: 'cat', legs: 4, mammal: true}, {name: 'salmon', legs: 0, mammal: false}, ], animal => animal.legs === 0, ) // [ // {name: 'dolphin', legs: 0, mammal: true}, // {name: 'salmon', legs: 0, mammal: false}, // ] 

बस कल्पना करें कि क्या आपको नियंत्रण उलटा लगाने के बिना इस उपयोग के मामले में समर्थन जोड़ने की आवश्यकता है? हाँ, यह सिर्फ हास्यास्पद होगा।

खराब एपीआई?

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

 //  filter([0, 1, undefined, 2, null, 3, 'four', '']) //  filter( [0, 1, undefined, 2, null, 3, 'four', ''], el => el !== null && el !== undefined, ) 

हां, एक विकल्प स्पष्ट रूप से दूसरे की तुलना में उपयोग करना आसान है। लेकिन नियंत्रण उलटा का एक लाभ यह है कि आप एक एपीआई का उपयोग कर सकते हैं जो आपके पुराने एपीआई को फिर से लागू करने के लिए नियंत्रण उलटा का उपयोग करता है। यह आमतौर पर बहुत सरल है। उदाहरण के लिए:

 function filterWithOptions( array, { filterNull = true, filterUndefined = true, filterZero = false, filterEmptyString = false, } = {}, ) { return filter( array, element => !( (filterNull && element === null) || (filterUndefined && element === undefined) || (filterZero && element === 0) || (filterEmptyString && element === '') ), ) } 

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

और, बस प्रशंसक के लिए:

 function filterByLegCount(array, legCount) { return filter(array, animal => animal.legs === legCount) } filterByLegCount( [ {name: 'dog', legs: 4, mammal: true}, {name: 'dolphin', legs: 0, mammal: true}, {name: 'eagle', legs: 2, mammal: false}, {name: 'elephant', legs: 4, mammal: true}, {name: 'robin', legs: 2, mammal: false}, {name: 'cat', legs: 4, mammal: true}, {name: 'salmon', legs: 0, mammal: false}, ], 0, ) // [ // {name: 'dolphin', legs: 0, mammal: true}, // {name: 'salmon', legs: 0, mammal: false}, // ] 

आप किसी भी स्थिति के लिए विशेष कार्यक्षमता बना सकते हैं जो अक्सर आपके साथ होती है।

वास्तविक जीवन के उदाहरण

तो, यह सरल मामलों में काम करता है, लेकिन क्या यह अवधारणा वास्तविक जीवन के लिए उपयुक्त है? खैर, सबसे अधिक संभावना है कि आप लगातार नियंत्रण उलटा का उपयोग कर रहे हैं। उदाहरण के लिए, फ़ंक्शन Array.prototype.filter व्युत्क्रम नियंत्रण लागू करता है। फ़ंक्शन की तरह Array.prototype.map ।

ऐसे विभिन्न पैटर्न हैं जिनसे आप पहले से ही परिचित हो सकते हैं, और जो नियंत्रण व्युत्क्रम का सिर्फ एक रूप हैं।

यहाँ मेरे दो पसंदीदा पैटर्न हैं जो ये दिखाते हैं कि "कंपाउंड कंपोनेंट्स" और "स्टेट रिड्यूसर" हैं । नीचे इन पैटर्नों को कैसे लागू किया जा सकता है, इसके संक्षिप्त उदाहरण दिए गए हैं।

यौगिक घटक

मान लीजिए कि आप एक Menu घटक बनाना चाहते हैं जिसमें एक Menu खोलने के लिए एक बटन और मेनू आइटम की एक सूची है जो बटन पर क्लिक करने पर प्रदर्शित होगी। फिर, जब आइटम का चयन किया जाता है, तो यह कुछ कार्रवाई करेगा। आमतौर पर, इसे लागू करने के लिए, वे बस सहारा बनाते हैं:

 function App() { return ( <Menu buttonContents={ <> Actions <span aria-hidden>▾</span> </> } items={[ {contents: 'Download', onSelect: () => alert('Download')}, {contents: 'Create a Copy', onSelect: () => alert('Create a Copy')}, {contents: 'Delete', onSelect: () => alert('Delete')}, ]} /> ) } 

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

शायद एक विशेष प्रकार का मेनू आइटम बनाते हैं, उदाहरण के लिए {contents: <hr />} । मुझे लगता है कि यह काम करेगा, लेकिन फिर हमें उन मामलों को संभालना होगा जहां कोई onSelect नहीं है। और ईमानदार होने के लिए, यह एक बहुत ही अजीब एपीआई है।

जब आप इस बारे में सोचते हैं कि उन लोगों के लिए एक अच्छा एपीआई कैसे बनाया जाए, जो कुछ अलग करने की कोशिश कर रहे हैं, if कथन के लिए पहुँचता है, if नियंत्रण को उलटने का प्रयास करें। क्या होगा यदि हम उपयोगकर्ता के लिए मेनू विज़ुअलाइज़ेशन के लिए जिम्मेदारी स्थानांतरित करते हैं? हम प्रतिक्रिया की ताकत का उपयोग करते हैं:

 function App() { return ( <Menu> <MenuButton> Actions <span aria-hidden>▾</span> </MenuButton> <MenuList> <MenuItem onSelect={() => alert('Download')}>Download</MenuItem> <MenuItem onSelect={() => alert('Copy')}>Create a Copy</MenuItem> <MenuItem onSelect={() => alert('Delete')}>Delete</MenuItem> </MenuList> </Menu> ) } 

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

आप यहां इस पैटर्न के बारे में अधिक पढ़ सकते हैं। रयान फ्लोरेंस को धन्यवाद, जिन्होंने मुझे यह सिखाया।

स्टेट रिड्यूसर

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

Downshift पीछे तर्क ने सुझाव दिया कि पसंद किए जाने के बाद, मेनू बंद होना चाहिए। एक लाइब्रेरी उपयोगकर्ता जिसे अपनी कार्यक्षमता को बदलने की आवश्यकता थी, ने प्रोप closeOnSelection जोड़ने का सुझाव दिया। मैंने इस प्रस्ताव को अस्वीकार कर दिया, क्योंकि एक बार जब मैं पहले से ही एप्रोपलाॅस की ओर जाता था , और इससे बचना चाहता था।

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

Downshift लाइब्रेरी का उपयोग करने का एक उदाहरण ताकि उपयोगकर्ता चयनित आइटम पर क्लिक करने के बाद मेनू को बंद न करे:

 function stateReducer(state, changes) { switch (changes.type) { case Downshift.stateChangeTypes.keyDownEnter: case Downshift.stateChangeTypes.clickItem: return { ...changes, //     Downshift   //       isOpen  highlightedIndex //      isOpen: state.isOpen, highlightedIndex: state.highlightedIndex, } default: return changes } } // ,   // <Downshift stateReducer={stateReducer} {...restOfTheProps} /> 

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

रेंडर प्रॉप्स

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

चेतावनी

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

आइए, हमारे दूरगामी उदाहरण पर वापस आते हैं:

 //   Array.prototype.filter   function filter(array) { let newArray = [] for (let index = 0; index < array.length; index++) { const element = array[index] if (element !== null && element !== undefined) { newArray[newArray.length] = element } } return newArray } // : filter([0, 1, undefined, 2, null, 3, 'four', '']) // [0, 1, 2, 3, 'four', ''] 

क्या होगा अगर यह सब हमें filter फ़ंक्शन से चाहिए? और हमें कभी भी ऐसी स्थिति का सामना नहीं करना पड़ा जब हमें null और undefined अलावा कुछ भी फ़िल्टर करने की आवश्यकता होगी? इस मामले में, एकल उपयोग के मामले में नियंत्रण उलटा जोड़ने से कोड को जटिल किया जाएगा और बहुत अधिक लाभ नहीं होगा।

किसी भी अमूर्त के साथ के रूप में, AHA प्रोग्रामिंग के सिद्धांत को लागू करने और जल्दबाजी के सार से बचने के लिए सावधान रहें!

निष्कर्ष

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

यदि आप चाहें, तो आप CodeSandbox पर एक लेख से एक उदाहरण के साथ खेल सकते हैं।

गुड लक और आपका ध्यान के लिए धन्यवाद!

पुनश्च। अगर आपको यह लेख अच्छा लगा हो, तो आप इस बात का आनंद ले सकते हैं: youtube Kent C Dodds - Simply React