क्या हुक रिएक्ट में बदल जाते हैं?

चूंकि हुक रिएक्ट में दिखाई दिए, इसलिए कई सवाल हैं कि क्या वे Redux की जगह ले सकते हैं।

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



रिएक्ट हुक और रेडक्स के लिए मेरे दृष्टिकोण को समझाने के लिए, मैं सबसे पहले उन परिस्थितियों के बारे में बात करना चाहूंगा जिनमें आमतौर पर रेडक्स का उपयोग किया जाता है।

Redux क्या है?

Redux एक ऐसी लाइब्रेरी है, जो अनुमानित एप्लिकेशन स्टेट स्टोरेज को लागू करती है। यह एक वास्तुकला भी है जो प्रतिक्रिया के साथ मूल रूप से एकीकृत होती है।

यहाँ Redux की मुख्य ताकतें हैं:

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

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

रिएक्ट हुक क्या हैं?

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

हुक की मुख्य शक्तियों में निम्नलिखित हैं:

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

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

यदि आप हुक के साथ प्रतिक्रिया-redux एपीआई जैसे उपकरण का उपयोग करते हैं , या प्रतिक्रिया का उपयोग करें , तो आपको पता चलेगा कि क्या चुनने का कोई कारण नहीं है - हुक या रेडक्स। आप इन तकनीकों का संयोजन और संयोजन दोनों का उपयोग कर सकते हैं।

हुक की जगह क्या?

हुक एपीआई के आगमन के बाद, मैंने निम्नलिखित तकनीकों का उपयोग करना बंद कर दिया:

• कक्षा आधारित घटक।
• रेंडर-प्रोप पैटर्न।

हुक की जगह क्या नहीं है?

मैं अभी भी अक्सर निम्नलिखित तकनीकों का उपयोग करता हूं:

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

हुक का उपयोग कब करें?

हर आवेदन में और हर घटक में Redux का उपयोग करने का प्रयास करने की आवश्यकता नहीं है। यदि आपकी परियोजना में एक दृश्य घटक शामिल है, अगर यह डेटा को नहीं बचाता है और वहां से डेटा लोड नहीं करता है, यदि अतुल्यकालिक I / O संचालन इसमें नहीं किए जाते हैं, तो मैं इस परियोजना को जटिल बनाने के लिए एक योग्य कारण के बारे में नहीं सोच सकता।

उन्हीं घटकों के बारे में कहा जा सकता है जिनमें निम्नलिखित विशेषताएं हैं:

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

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

 import React, { useState } from 'react'; import t from 'prop-types'; import TextField, { Input } from '@material/react-text-field'; const noop = () => {}; const Holder = ({  itemPrice = 175,  name = '',  email = '',  id = '',  removeHolder = noop,  showRemoveButton = false, }) => {  const [nameInput, setName] = useState(name);  const [emailInput, setEmail] = useState(email); const setter = set => e => {    const { target } = e;    const { value } = target;    set(value);  }; return (    <div className="row">      <div className="holder">        <div className="holder-name">          <TextField label="Name">            <Input value={nameInput} onChange={setter(setName)} required />          </TextField>        </div>        <div className="holder-email">          <TextField label="Email">            <Input              value={emailInput}              onChange={setter(setEmail)}              type="email"              required            />          </TextField>        </div>        {showRemoveButton && (          <button            className="remove-holder"            aria-label="Remove membership"            onClick={e => {              e.preventDefault();              removeHolder(id);            }}          >            ×          </button>        )}      </div>      <div className="line-item-price">${itemPrice}</div>      <style jsx>{cssHere}</style>    </div>  ); }; Holder.propTypes = {  name: t.string,  email: t.string,  itemPrice: t.number,  id: t.string,  removeHolder: t.func,  showRemoveButton: t.bool, }; export default Holder; 

name और email इनपुट फ़ील्ड के संक्षिप्त उपयोग की स्थिति को नियंत्रित करने के लिए यहां useState उपयोग किया जाता है:

 const [nameInput, setName] = useState(name); const [emailInput, setEmail] = useState(email); 

आप देख सकते हैं कि Redux की संपत्तियों में अभी भी removeHolder की एक removeHolder है। जैसा कि पहले ही उल्लेख किया गया है, प्रौद्योगिकियों का संयोजन और संयोजन पूरी तरह से सामान्य है।

ऐसी समस्याओं को हल करने के लिए एक घटक की स्थानीय स्थिति का उपयोग करना हमेशा अच्छा लगता था, लेकिन रिएक्ट हुक से पहले मुझे किसी भी मामले में, Redux-Storage में घटक डेटा को सहेजना और गुणों से राज्य प्राप्त करना चाहिए।

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

चूंकि मैंने पहले से ही अपने सभी कम या ज्यादा जटिल अनुप्रयोगों में Redux का उपयोग किया है, इसलिए घटकों के घटकों की स्थिति को संग्रहीत करने के लिए प्रौद्योगिकी की पसंद ने मुझे बहुत सोचा नहीं था। मैंने लगभग सभी मामलों में Redux का उपयोग किया।

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

Redux का उपयोग कब करें?

राज्य प्रबंधन के संबंध में एक और सामान्य प्रश्न है: “क्या मुझे Redux रिपॉजिटरी में पूरी तरह से सब कुछ डालने की आवश्यकता है? यदि मैं ऐसा नहीं करता हूं, तो क्या यह TTD तंत्रों का उपयोग करके अनुप्रयोगों को डीबग करने की क्षमता का उल्लंघन करेगा? ”

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

दूसरे शब्दों में, आप सुरक्षित रूप से Redux का उपयोग कर सकते हैं, लेकिन इसके लिए कुछ कारण होना चाहिए। घटकों में Redux सुविधाओं का उपयोग उचित हो सकता है यदि घटक निम्नलिखित विशेषताओं में भिन्न हों:

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

यहाँ एक और उदाहरण TDDDay एप्लिकेशन से लिया गया है:

 import React from 'react'; import { useDispatch, useSelector } from 'react-redux'; import { compose } from 'ramda'; import page from '../../hocs/page.js'; import Purchase from './purchase-component.js'; import { addHolder, removeHolder, getHolders } from './purchase-reducer.js'; const PurchasePage = () => {  //      // mapStateToProps  mapDispatchToProps  const dispatch = useDispatch();  const holders = useSelector(getHolders); const props = {    //           //    dispatch.    addHolder: compose(      dispatch,      addHolder    ),    removeHolder: compose(      dispatch,      removeHolder    ),    holders,  }; return <Purchase {...props} />; }; // `page` -    ,    //        . export default page(PurchasePage); 

यह दस्तावेज़ DOM से संबंधित नहीं है। यह एक प्रस्तुति घटक है। यह हुक समर्थन के साथ प्रतिक्रिया- Redux एपीआई का उपयोग करके Redux से जुड़ा हुआ है।

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

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

रिएक्ट सस्पेंस एपीआई, भविष्य में, किसी राज्य में डेटा स्टोर करने और उससे लोड करने पर काम में आ सकता है। हमें इसकी रिलीज़ की प्रतीक्षा करने और यह देखने की आवश्यकता है कि क्या यह Redux डेटा को सहेजने और लोड करने के लिए टेम्प्लेट को बदल सकता है। Redux हमें बाकी घटक तर्क से स्पष्ट रूप से दुष्प्रभावों को अलग करने की अनुमति देता है, जबकि हमें एक विशेष तरीके से I / O सेवाओं के साथ काम करने की आवश्यकता नहीं है। (कारण है कि मैं redux-thunk मिडिलवेयर के लिए redux-saga लाइब्रेरी को प्राथमिकता देता हूं प्रभाव अलगाव है)। इस परिदृश्य में Redux के साथ प्रतिस्पर्धा करने के लिए, प्रतिक्रिया API को प्रभाव अलगाव प्रदान करने की आवश्यकता होगी।

Redux आर्किटेक्चर है

Redux एक राज्य प्रबंधन पुस्तकालय की तुलना में बहुत अधिक (और अक्सर बहुत कम) है। यह फ्लक्स वास्तुकला का एक सबसेट भी है, जो बहुत अधिक सख्ती से परिभाषित करता है कि राज्य परिवर्तन कैसे लागू होते हैं। Redux वास्तुकला के बारे में यहाँ और पढ़ें।

मैं अक्सर उन मामलों में Redux शैली में निर्मित reducers का उपयोग करता हूं जब मुझे घटक की जटिल स्थिति को बनाए रखने की आवश्यकता होती है, लेकिन Redux पुस्तकालय का उपयोग करने की आवश्यकता नहीं होती है। इसके अलावा, मैं Node.js अनुप्रयोगों में कार्रवाई भेजने के लिए Redux (और यहां तक ​​कि Autodux और Redux -saga जैसे Redux टूल) की भावना में बनाई गई क्रियाओं का उपयोग करता हूं। हालाँकि, मैं Redux को ऐसे अनुप्रयोगों में आयात नहीं करता।

Redux परियोजना हमेशा एक वास्तुकला और एक पुस्तकालय की तुलना में स्वैच्छिक समझौतों का एक सेट रही है। वास्तव में, Redux के मूल कार्यान्वयन को कोड की एक दर्जन पंक्तियों में शाब्दिक रूप से रखा जा सकता है।

यह उन लोगों के लिए अच्छी खबर होगी, जो हुक के साथ घटकों के स्थानीय राज्य का अधिक बार उपयोग करना चाहते हैं और रेडक्स के लिए सब कुछ नहीं बांधते हैं।

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

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

क्यू एंड ए

यदि Redux सभी एप्लिकेशन डेटा का प्रबंधन नहीं करता है तो क्या निर्धारित होता है?

नहीं, यह टूटा नहीं है। वास्तव में, Redux का उपयोग करने से कोई परियोजना निर्धारित नहीं होती है। लेकिन समझौते हैं। यदि आप चाहते हैं कि आपका Redux राज्य निर्धारक हो, तो शुद्ध कार्यों का उपयोग करें। यह उन स्थितियों पर लागू होता है जिनमें यह आवश्यक है कि स्थानीय घटकों की अस्थायी स्थिति का निर्धारण किया जाए।

▍ क्या Redux लाइब्रेरी को विश्वसनीय डेटा के एकल स्रोत की भूमिका निभानी चाहिए?

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

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

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

यदि आप Redux राज्य में कुछ डेटा रखते हैं, तो आपको Redux राज्य के इस डेटा को हमेशा पढ़ना चाहिए। Redux रिपॉजिटरी में जो कुछ भी है, उसके लिए यह रिपॉजिटरी विश्वसनीय डेटा का एकमात्र स्रोत होना चाहिए।

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

▍ क्या मुझे रिएक्शन-रेडक्स से कनेक्ट फ़ंक्शन का उपयोग करने की आवश्यकता है, या क्या हुक का उपयोग करना बेहतर है?

यह बहुत कुछ पर निर्भर करता है। connect फ़ंक्शन बार-बार उपयोग के लिए उपयुक्त एक उच्च-क्रम घटक बनाता है, और हुक एकल घटक के साथ एकीकरण के लिए अनुकूलित होते हैं।

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

 import { connect } from 'react-redux'; import RequiresPermission from './requires-permission-component'; import { userHasPermission } from '../../features/user-profile/user-profile-reducer'; import curry from 'lodash/fp/curry'; const requiresPermission = curry(  (NotPermittedComponent, { permission }, PermittedComponent) => {    const mapStateToProps = state => ({      NotPermittedComponent,      PermittedComponent,      isPermitted: userHasPermission(state, permission),    });    return connect(mapStateToProps)(RequiresPermission);  }, ); export default requiresPermission; 

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

 import NextError from 'next/error'; import compose from 'lodash/fp/compose'; import React from 'react'; import requiresPermission from '../requires-permission'; import withFeatures from '../with-features'; import withAuth from '../with-auth'; import withEnv from '../with-env'; import withLoader from '../with-loader'; import withLayout from '../with-layout'; export default compose(  withEnv,  withAuth,  withLoader,  withLayout(),  withFeatures,  requiresPermission(() => <NextError statusCode={404} />, {    permission: 'admin',  }), ); 

इसका उपयोग कैसे करें:

 import compose from 'lodash/fp/compose'; import adminPage from '../HOCs/admin-page'; import AdminIndex from '../features/admin-index/admin-index-component.js'; export default adminPage(AdminIndex); 

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

दूसरे शब्दों में, मैं कह सकता हूं कि मेरा मानना ​​है कि connect के विकास के दौरान कोड की संक्षिप्तता की दिशा में बहुत काम किया गया था, लेकिन परिणामी कोड न तो विशेष रूप से पठनीय है, न ही विशेष रूप से सुविधाजनक है। अगर मुझे कई घटकों के साथ काम करने की आवश्यकता नहीं है, तो मैं बहुत अधिक सुविधाजनक हुक एपीआई के लिए असुविधाजनक connect एपीआई को प्राथमिकता देना चाहूंगा, यहां तक ​​कि यह मानते हुए कि इससे कोड की मात्रा में वृद्धि होगी।

Leton यदि एक सिंगलटन को एक विरोधी पैटर्न माना जाता है और Redux एक सिंगलटन है, तो क्या इसका मतलब यह है कि Redux एक एंटी-पैटर्न है?

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

परिणाम

क्या Redux रिएक्ट हुक की जगह लेता है? हुक बहुत बढ़िया हैं, लेकिन वे Redux की जगह नहीं लेते हैं।

हमें उम्मीद है कि यह सामग्री आपकी प्रतिक्रिया परियोजनाओं के लिए एक राज्य प्रबंधन मॉडल चुनने में आपकी सहायता करेगी।

प्रिय पाठकों! क्या आपने ऐसी स्थितियों का सामना किया है जिनमें रिएक्ट हुक Redux की जगह ले सकता है?