कार्यात्मक प्रथाओं और सामने: मोनडर्स और फंक्शनलर्स

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



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

तो, चलिए राज्यों को संभालते हुए शुरू करते हैं। उसी समय, मैं आपको बताता हूँ, और यहाँ, सामान्य तौर पर, मोनाड्स और फ़ंक्शनलर्स।

पहचान

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

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

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

सभी उदाहरणों में रिएक्ट लाइब्रेरी और जावास्क्रिप्ट के एक सुपरसेट का उपयोग करके कोड उदाहरण होंगे - टाइपस्क्रिप्ट, साथ ही कार्यात्मक प्रोग्रामिंग fp-ts के लिए लाइब्रेरी।

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

  const renderInitial = (...) => ...; const renderPending = (...) => ...; const renderError = (...) => ... ; const renderSuccess = (...) => ... ; return ( {state.subcribers.foldL( renderInitial, renderPending, renderError, renderSuccess, )} ); 

उदाहरण स्पष्ट रूप से दिखाता है कि डेटा मॉडल के प्रत्येक राज्य का अपना कार्य है, और प्रत्येक फ़ंक्शन इसे (संदेश, बटन, आदि) के लिए यूआई का एक टुकड़ा लौटाता है। आगे देखते हुए, मैं कहूंगा कि उदाहरण RemoteData monad का उपयोग करता है।

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

फनकार और मोनाड

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

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

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

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

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

एक श्रेणी में उन वस्तुओं और तीर होते हैं जो उनके बीच निर्देशित होते हैं। किसी श्रेणी की कल्पना करने का सबसे आसान तरीका है:

तीरों की व्यवस्था इसलिए की जाती है कि यदि आपके पास ऑब्जेक्ट A से ऑब्जेक्ट B तक का तीर है और ऑब्जेक्ट B से C तक का तीर है , तो एक तीर होना चाहिए - उनकी संरचना A से C तक है । कार्यों के रूप में तीर के बारे में सोचो; उन्हें आकारिकी भी कहा जाता है। आपके पास एक फ़ंक्शन f जो ए को एक तर्क के रूप में लेता है और बी लौटाता है। एक अन्य फ़ंक्शन g जो बी को एक तर्क के रूप में लेता है और सी। रिटर्न करता है। आप f से g तक परिणाम पारित करके उन्हें जोड़ सकते हैं। हमने सिर्फ एक नए फ़ंक्शन का वर्णन किया है जो ए और रिटर्न सी लेता है। गणित में, इस तरह की रचना को फ़ंक्शन संकेतन के बीच एक छोटे वृत्त द्वारा दर्शाया जाता है: जी: एफ। रचना क्रम पर ध्यान दें - दाएं से बाएं।

गणित में, रचना को दाईं से बाईं ओर निर्देशित किया जाता है। इस मामले में, यह मदद करता है यदि आप जी “एफ को" जी के बाद एफ "के रूप में पढ़ते हैं।

 -—   A  B f :: A -> B -—   B   g :: B -> C -— A  C g . f 

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

1. रचना साहचर्य है (सहकारिता संचालन की एक संपत्ति है जो आपको समान प्राथमिकता के साथ उत्तराधिकार के स्पष्ट संकेत के अभाव में उनके निष्पादन के अनुक्रम को बहाल करने की अनुमति देती है; यह बाईं सहकारिता के बीच अंतर करती है, जहां अभिव्यक्ति का मूल्यांकन बाईं से दाईं ओर, और दाईं से बाईं ओर समरूपता का मूल्यांकन किया जाता है। संगत ऑपरेटरों को बाएं-सहयोगी और दाएं-सहयोगी कहा जाता है। यदि आपके पास तीन आकार (तीर), f, g और h हैं, जिन्हें व्यवस्थित किया जा सकता है (अर्थात, उनके प्रकार एक दूसरे के अनुरूप हैं) समूह के लिए कोष्ठकों की जरूरत है उन्हें। गणित के अनुसार, इस रूप में लिखा है h ◦ (g ◦ f) = (h ◦ g) ◦ f = h ◦ g ◦ f (ज ◦ छ) ◦ च = ज ◦ जी ◦ च
2. प्रत्येक वस्तु ए के लिए एक तीर है, जो रचना की एक इकाई होगी। यह तीर एक वस्तु से ही है। रचना की एक इकाई होने का मतलब है कि किसी भी तीर के साथ एक इकाई की रचना करना, जो या तो ए पर शुरू होता है या क्रमशः ए पर समाप्त होता है, रचना उसी तीर को वापस करती है। किसी वस्तु A के इकाई तीर को आईडीए (A पर इकाई) कहा जाता है। गणितीय संकेतन में, यदि f A से B तक जाता है, तो f ◦ idA = f
   
   फ़ंक्शंस के साथ काम करने के लिए, एक एकल तीर को एक समान फ़ंक्शन के रूप में लागू किया जाता है, जो बस अपना तर्क देता है।

अब हम विचार कर सकते हैं कि श्रेणी सिद्धांत में एक फ़नकार क्या है।

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

शायद कंटेनर के लिए एक फ़नकार के कार्यान्वयन के एक उदाहरण पर विचार करें, जो कि "मूल्य जो अनुपस्थित हो सकता है" का विचार है।

 const compose = <A, B, C>( f: (a: A) => B, g: (b: B) => C, ): (a: A) => C => (a: A) => g(f(a)); //  Maybe: type Nothing = Readonly<{ tag: 'Nothing' }>; type Just<A> = Readonly<{ tag: 'Just'; value: A }>; export type Maybe<A> = Nothing | Just<A>; const nothing: Nothing = { tag: 'Nothing' }; const just = <A>(value: A): Just<A> => ({ tag: 'Just', value }); //    Maybe: const fmap = <A, B>(f: (a: A) => B) => (fa: Maybe<A>): Maybe<B> => { switch (fa.tag) { case 'Nothing': return nothing; case 'Just': return just(f(fa.value)); } }; //  1: fmap id === id namespace Laws { console.log( fmap(id)(just(42)), id(just(42)), ); // => { tag: 'Just', value: 42 } //  2: fmap f ◦ fmap g === fmap (f ◦ g) const f = (a: number): string => `Got ${a}!`; const g = (s: string): number => s.length; console.log( compose(fmap(f), fmap(g))(just(42)), fmap(compose(f, g))(just(42)), ); // => { tag: 'Just', value: 7 } } 

fmap विधि को दो तरफ से देखा जा सकता है:

1. एक शुद्ध कार्य को "कंटेनरीकृत" मान पर लागू करने के तरीके के रूप में;
2. एक शुद्ध कार्य "कंटेनर संदर्भ में बढ़ा" करने के तरीके के रूप में।

वास्तव में, अगर इंटरफ़ेस में कोष्ठक थोड़े अलग हैं, तो हम fmap फ़ंक्शन के हस्ताक्षर प्राप्त कर सकते हैं:

 const fmap: <A, B>(f: (a: A) => B) => ((ma: Maybe<A>) => Maybe<B>); 

इंटरफ़ेस परिभाषित करने के बाद:

 type Function1<Domain, Codomain> = (a: Domain) => Codomain; 

हमें fmap की परिभाषा fmap :

 const fmap: <A, B>(f: (a: A) => B) => Function1<Maybe<A>, Maybe<B>>; 

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

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

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

भिक्षुओं को बेहतर समझने के लिए, निम्नलिखित महत्वपूर्ण अवधारणाओं को सीखना चाहिए।

इकाई। मौद्रिक संचालन के लिए एक सार इंटरफ़ेस प्रदान करता है
मोनाडिक प्रकार। इस इंटरफ़ेस का विशिष्ट कार्यान्वयन

लेकिन भविष्य के लेखों में एक फ़ंक्टर और अन्य श्रेणीबद्ध निर्माणों के इन गुणों के आवेदन के व्यावहारिक उदाहरण।