हम FRP का उपयोग करके रिएक्ट हुक को पंप करते हैं

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

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

इनपुट के लिए एक निश्चित क्षेत्र है, सशर्त रूप से, एक नाम। और क्लिक करके एक बटन है जिस पर हमें दर्ज नाम (एक निश्चित खोज) के साथ सर्वर से अनुरोध करना चाहिए। ऐसा लगता है कि यह आसान हो सकता है? हालांकि, समाधान स्पष्ट से बहुत दूर है। पहला अनुभवहीन कार्यान्वयन:

const App = () => { const [name, setName] = useState(''); const [request, setRequest] = useState(); const [result, setResult] = useState(); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => setRequest(name)}/> { result && <div>Result: { result }</div> } </div>; } 

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

 const App = () => { const [name, setName] = useState(''); const [request, setRequest] = useState(); const [result, setResult] = useState(); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => setRequest(!request)}/> { result && <div>Result: { result }</div> } </div>; } 

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

आइए इस उदाहरण को थ्रेड एब्स्ट्रक्शन का उपयोग करके एक सैद्धांतिक स्तर पर देखें। उपयोगकर्ता इंटरफेस की स्थिति का वर्णन करने के लिए यह बहुत सुविधाजनक है। तो, हमारे पास दो धाराएँ हैं: डेटा पाठ क्षेत्र (नाम $) में दर्ज किया गया है, और फॉर्म के सबमिट बटन पर क्लिक की एक धारा ($ क्लिक करें)। उनसे हमें सर्वर से अनुरोधों की एक तीसरी, संयुक्त धारा बनाने की आवश्यकता है।

 name$ __(C)____(Ca)_____(Car)____________________(Carl)___________ click$ ___________________________()______()________________()_____ request$ ___________________________(Car)___(Car)_____________(Carl)_ 

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

हमारे मामले में, क्लिक $ एक शुद्ध संकेत है: यह मायने नहीं रखता है कि कौन सा मूल्य इसके माध्यम से बहता है (अपरिभाषित / सत्य / घटना / जो भी हो), यह तब होता है जब यह महत्वपूर्ण होता है। केस का नाम $
इसके विपरीत: किसी भी तरह से इसके परिवर्तन प्रणाली में किसी भी तरह के बदलाव नहीं करते हैं, लेकिन हमें कुछ बिंदु पर इसके अर्थ की आवश्यकता हो सकती है। और इन दो धाराओं से हमें तीसरा बनाने की जरूरत है, पहली बार से, दूसरी - मूल्य से।

Rxjs के मामले में, हमारे पास इसके लिए लगभग तैयार ऑपरेटर है:

 const names$ = fromEvent(...); const click$ = fromEvent(...); const request$ = click$.pipe(withLatestFrom(name$), map(([name]) => fromPromise(fetch(...)))); 

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

 import useMrr from 'mrr/hooks'; const App = props => { const [state, set] = useMrr(props, { result: [name => fetch('//example.api/' + name).then(data => data.result), '-name', 'submit'], }); return <div> <input value={state.name} onChange={set('name')}/> <input type="submit" value="Check" onClick={set('submit')}/> { state.result && <div>Result: { state.result }</div> } </div>; } 

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

हमें वांछित व्यवहार मिला, संक्षेप में, एक पंक्ति में। लेकिन यह सिर्फ संक्षिप्तता नहीं है। आइए प्राप्त परिणामों की अधिक विस्तार से तुलना करें, और सबसे पहले इस तरह के पैरामीटर के संबंध में पठनीयता और परिणामी कोड की स्पष्टता।

Mrr में, आपको "टेम्पलेट" से "तर्क" का लगभग पूरा पृथक्करण मिल जाएगा: आपको JSX में किसी भी जटिल अनिवार्य हैंडलर को लिखना नहीं होगा। सब कुछ अत्यंत घोषणात्मक है: हम बस DOM इवेंट को संबंधित स्ट्रीम में मैप करते हैं, व्यावहारिक रूप से रूपांतरण के बिना (इनपुट फ़ील्ड के लिए, मान e.target.value स्वचालित रूप से निकाला जाता है, जब तक कि आप अन्यथा निर्दिष्ट न करें), और पहले से ही उपयोग में संरचना संरचना में हम आधार कैसे बनते हैं। सहायक। इस प्रकार, दोनों तुल्यकालिक और अतुल्यकालिक डेटा परिवर्तनों के मामले में, हम हमेशा आसानी से ट्रैक कर सकते हैं कि हमारा मूल्य कैसे बनता है।

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

 result: [(name, surname) => fetch(...), '-name', '-surname', 'submit'], 

और Rx में आपको एक नक्शे के साथ एक और withLatestFrom को खोदना होगा, या पहले नाम और उपनाम को एक स्ट्रीम में संयोजित करना होगा।

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

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

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

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

 const App = () => { const [request, makeRequest] = useState(); const [name, setName] = useState(''); const [result, setResult] = useState(false); const [clicks, setClicks] = useState(0); useEffect(() => { fetch('//example.api/' + name).then((data) => { setResult(data.result); }); }, [request]); return <div> <input onChange={e => setName(e.target.value)}/> <input type="submit" value="Check" onClick={() => { makeRequest(!request); setClicks(clicks + 1); }}/><br /> Clicked: { clicks } </div>; } 

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

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

Mrr पर:

 const App = props => { const [state, set] = useMrr(props, { $init: { clicks: 0, }, isValid: [name => fetch('//example.api/' + name).then(data => data.isValid), '-name', 'makeRequest'], clicks: [a => a + 1, '-clicks', 'makeRequest'], }); return <div> <input onChange={set('name')}/> <input type="submit" value="Check" onClick={set('makeRequest')}/> </div>; } 

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

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

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

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

 const App = props => { const [state, set] = useMrr(props, { $log: true, $init: { clicks: 0, }, isValid: [name => fetch('//example.api/' + name).then(data => data.isValid), '-name', 'makeRequest'], clicks: [a => a + 1, '-clicks', 'makeRequest'], }); ... 

उसके बाद, धाराओं में सभी परिवर्तन कंसोल में प्रदर्शित किए जाएंगे। पूरे राज्य तक पहुँचने के लिए (यानी, सभी थ्रेड्स के वर्तमान मूल्य), एक छद्म-धारा $ स्थिति है:

 a: [({ name, click, result }) => { ... }, '$state', 'click'], 

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

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

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

निष्कर्ष

नए रिएक्ट हुक महान हैं और हमारे जीवन को सरल बनाते हैं, लेकिन उनके पास कुछ खामियां हैं जो एक उच्च-स्तरीय सामान्य प्रयोजन हुक (राज्य प्रबंधन) को ठीक कर सकती हैं। कार्यात्मक-प्रतिक्रियाशील mrr पुस्तकालय से UseMrr प्रस्तावित किया गया था और इस तरह माना जाता था।

समस्याएं और उनके समाधान:

• प्रत्येक रेंडर पर डेटा की अनावश्यक कमी (पुश-आधारित प्रतिक्रिया के कारण mrr में अनुपस्थित हैं)
• जब राज्य में परिवर्तन UI में परिवर्तन नहीं करता है तो अतिरिक्त रेंडरिंग
• अतुल्यकालिक रूपांतरण (तुल्यकालिक लोगों की तुलना में) के साथ खराब कोड पठनीयता। Mrr में, अतुल्यकालिक कोड पठनीयता और अभिव्यक्ति में तुल्यकालिक से नीच नहीं है। हाल ही के लेख में mrr पर उपयोग के बारे में चर्चा की गई अधिकांश समस्याएं मूल रूप से असंभव हैं
• अनिवार्य हैंडलर जो हमेशा के लिए उपलब्ध नहीं होते हैं (श्री में वे स्वचालित रूप से कैश किए जाते हैं, लगभग हमेशा कैश किया जा सकता है, घोषणा)
• एक ही समय में useState और useReducer का उपयोग कर अजीब कोड बना सकते हैं
• समय के साथ प्रवाह को बदलने के लिए उपकरणों की कमी (बहस, गला घोंटना, दौड़ की स्थिति)

कई बिंदुओं पर, कोई यह तर्क दे सकता है कि उन्हें कस्टम हुक द्वारा हल किया जा सकता है। लेकिन यह वही है जो प्रस्तावित किया जा रहा है, लेकिन इसके बजाय अलग-अलग कार्यान्वयन के लिए, प्रत्येक अलग कार्य के लिए, एक समग्र, सुसंगत समाधान प्रस्तावित है।

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

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

जो लोग रुचि रखते हैं, वे इस विषय पर 28 मार्च को कीवीज पर एक प्रस्तुति देख सकते हैं।