इस उदाहरण का उत्तर है: https://github.com/facebook/react/issues/14920#issuecomment -466145690

कोडसैंडबॉक्स

यह एक अनियंत्रित चेकबॉक्स घटक है जो प्रारंभिक रेंडर पर अनिश्चित स्थिति सेट करने के लिए defaultIndeterminate प्रोप लेता है (जो केवल जेएस में रेफरी का उपयोग करके किया जा सकता है क्योंकि कोई indeterminate तत्व विशेषता नहीं है)। इस प्रोप का उद्देश्य defaultValue जैसा व्यवहार करना है, जहां इसका मूल्य केवल प्रारंभिक रेंडर पर उपयोग किया जाता है।

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

मुझे इस और मामले के प्रकार के बीच अंतर करने का कोई तरीका नहीं दिख रहा है कि नियम पकड़ने के लिए _meant_ है, लेकिन यह बहुत अच्छा होगा यदि अंतिम नियम दस्तावेज में सुझाए गए कामकाज शामिल हो सकते हैं। मैं

पुन: https://github.com/facebook/react/issues/14920#issuecomment -466144466

@billyjanitsch इसके बजाय क्या यह काम करेगा? https://codesandbox.io/s/jpx1pmy7ry

मैंने useState को indeterminate useState लिए जोड़ा जो defaultIndeterminate प्रारंभ हो जाता है। तब प्रभाव [indeterminate] को तर्क के रूप में स्वीकार करता है। आप वर्तमान में इसे नहीं बदलते हैं - लेकिन अगर आपने इसे बाद में किया, तो मुझे लगता है कि यह भी काम करेगा? तो कोड भविष्य के संभावित उपयोग के मामले को थोड़ा बेहतर होने की उम्मीद करता है।

तो मुझे यह निम्नलिखित (किनारे?) मामला मिला जहां मैं कुछ एचटीएमएल पास करता हूं और अपने घटक (कुछ संपादकीय सामग्री) को अपडेट करने के लिए dangerouslySetInnerHtml साथ इसका उपयोग करता हूं।
मैं html प्रोप का उपयोग नहीं कर रहा हूं, लेकिन रेफरी जहां मैं कुछ जादू करने के लिए ref.current.querySelectorAll का उपयोग कर सकता हूं।
अब मैं जोड़ने की जरूरत है html में मेरी निर्भरता को useEffect भले ही मैं स्पष्ट रूप से इसे का उपयोग नहीं कर रहा हूँ। क्या यह एक उपयोग का मामला है जहां मुझे वास्तव में नियम को अक्षम करना चाहिए?

विचार संपादकीय सामग्री से सभी लिंक क्लिक को रोकना और कुछ विश्लेषणों को ट्रैक करना या अन्य प्रासंगिक सामान करना है।

यह एक वास्तविक घटक से पानी पिलाया गया उदाहरण है:
https://codesandbox.io/s/8njp0pm8v2

मैं प्रतिक्रिया-रेडक्स का उपयोग कर रहा हूं, इसलिए mapDispatchToProps से प्रॉप्स में एक्शन क्रिएटर को पास करते समय, और हुक में उस एक्शन क्रिएटर का उपयोग करते हुए, मुझे exhaustive-deps चेतावनी मिलती है।

तो मैं स्पष्ट रूप से निर्भरता सरणी में रेडक्स क्रिया जोड़ सकता हूं, लेकिन क्योंकि रेडक्स क्रिया एक फ़ंक्शन है और कभी नहीं बदलती है, यह असफल सही है?

const onSubmit = React.useCallback(
  () => {
    props.onSubmit(emails);
  },
  [emails, props]
);

मुझे उम्मीद है कि लिंट डिपो को [emails, props.onSubmit] ठीक करेगा, लेकिन अभी यह हमेशा डिपो को [emails, props] में ठीक करता है।

1. एक कोडसैंडबॉक्स एक न्यूनतम कोड उदाहरण प्रदर्शित करता है जो अभी भी आपके इरादे को व्यक्त करता है ("फू बार" नहीं बल्कि वास्तविक यूआई पैटर्न जिसे आप लागू कर रहे हैं)।

https://codesandbox.io/s/xpr69pllmz

1. उपयोगकर्ता द्वारा किए जाने वाले कदमों की व्याख्या और आप स्क्रीन पर क्या देखने की उम्मीद करते हैं।

एक उपयोगकर्ता एक ईमेल जोड़ देगा और उन ईमेल को ऐप में आमंत्रित करेगा। मैं जानबूझकर शेष UI को केवल button हटा देता हूं क्योंकि वे मेरी समस्या के लिए अप्रासंगिक हैं।

1. आपके हुक/घटक के इच्छित API की व्याख्या।

मेरे घटक में एक एकल प्रोप है, onSubmit: (emails: string[]) => void । जब कोई उपयोगकर्ता फॉर्म जमा करेगा तो इसे emails स्थिति के साथ बुलाया जाएगा।

संपादित करें: https://github.com/facebook/react/issues/14920#issuecomment -467494468 में उत्तर दिया गया

ऐसा इसलिए है क्योंकि तकनीकी रूप से props.foo() props को this से foo कॉल के रूप में पास करता है। तो foo परोक्ष रूप से props पर निर्भर हो सकता है। हालांकि हमें इस मामले के लिए एक बेहतर संदेश की आवश्यकता होगी। सबसे अच्छा अभ्यास हमेशा विनाशकारी होता है।

कोडसैंडबॉक्स

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

नमस्ते,

सुनिश्चित नहीं है कि यहां मेरे कोड में क्या गलत है:

const [client, setClient] = useState(0);

useEffect(() => {
    getClient().then(client => setClient(client));
  }, ['client']);

मुझे React Hook useEffect has a complex expression in the dependency array. Extract it to a separate variable so it can be statically checked

@joelmoss @sylvainbaronnet मैं आपकी प्रतिक्रिया की सराहना

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

मेरा मानना ​​​​है कि कोड के रूप में त्रुटि नहीं होनी चाहिए। यह अभी लाइन 35 पर कहता है कि setLastName को सरणी में शामिल किया जाना चाहिए। इसके बारे में क्या करना है इस पर कोई विचार? क्या मैं कुछ अप्रत्याशित कर रहा हूँ?

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

यदि आपको अभी भी अधिक जानकारी की आवश्यकता है, तो कोडसैंडबॉक्स बनाने में प्रसन्नता हो रही है। धन्यवाद

@joelmoss मुझे लगता है कि मेरा

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

@gaearon मैं समझता हूं कि यह समझ में आता है, वास्तव में यह मेरे लिए काम करता है क्योंकि मैं क्यों हासिल करना चाहता था:

यदि आप एक प्रभाव चलाना चाहते हैं और इसे केवल एक बार (माउंट और अनमाउंट पर) साफ करना चाहते हैं, तो आप एक खाली सरणी ([]) को दूसरे तर्क के रूप में पास कर सकते हैं।

स्पष्टीकरण के लिए बहुत-बहुत धन्यवाद। (और ऑफ टॉपिक के लिए खेद है)

मैं जो कार्यान्वित कर रहा हूं उसका कोड संस्करण यहां दिया गया है। यह ज्यादा नहीं दिखता है, लेकिन पैटर्न मेरे असली कोड के साथ 100% समान है।

https://codesandbox.io/s/2x4q9rzwmp?fontsize=14

• उपयोगकर्ता द्वारा किए जाने वाले कदमों की व्याख्या और आप स्क्रीन पर क्या देखने की उम्मीद करते हैं।

इस उदाहरण में सब कुछ बढ़िया काम करता है! लिटर मुद्दे को छोड़कर।

• आपके हुक/घटक के इच्छित API की व्याख्या।

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

सैंडबॉक्स कोड पर इसे चलाते समय मुझे लिंटर से यही मिलता है:

25:5   warning  React Hook useEffect has a missing dependency: 'fetchPodcastsFn'. Either include it or remove the dependency array  react-hooks/exhaustive-deps

मेरा प्रश्न है: क्या यह व्यवहार करना चाहिए (या तो लिंटर नियम, या हुक सरणी नियम)? क्या इस प्रभाव का वर्णन करने का एक और मुहावरेदार तरीका है?

@svenanders , मैं इस कारण से उत्सुक हूं कि आप fetchPodcastsFn क्यों शामिल नहीं करना चाहते हैं? क्या ऐसा इसलिए है क्योंकि आप इसे हर रेंडर पर बदलते हैं? यदि ऐसा है, तो आप शायद उस फ़ंक्शन को याद रखना चाहते हैं या इसे स्थिर बनाना चाहते हैं (यदि इसमें कोई पैरामीटर नहीं है)

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

https://codesandbox.io/s/4xym4yn9kx

• कदम

उपयोगकर्ता पृष्ठ पर एक मार्ग तक पहुँचता है, लेकिन वे सुपर उपयोगकर्ता नहीं हैं, इसलिए हम उन्हें पृष्ठ से दूर पुनर्निर्देशित करना चाहते हैं। props.navigate को राउटर लाइब्रेरी के माध्यम से इंजेक्ट किया जाता है, इसलिए हम वास्तव में पेज रीलोड को रोकने के लिए window.location.assign का उपयोग नहीं करना चाहते हैं।

सब कुछ काम करता है!

• इरादा एपीआई

मैं कोड खिलौने के डिब्बे में के रूप में सही ढंग से निर्भरता में डाल दिया, लेकिन लिंटर मुझे बता रहा है कि निर्भरता सूची होनी चाहिए props के बजाय props.navigate । ऐसा क्यों है?

स्क्रीनशॉट के साथ एक ट्वीट! https://twitter.com/ferdaber/status/1098966716187582464

संपादित करें: एक वैध कारण यह छोटी गाड़ी हो सकती है यदि navigate() एक ऐसी विधि है जो एक बाध्य this पर निर्भर करती है, इस मामले में तकनीकी रूप से यदि props अंदर कुछ भी बदलता है तो सामान अंदर this भी बदल जाएगा।

कोडसैंडबॉक्स: https://codesandbox.io/s/711r1zmq50

इरादा एपीआई:

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

कदम:

उदाहरण आपको मार्वल कॉमिक एपीआई की खोज करने की अनुमति देता है और एपीआई कॉल को प्रत्येक कीस्ट्रोक पर सक्रिय होने से रोकने के लिए यूजडेब्यून्स का उपयोग करता है।

IMO "सब कुछ" जो हम निर्भरता सरणी में उपयोग करते हैं, वह कुशल नहीं है।

उदाहरण के लिए useDebounce Hook पर विचार करें। वास्तविक दुनिया के उपयोगों में (कम से कम हमारे में), delay पहले रेंडर के बाद नहीं बदलेगा, लेकिन हम जांच कर रहे हैं कि यह हर री-रेंडर पर बदला गया है या नहीं। तो, यह हुक में, का दूसरा तर्क useEffect बेहतर है होना करने के लिए [value] के बजाय [value, delay] ।

कृपया यह न सोचें कि उथली समानता जांच बेहद सस्ते हैं। रणनीतिक रूप से रखे जाने पर वे आपके ऐप की मदद कर सकते हैं लेकिन हर एक घटक को शुद्ध बनाने से वास्तव में आपका ऐप धीमा हो सकता है। ट्रेडऑफ़।

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

सम्मेलन द्वारा कस्टम हुक पर स्वचालित रूप से काम करने के लिए इस नियम को सक्षम करने के बारे में मेरे पास कुछ फीडबैक है।

मैं स्रोत कोड में देख सकता हूं कि लोगों को नाम से कस्टम हुक कैप्चर करने के लिए रेगेक्स निर्दिष्ट करने की अनुमति देने का कुछ इरादा है:

https://github.com/facebook/react/blob/ba708fa79b3db6481b7886f9fdb6bb776d0c2fb9/packages/eslint-plugin-react-hooks/src/ExhaustiveDeps.js#L490 -L492

रिएक्ट टीम निर्भरता सरणियों के साथ कस्टम हुक के लिए एक अतिरिक्त नामकरण सम्मेलन के बारे में क्या सोचेगी? इस प्लगइन द्वारा हुक के रूप में पहचाने जाने के लिए हुक पहले से ही use से पहले होने की परंपरा का पालन करते हैं। सम्मेलन मैं कुछ निर्भरताओं पर भरोसा करने वाले कस्टम हुक का पता लगाने के लिए प्रस्तावित करूंगा, कुछ प्रकार का पोस्टफिक्स होगा, जैसे कुछ WithDeps , जिसका अर्थ है कि एक पूर्ण कस्टम हुक नाम कुछ ऐसा हो सकता है useCustomHookWithDeps । WithDeps पोस्टफिक्स प्लगइन को बताएगा कि अंतिम सरणी तर्क निर्भरता में से एक है।

प्लगइन अभी भी अतिरिक्त रूप से रेगेक्स का समर्थन कर सकता है, लेकिन मुझे लगता है कि पुस्तकालय लेखकों को किसी भी और सभी कस्टम के लिए प्लगइन को स्पष्ट रूप से कॉन्फ़िगर करने के लिए लाइब्रेरी उपभोक्ताओं को मजबूर करने के बजाय WithDeps साथ पोस्टफिक्स्ड अपने कस्टम हुक को निर्यात करने की अनुमति देकर मुझे बहुत लाभ दिखाई देगा। हुक तृतीय-पक्ष या अन्यथा।

यह कस्टम समानता जांच की चेतावनी और स्वतः हटा देता है।

const myEqualityCheck = a => a.includes('@');

useCallback(
  () => {
    // ...
  },
  [myEqualityCheck(a)]
);

उपयोग के लिए, मुझे नहीं लगता कि "अनावश्यक निर्भरता" चेतावनी दिखाई देनी चाहिए क्योंकि वे "निर्भरताएं" बदल जाएंगी कि प्रभाव कैसे आग लगती है।

मान लें कि मेरे पास दो काउंटर हैं, माता-पिता और बच्चे:

• काउंटरों को स्वतंत्र रूप से बढ़ाया / घटाया जा सकता है।
• जब माता-पिता काउंटर बदलता है तो मैं बाल काउंटर को शून्य पर रीसेट करना चाहता हूं।

कार्यान्वयन:

  const [parent, setParent] = useState(0);
  const [child, setChild] = useState(0);

  useEffect(
    () => {
      setChild(0);
    },
    [parent] // "unnecessary dependency: 'parent'"
  );

संपूर्ण-डिप्स नियम चेतावनी देता है React Hook useEffect has an unnecessary dependency: 'parent'. Either exclude it or remove the dependency array.

मुझे नहीं लगता कि लिंटर को यह सुझाव देना चाहिए क्योंकि यह बदलता है कि ऐप कैसे व्यवहार करता है।

1. कोडसैंडबॉक्स: https://codesandbox.io/s/ol6r9plkv5
2. चरण: जब parent बदलता है, तो child शून्य पर रीसेट हो जाता है।
3. इरादा: निर्भरता को अनावश्यक के रूप में चिह्नित करने के बजाय, लिंटर को यह पहचानना चाहिए कि parent useEffect के व्यवहार को बदल देता है और मुझे इसे हटाने की सलाह नहीं देनी चाहिए।

[संपादित करें]

वर्कअराउंड के रूप में, मैं कुछ इस तरह लिख सकता हूं

const [parent, setParent] = useState(0)
const [child, setChild] = useState(0)
const previousParent = useRef(parent)

useEffect(() => {
  if (parent !== previousParent.current) {
    setChild(0)
  }

  previousParent.current = parent
}, [parent])

लेकिन मूल अंश में एक "कविता" है जो मुझे पसंद है।

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

यह वास्तव में एक पैटर्न है जिसे मैंने कुछ आंतरिक कैश को अमान्य करने के लिए दो बार उपयोग किया है:

useEffect(() => {
  if (props.invalidateCache) {
    cache.clear()
  }
}, [props.invalidateCache])

अगर मुझे इस तरह से इसका उपयोग नहीं करना चाहिए, तो बेझिझक मुझे बताएं और इस टिप्पणी की अवहेलना करें।

@श्री लीबो
व्हाट अबाउट

  const [parent, setParent] = useState(0);
  const [child, setChild] = useState(0);
  const updateChild = React.useCallback(() => setChild(0), [parent]);

  useEffect(
    () => {
      updateChild();
    },
    [updateChild] 
  );

मैं आप के उस अंश को भी नहीं समझ पाऊंगा। निर्भरता केवल आपके कोड के आधार पर मानी जा सकती है लेकिन यह एक बग हो सकती है। जबकि मेरा प्रस्ताव अनिवार्य रूप से हल नहीं करता है कि यह इसे कम से कम अधिक स्पष्ट बनाता है।

ऐसा लगता है कि इसे पहले getDerivedStateFromProps माध्यम से हल किया गया था? क्या मैं getDerivedStateFromProps को कैसे कार्यान्वित करूं? मदद?

@nghiepit मैंने आपकी टिप्पणी छुपा दी क्योंकि आपने पहली पोस्ट में आवश्यक चेकलिस्ट को अनदेखा कर दिया था (उदाहरण के लिए कोडसैंडबॉक्स)। कृपया चेकलिस्ट का पालन करें और फिर से पोस्ट करें। धन्यवाद।

@ eps1lon आपके पास useCallback पर ठीक वैसी ही चेतावनी होगी, और मैं सामान्य रूप से उस पैटर्न से असहमत हूं जो मूल में सुधार है, लेकिन मैं इस बारे में बात करने के लिए विषय को पटरी से नहीं उतारना चाहता। स्पष्ट करने के लिए, मुझे लगता है कि अनावश्यक निर्भरता नियम को useEffect या useLayoutEffect विशेष रूप से शिथिल किया जाना चाहिए, क्योंकि उनमें प्रभावी तर्क हो सकते हैं, लेकिन नियम useCallback लिए बना रहना चाहिए, useMemo , आदि।

मैं कुछ ऐसे ही मुद्दों/मानसिक मॉडल प्रश्नों में भाग रहा हूं जिन्हें @MrLeebo ने यहां वर्णित किया है। मेरी आंत की भावना यह है कि useEffect निर्भरता नियम उतना सख्त नहीं हो सकता। मेरे पास एक अविश्वसनीय रूप से विकसित उदाहरण है कि मैं अवधारणा विचार के मूल प्रमाण के लिए काम कर रहा था। मुझे पता है कि यह कोड बेकार है और विचार विशेष रूप से उपयोगी नहीं है, लेकिन मुझे लगता है कि यह समस्या का एक अच्छा उदाहरण है। मुझे लगता है कि @MrLeebo ने इस सवाल को व्यक्त किया कि मैं काफी अच्छा कर रहा हूं:

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

https://codesandbox.io/s/5v9w81j244

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

useDelayedItems हुक का मूल विचार आइटमों की एक सरणी और एक कॉन्फिग ऑब्जेक्ट (एमएस में देरी, प्रारंभिक पृष्ठ आकार) दिया गया है, मुझे शुरू में मेरे कॉन्फ़िगर किए गए पृष्ठ आकार के आधार पर आइटम्स का एक सबसेट दिया जाएगा। config.delay बीत जाने के बाद, आइटम अब आइटम का पूरा सेट होगा। जब इसे वस्तुओं का एक नया सेट दिया जाता है, तो हुक को इस "देरी" तर्क को फिर से चलाना चाहिए। यह विचार बड़ी सूचियों के विलंबित प्रतिपादन का एक बहुत ही कच्चा और गूंगा संस्करण है।

इन नियमों पर सभी कार्यों के लिए धन्यवाद, विकसित करते समय यह बहुत मददगार रहा है। यहां तक ​​​​कि अगर मेरा उदाहरण संदिग्ध गुणवत्ता का है, तो मुझे उम्मीद है कि यह कुछ अंतर्दृष्टि देता है कि इन ऑपरेटरों को कैसे इस्तेमाल किया जा सकता है।

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

एक एकल मूल्य के बारे में क्या है जो अन्य मूल्यों को जोड़ता है?

उदाहरण: fullName firstName और lastName । हम प्रभाव को तभी ट्रिगर करना चाहते हैं जब fullName परिवर्तन होता है (जैसे जब उपयोगकर्ता "सहेजें" हिट करता है) लेकिन प्रभाव में बनाए गए मानों तक भी पहुंच बनाना चाहते हैं

डेमो

निर्भरता में firstName या lastName जोड़ने से चीजें टूट जाएंगी क्योंकि हम केवल fullName बदलने के बाद प्रभाव चलाना चाहते हैं।

@awery मुझे यकीन नहीं है कि आपको useEffect प्रोप परिवर्तन संकेत से क्या मूल्य मिल रहा है। ऐसा लगता है कि आपका onClick उस "प्रभाव" को संभालना चाहिए।

https://codesandbox.io/s/0m4p3klpyw

जहां तक ​​​​एकल मान जो अन्य मूल्यों को जोड़ते हैं, useMemo शायद वही होगा जो आप चाहते हैं। आपके उदाहरण में गणना की विलंबित प्रकृति का अर्थ है कि यह आपके लिंक किए गए व्यवहार के साथ ठीक 1:1 को मैप नहीं करता है।

मैं इन उदाहरणों के लिए कोडसैंडबॉक्स लिंक बनाऊंगा और इस पोस्ट को संपादित करूंगा।

मेरे पास एक अत्यंत सरल नियम है: यदि वर्तमान टैब बदल गया है, तो शीर्ष पर स्क्रॉल करें:
https://codesandbox.io/s/m4nzvryrxj

useEffect(() => {
    window.scrollTo(0, 0);
  }, [activeTab]);

और मुझे React Hook useEffect has an unnecessary dependency: 'activeTab'. Either exclude it or remove the dependency array

साथ ही, जब मैं कुछ घटकों को माइग्रेट कर रहा था, तो मैं घटकडिडमाउंट व्यवहार को दोहराना चाहता हूं:

useEffect(() => {
    ...
  }, []);

यह नियम इस बारे में कड़ी शिकायत कर रहा है। मैं प्रत्येक निर्भरता को useEffect सरणी में जोड़ने में संकोच कर रहा हूं।

अंत में, यदि आप उपयोग करने से पहले एक नया इनलाइन फ़ंक्शन घोषित करते हैं, तो इस तरह:
https://codesandbox.io/s/nr7wz8qp7l

const foo = () => {...};
useEffect(() => {
    foo();
  }, []);

आपको मिलता है: React Hook useEffect has a missing dependency: 'foo'. Either include it or remove the dependency array
मुझे यकीन नहीं है कि मैं निर्भरता सूची में foo जोड़ने के बारे में कैसा महसूस करता हूं। प्रत्येक रेंडर में फू एक नया फंक्शन है और यूजइफेक्ट हमेशा चलता रहेगा?

@ ksaldana1 इवेंट हैंडलर के अंदर साइड इफेक्ट डालना पर्याप्त नहीं है। इससे वास्तविक अद्यतन किए जाने से पहले साइड इफेक्ट होने का कारण होगा, जिसके कारण साइड इफेक्ट आपकी इच्छा से अधिक बार ट्रिगर हो सकता है।

यह useReducer का उपयोग करते समय भी काम नहीं करेगा क्योंकि अपडेट की गई स्थिति ईवेंट हैंडलर के अंदर उपलब्ध नहीं होगी।

जहां तक ​​​​एकल मान जो अन्य मूल्यों को जोड़ते हैं, useMemo शायद वही होगा जो आप चाहते हैं।

यदि यह उदाहरण useMemo करता है तो यह टूट जाएगा क्योंकि useMemo fullName हर बार firstName या lastName परिवर्तित होने पर एक नया fullName प्राप्त करेगा। यहां व्यवहार यह है कि fullName तब तक अपडेट नहीं होता जब तक सेव बटन पर क्लिक नहीं किया जाता है।

@awery क्या कुछ इस तरह काम करेगा? https://codesandbox.io/s/lxjm02j50m
मैं यह देखने के लिए बहुत उत्सुक हूं कि अनुशंसित कार्यान्वयन क्या है।

मैं आपके द्वारा कही गई कुछ बातों के बारे में और जानने के लिए भी उत्सुक हूं। क्या आप मुझे इनके बारे में और जानकारी के लिए इंगित कर सकते हैं?

हैंडलर में ट्रिगरिंग और प्रभाव:

इससे वास्तविक अद्यतन किए जाने से पहले साइड इफेक्ट होने का कारण होगा, जिसके कारण साइड इफेक्ट आपकी इच्छा से अधिक बार ट्रिगर हो सकता है।

ईवेंट हैंडलर में useReducer स्थिति का उपयोग करना:

अद्यतन स्थिति उपलब्ध नहीं होगी।

धन्यवाद!

@bugzpodder असंबंधित की तरह लेकिन पुस्तक कॉल के अंदर होना चाहिए useLayoutEffect के बजाय useEffect । वर्तमान में नए मार्ग पर नेविगेट करते समय ध्यान देने योग्य झिलमिलाहट है

सुनिश्चित नहीं है कि यह जानबूझकर है या नहीं:

जब आप प्रॉप्स से किसी फ़ंक्शन को कॉल करते हैं, तो लिंटर संपूर्ण प्रॉप्स ऑब्जेक्ट को एक निर्भरता के रूप में जोड़ने का सुझाव देता है।

लघु संस्करण:

useEffect(function() {
  props.setLoading(true)
}, [props.setLoading])

// ⚠️ React Hook useEffect has a missing dependency: 'props'.

पूर्ण संस्करण: कोडसैंडबॉक्स

फिर से कोशिश कर रहा हूं... लेकिन इस बार आसान;)

प्रॉप्स में, या वास्तव में कहीं से भी एक फ़ंक्शन को पास करते समय, और एक हुक के अंदर उस फ़ंक्शन का उपयोग करते हुए, मुझे exhaustive-deps चेतावनी मिलती है।

तो मैं स्पष्ट रूप से निर्भरता सरणी में फ़ंक्शन जोड़ सकता हूं, लेकिन क्योंकि यह एक फ़ंक्शन है और कभी नहीं बदलता है, यह असफल सही है?

-> सैंडबॉक्स

आशा है कि वह सब कुछ है जो आपको चाहिए, लेकिन मैंने बस @siddharthkp के सैंडबॉक्स को फोर्क किया क्योंकि यह दर्शाता है कि मेरा क्या मतलब है।

धन्यवाद।

तो मैं स्पष्ट रूप से निर्भरता सरणी में फ़ंक्शन जोड़ सकता हूं, लेकिन क्योंकि यह एक फ़ंक्शन है और कभी नहीं बदलता है, यह असफल सही है?

यह सही नहीं है; फ़ंक्शन हर समय बदल सकते हैं जब माता-पिता पुन: प्रस्तुत करते हैं।

@सिद्धार्थकप

जब आप प्रॉप्स से किसी फ़ंक्शन को कॉल करते हैं, तो लिंटर संपूर्ण प्रॉप्स ऑब्जेक्ट को एक निर्भरता के रूप में जोड़ने का सुझाव देता है।

ऐसा इसलिए है क्योंकि तकनीकी रूप से props.foo() props को this से foo कॉल के रूप में पास करता है। तो foo परोक्ष रूप से props पर निर्भर हो सकता है। हालांकि हमें इस मामले के लिए एक बेहतर संदेश की आवश्यकता होगी। सबसे अच्छा अभ्यास हमेशा विनाशकारी होता है।

फ़ंक्शन हर समय बदल सकते हैं जब माता-पिता पुन: प्रस्तुत करते हैं।

ज़रूर, लेकिन अगर फ़ंक्शन को कहीं और परिभाषित किया गया था और मूल घटक से नहीं, तो यह कभी नहीं बदलेगा।

ज़रूर, लेकिन अगर फ़ंक्शन को कहीं और परिभाषित किया गया था और मूल घटक से नहीं, तो यह कभी नहीं बदलेगा।

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

thx @gaearon

ऐसा इसलिए है क्योंकि तकनीकी रूप से props.foo() props को this से foo कॉल के रूप में पास करता है। तो foo परोक्ष रूप से props पर निर्भर हो सकता है। हालांकि हमें इस मामले के लिए एक बेहतर संदेश की आवश्यकता होगी। सबसे अच्छा अभ्यास हमेशा विनाशकारी होता है।

वही मेरे प्रश्न का उत्तर भी देता है। शुक्रिया! मैं

https://codesandbox.io/s/98z62jkyro

तो मैं प्रत्येक इनपुट के लिए स्वयं को पंजीकृत करने के लिए एक संदर्भ में उजागर किए गए एपीआई का उपयोग करके सभी इनपुट पंजीकृत करके इनपुट सत्यापन को संभालने के लिए एक पुस्तकालय बना रहा हूं। मैंने useRegister नामक एक कस्टम हुक बनाया है।

भूतपूर्व:

 useEffect(
    () => {
      register(props.name, props.rules || []);
      console.log("register");
      return function cleanup() {
        console.log("cleanup");
        unregister(props.name);
      };
    },
    [props.name, props.rules, register, unregister]
  );

जब प्रॉप्स.रूल्स को निर्भरता का हिस्सा बनने के लिए मजबूर किया जाता है, तो ऐसा लगता है कि यह एक अनंत रेंडर-लूप में समाप्त हो जाएगा। Props.rules सत्यापनकर्ताओं के रूप में पंजीकृत होने के लिए कार्यों की एक सरणी है। निर्भरता के रूप में सरणियाँ प्रदान करते समय मैंने केवल इस समस्या का पता लगाया है। मेरे कोडसैंडबॉक्स में, आप देख सकते हैं कि यह कंसोल को खोलने के लिए लूप करता है।

निर्भरता के रूप में केवल props.name होने से यह इरादा के अनुसार काम करता है। निर्भरता को लागू करने से जैसा कि अन्य ने बताया, आवेदन के व्यवहार में बदलाव आएगा, और इस अवसर पर दुष्प्रभाव गंभीर हैं।

@bugzpodder

पुन: https://github.com/facebook/react/issues/14920#issuecomment -467212561

useEffect(() => {
    window.scrollTo(0, 0);
  }, [activeTab]);

यह एक कानूनी मामला लगता है। मैं केवल प्रभाव के लिए बाहरी डीप की अनुमति देने के लिए चेतावनी में ढील देने जा रहा हूं। (लेकिन useMemo या useCallback ।)

साथ ही, जब मैं कुछ घटकों को माइग्रेट कर रहा था, तो मैं घटकडिडमाउंट व्यवहार को दोहराना चाहता हूं:
यह नियम इस बारे में कड़ी शिकायत कर रहा है। मैं प्रत्येक निर्भरता को useEffect सरणी में जोड़ने में संकोच कर रहा हूं।

क्षमा करें, आपने इसके लिए कोई उदाहरण नहीं जोड़ा, इसलिए हमने उस पर चर्चा करने का अवसर खो दिया। यही कारण है कि ओपी पोस्ट एक ठोस यूआई उदाहरण निर्दिष्ट करने के

अंत में, यदि आप useEffect से पहले एक नया इनलाइन फ़ंक्शन घोषित करते हैं, तो इस तरह: https://codesandbox.io/s/nr7wz8qp7l

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

मुझे नहीं पता कि यह एक नए नियम के लिए एक सुविधा अनुरोध है, या ऐसा कुछ है जिसे exhaustive-deps बारे में सुधारा जा सकता है ...

import React from 'react'
import emitter from './thing'

export const Foo = () => {
  const onChange = () => {
    console.log('Thing changed')
  }

  React.useEffect(() => {
    emitter.on('change', onChange)
    return () => emitter.off('change', onChange)
  }, [onChange])

  return <div>Whatever</div>
}

क्योंकि onChange फ़ंक्शन प्रत्येक रेंडर बनाया जाता है, useEffect हुक [onChange] तर्क बेमानी है, और इसे हटाया भी जा सकता है:

   React.useEffect(() => {
     emitter.on('change', onChange)
     return () => emitter.off('change', onChange)
-  }, [onChange])
+  })

लिंटर इसका पता लगा सकता है, और आपको सरणी तर्क को हटाने की सलाह दे सकता है।

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

इस नियम के लिए कुछ सुधारों और बेहतर संदेशों के साथ अभी-अभी [email protected] जारी किया है। कुछ भी महत्वपूर्ण नहीं है लेकिन कुछ मामलों को हल किया जाना चाहिए। मैं अगले हफ्ते बाकी को देख लूंगा।

मैंने यहां "सुरक्षित" फ़ंक्शन डिप्स को छोड़ने के लिए पहला संभावित चरण भी पोस्ट किया है: https://github.com/facebook/react/pull/14996। (परीक्षण देखें।) यदि आपके पास उपयोगी अनुमान के बारे में विचार हैं और लोगों को सही सुधारों के लिए कैसे मार्गदर्शन करना है, तो कृपया पीआर पर टिप्पणी करें।

@gaearon उत्कृष्ट विचार। यह निश्चित रूप से हुक का उपयोग करते समय एक बेहतर शैली के लिए उपयोगी होगा 🙏

@gaearon यह अभी भी काम नहीं करता है अगर कार्रवाई प्रोप से आती है। इस उदाहरण पर विचार करें:

जिसमें setScrollTop एक redux क्रिया है।

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

कोडसैंडबॉक्स में देखा गया प्रभाव यहां दिया गया है:

const { min, max, step } = props;
const sliderElement = useRef();

useEffect(() => {
  if (!sliderElement.current) {
    return;
  }

  const slider = sliderElement.current;
  noUiSlider.create(slider, {
    connect: true,
    start: [min, max],
    step,
    range: {
      min: [min],
      max: [max],
    },
  });

  if (props.onUpdate) {
    slider.noUiSlider.on('update', props.onUpdate);
  }

  if (props.onChange) {
    slider.noUiSlider.on('change', props.onChange);
  }
}, [sliderElement]);

@ WebDeg-Brian मैं पूर्ण कोडसैंडबॉक्स डेमो के बिना आपकी मदद नहीं कर सकता। माफ़ करना। शीर्ष पोस्ट देखें।

मैंने सामान्य "फ़ंक्शंस कभी नहीं बदलते" गलत धारणा के बारे में कुछ पोस्ट किया:

https://overreacted.io/how-are-function-components-different-from-classes/

बिल्कुल वही विषय नहीं है, लेकिन इस नियम के लिए प्रासंगिक है।

हाय @gaearon , यहां वह उदाहरण है जिसे आपने मुझे यहां पोस्ट करने के लिए कहा था (ट्वीटर से) :)

मूल रूप से मैं अपने पुस्तकालय प्रतिक्रिया-जाल को हुक में बदलने की कोशिश कर रहा हूं।
यह किसी तत्व के बाहर/अंदर घटनाओं के लिए सिर्फ एक जाल है।

मेरी समस्या यह है कि यदि useEffect राज्य मूल्य ( trapped ) पर निर्भर नहीं है , तो यह कभी-कभी पुराना होता है।
मैंने प्रदर्शित करने के लिए कुछ टिप्पणियाँ और लॉग लिखे। useTrap.js फ़ाइल को देखें, टिप्पणियाँ और लॉग useEffect और preventDefaultHelper फ़ंक्शन में हैं।

मेरी जानकारी के लिए, यदि कोई मान useEffect अंदर नहीं है तो यह उसकी निर्भरता का हिस्सा नहीं होना चाहिए (अगर मैं गलत हूं तो मुझे सुधारें)।

1. एक कोडसैंडबॉक्स
2. कदम:
   उपयोगकर्ता इसे सक्रिय बनाने के लिए बॉक्स के अंदर क्लिक करता है, और इसे सक्रिय नहीं करने के लिए बाहर, उपयोगकर्ता दाएं माउस बटन के साथ भी क्लिक कर सकता है, हालांकि पहले क्लिक के लिए इसे संदर्भ मेनू को ट्रिगर नहीं करना चाहिए ( e.preventDefault )
   जब मैं कहता हूं "पहला क्लिक" मेरा मतलब राज्य को बदलने वाला पहला क्लिक है।
   एक सक्रिय बॉक्स को देखते हुए, इसके बाहर एक राइट क्लिक राज्य को "सक्रिय नहीं" में बदल देगा और संदर्भ मेनू को रोक देगा। बाहर एक और क्लिक राज्य को प्रभावित नहीं करेगा, इसलिए संदर्भ मेनू प्रकट होना चाहिए।

मुझे आशा है कि मैं यहां स्पष्ट हूं और उपयोग का मामला समझ में आता है, कृपया मुझे बताएं कि क्या मुझे और जानकारी प्रदान करने की आवश्यकता है। धन्यवाद!

हाय @gaearon , जैसा कि आपने मुझे ट्विटर पर सुझाया था, मैं यहां अपना कस्टम हुक जोड़ रहा हूं! मैं सही आकार खोजने के लिए संघर्ष कर रहा हूं जो निर्भरता को नहीं छोड़ता है।

यह एक उदाहरण के रूप में विस्तृत है, मुझे आशा है कि मैं इसे स्पष्ट और समझने योग्य तरीके से समझा सकता हूं।

यह इसकी वर्तमान स्थिति है: प्रतिक्रिया-async-utils/src/hooks/useAsyncData.ts

कार्यक्षमता का अवलोकन
उपयोगकर्ता को एसिंक कॉल, परिणामी डेटा और प्रक्रिया के साथ इसकी स्थिति से निपटने में मदद करना।

triggerAsyncData अपडेट asyncData राज्य अतुल्यकालिक रूप से एक के अनुसार getData समारोह है कि रिटर्न एक Promise । triggerAsyncData को हुक उपयोगकर्ता द्वारा प्रभाव या "मैन्युअल रूप से" दोनों के रूप में लागू किया जा सकता है।

चुनौतियों

1. triggerAsyncData को लागू करने वाले प्रभाव की निर्भरताएं जटिल हैं। triggerAsyncData प्रभाव का एक निर्भरता है, लेकिन यह हर प्रस्तुत करना में बनाया जाता है। विचारों की रेखा अब तक:
   
   
   
   1. बस इसे एक निर्भरता के रूप में जोड़ें => लेकिन फिर प्रभाव हर रेंडर पर चलता है।
   
   
   2. इसे एक निर्भरता के रूप में जोड़ें, लेकिन useMemo / useCallback साथ triggerAsyncData => useMemo / useCallback उपयोग केवल प्रदर्शन अनुकूलन के लिए किया जाना चाहिए AFAIK।
   
   
   3. इसे प्रभाव के अंदर दायर करें => तब मैं इसे उपयोगकर्ता को वापस नहीं कर सकता।
   
   
   4. निर्भरता के रूप में triggerAsyncData का उपयोग करने के बजाय, निर्भरता के रूप में triggerAsyncData की निर्भरता का उपयोग करें => अब तक मुझे मिला सबसे अच्छा विकल्प। लेकिन यह "संपूर्ण-डिप्स" नियम तोड़ता है।
   
   
2. कस्टम हुक का प्रत्येक इनपुट पैरामीटर हमारे आंतरिक प्रभाव की निर्भरता है / बन जाता है। तो पैरामीटर के रूप में इनलाइन फ़ंक्शंस और शाब्दिक ऑब्जेक्ट्स प्रभाव को अक्सर चलाते हैं।
   
   
   
   1. उपयोगकर्ता को जिम्मेदारी छोड़ दें। यदि आवश्यक हो तो वे useMemo / useCallback का उपयोग करके उचित मूल्य प्रदान करेंगे => मुझे अक्सर डर है कि वे नहीं करेंगे। और अगर वे ऐसा करते हैं तो यह काफी क्रियात्मक है।
   
   
   2. कस्टम हुक के लिए इनपुट के विवरण प्रदान करने के लिए एक अतिरिक्त तर्क की अनुमति दें, और स्वयं इनपुट के बजाय इसका उपयोग करें => कूल, कम वर्बोज़, उपयोगकर्ता के लिए अधिक नियंत्रण। मैं इसका उपयोग कर रहा हूं। लेकिन यह "संपूर्ण-डिप्स" नियम तोड़ता है। (वास्तव में मैं यह हूं का उपयोग कर रहा हूं और अतिरिक्त तर्क प्रदान नहीं किए जाने पर नियमित डिपो में वापस आ रहा हूं। मुझे यह एक शक्तिशाली पैटर्न लगता है)।
   
   
3. कस्टम हुक के लिए खराब प्रबंधित निर्भरता आंतरिक प्रभाव के कारण एक अनंत एसिंक लूप उत्पन्न करती है। मैंने इसे रोकने के लिए रक्षात्मक प्रोग्रामिंग का उपयोग किया है, लेकिन यह "नकली" जोड़ता है? निर्भरता ( asyncData )। यह फिर से "संपूर्ण-डिप्स" नियम को तोड़ता है।

मेरी इच्छा से अधिक लंबी व्याख्या ... लेकिन मुझे लगता है कि यह हुक का उचित तरीके से उपयोग करने के मेरे संघर्ष को दर्शाता है। कृपया मुझे बताएं कि क्या कुछ और है जो मैं इन कठिनाइयों को स्पष्ट करने के लिए कर सकता हूं।

यहाँ सभी कड़ी मेहनत के लिए धन्यवाद!

अरे @gaearon आपकी कड़ी मेहनत के लिए धन्यवाद।

1. एक न्यूनतम एसिंक्रोनस डेटा लाने वाला उदाहरण कोडसैंडबॉक्स उदाहरण।

2. उपयोगकर्ता को जेसन एपीआई से प्राप्त 5 लोरेम इप्सम शीर्षक स्ट्रिंग देखने की उम्मीद है।

3. मैंने इच्छित एपीआई के साथ डेटा लाने के लिए कस्टम हुक बनाया है:

const { data, isLoading, isError } = useDataApi('https://jsonplaceholder.typicode.com/posts')

कस्टम useDataApi हुक के आंतरिक भाग:

...
  const fetchData = async () => {
    let response;
    setIsError(false);
    setIsLoading(true);

    try {
      response = await fetch(url).then(response => response.json());

      setData(response);
    } catch (error) {
      setIsError(true);
    }

    setIsLoading(false);
  };

  useEffect(
    () => {
      fetchData();
    },
    [url]
  );
...

यह कोड होने में समस्या

  useEffect(
    () => {
      fetchData();
    },
    [url]
  );

जहां react-hooks/exhaustive-deps एक चेतावनी देता है कि मुझे अपनी निर्भरता सरणी में fetchData जोड़ना चाहिए और url को हटा दिया जाना चाहिए।

अगर मैं इस हुक को . में बदल दूं

  useEffect(
    () => {
      fetchData();
    },
    [fetchData]
  );

तो यह लगातार फायरिंग अनुरोध है और कभी नहीं रुक रहा है, जो निश्चित रूप से एक बड़ी समस्या है। मुझे यकीन नहीं है कि मेरा कोड छोटी गाड़ी है या react-hooks/exhaustive-deps झूठी सकारात्मक फायरिंग कर रहा है।

किसी भी मदद की सराहना की। बहुत बहुत धन्यवाद।

पीएस मैंने उपयोग के बारे में आपकी टिप्पणी पढ़ी है जो डेटा लाने के लिए उपयुक्त नहीं है , हालांकि, प्रतिक्रिया दस्तावेज़ों का दावा है कि Data fetching, setting up a subscription, and manually changing the DOM in React components are all examples of side effects जिसने मुझे विश्वास दिलाया कि डेटा useEffect डेटा लाने के लिए बहुत अच्छा है। तो अब मैं थोड़ा भ्रमित हूँ

@ jan-stehlik आपको उपयोग कॉलबैक के साथ fetchData लपेटना चाहिए। मैंने यहां आवश्यक परिवर्तन के साथ आपके कोडसैंडबॉक्स को फोर्क किया है https://codesandbox.io/s/pjmjxprp0m

बहुत मददगार, बहुत बहुत धन्यवाद @viankakrisna !

मेरे ज्ञान के लिए, यदि कोई मान उपयोग के अंदर नहीं है तो यह उसकी निर्भरताओं का हिस्सा नहीं होना चाहिए (अगर मैं गलत हूं तो मुझे सही करें)।

मुझे लगता है कि तुम यहाँ गलत हो। या यों कहें, थोड़ा भ्रमित। आप अपने प्रभाव के अंदर handleEvent का उपयोग कर रहे हैं । लेकिन आप इसे घोषित नहीं करते हैं। इसलिए इसमें पढ़े गए मूल्य बासी हैं।

दिलचस्प।

आप अपने प्रभाव के अंदर हैंडलएवेंट का उपयोग कर रहे हैं। लेकिन आप इसे घोषित नहीं करते हैं। इसलिए इसमें पढ़े गए मूल्य बासी हैं।

आपका क्या मतलब है: _"लेकिन आप इसे घोषित नहीं करते"_?
इसे प्रभाव के नीचे घोषित किया गया है (अन्य सभी हैंडलर के समान)।

या क्या आपका मतलब है क्योंकि हैंडलर राज्य मूल्य का उपयोग कर रहा है, और प्रभाव हैंडलर को जोड़ रहा है तो इसका मतलब है कि प्रभाव उस राज्य मूल्य पर निर्भर है?

या क्या आपका मतलब है क्योंकि हैंडलर राज्य मूल्य का उपयोग कर रहा है, और प्रभाव हैंडलर को जोड़ रहा है तो इसका मतलब है कि प्रभाव उस राज्य मूल्य पर निर्भर है?

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

ठीक है यह मेरे लिए खबर है! इस इनपुट के लिए धन्यवाद @gaearon :)
मैं चाहता हूं कि यह मेरे लिए (और अन्य?) सुपर स्पष्ट हो ...

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

मुझे कहना होगा कि मैंने इसे दस्तावेज़ों पर नहीं देखा।
क्या आपको लगता है कि इसे _नोट_ अनुभाग में जोड़ना ठीक है?

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

संपादित करें
एक और बात, मेरे उदाहरण में, के लिए deps क्या कर रहे हैं useCallback जब यह लपेटता handleEvent (या कि कारण के लिए किसी अन्य हैंडलर)। क्या यह event यह स्वयं है?

मुझे कहना होगा कि मैंने इसे दस्तावेज़ों पर नहीं देखा।

दस्तावेज़ कहते हैं "प्रभाव फ़ंक्शन के अंदर संदर्भित प्रत्येक मान इनपुट सरणी में भी दिखाई देना चाहिए"। कार्य भी मूल्य हैं। मैं सहमत हूं कि हमें इसे बेहतर तरीके से दस्तावेज करने की आवश्यकता है - जो कि यह धागा है :-) मैं इसे समर्पित एक नए दस्तावेज़ीकरण पृष्ठ के लिए उपयोग के मामले एकत्र कर रहा हूं।

एक और बात, मेरे उदाहरण में, उपयोग के लिए डीपीएस क्या हैं कॉलबैक जब यह हैंडलएवेंट (या उस कारण से किसी अन्य हैंडलर) को लपेटता है। क्या यह घटना स्वयं है?

पक्का नहीं आपका क्या मतलब है। यह इसके बाहर के फ़ंक्शन द्वारा संदर्भित कोई भी मान है। जैसे useEffect ।

मुझे लगता है कि मैंने इसे निर्भरता के रूप में कार्यों के माध्यम से नहीं सोचा था। मेरा मानसिक मॉडल गलत था, मैं सोच रहा था कि एक फ़ंक्शन को केवल एक निर्भरता के रूप में पास करें यदि यह मेरे घटक/हुक के प्रोप या तर्क के रूप में आया है। मेरे लिए इसे स्पष्ट करने के लिए धन्यवाद।

useCallback , मैंने इसे इस तरह इस्तेमाल किया:

const memoHandleEvent = useCallback(
    handleEvent
);

और निश्चित रूप से memoHandleEvent को useEffect साथ-साथ वास्तविक handleEvent फ़ंक्शन के अंदर addEventListener लिए निर्भरता के रूप में पारित किया। काम करने लगता है, आशा है कि यह करने का यह उचित और मुहावरेदार तरीका है।

नोट useCallback दूसरे तर्क के बिना कुछ भी नहीं करता है।

फिर से, एक पूर्ण सैंडबॉक्स आवश्यक होगा। इस तरह के अधूरे विवरण से मैं यह नहीं बता सकता कि आपका सुधार सही है या नहीं।

नोट उपयोग कॉलबैक दूसरे तर्क के बिना कुछ भी नहीं करता है।

आर्ग! : मुस्कराहट: लोल

फिर से, एक पूर्ण सैंडबॉक्स आवश्यक होगा। इस तरह के अधूरे विवरण से मैं यह नहीं बता सकता कि आपका सुधार सही है या नहीं।

ओह, यह ऊपर से वही लिंक है। मैंने अभी इसे अपडेट किया है :)

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

अरे! माफ़ करना! :PI मेरे खाते पर सैंडबॉक्स की संख्या को पार कर गया है। मुझे कुछ हटाने दो और मैं एक और बनाऊंगा (और मूल में परिवर्तनों को वापस कर दूंगा)।

@gaearon useCallback साथ समाधान की यह दूसरी कड़ी है

मेरे पास एक परिदृश्य है जो मुझे लगता है कि ठीक है, लेकिन लिंटर शिकायत करता है। मेरा नमूना:

कोडसैंडबॉक्स

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

यहां का उदाहरण थोड़ा काल्पनिक है। मेरे वास्तविक एप्लिकेशन में, रिएक्ट एक डीआईवी में रहता है जो कि एक बहुत बड़े वेब एप्लिकेशन का एक छोटा सा हिस्सा है। पास किया गया फ़ंक्शन Redux और mapDispatchToProps के माध्यम से है, जहां एक क्रिया निर्माण आईडी लेता है और डेटा लाने और स्टोर को अपडेट करने के लिए एक अजाक्स अनुरोध करता है। रिफ्रेश रिक्वेस्ट प्रोप को React.createElement के माध्यम से पास किया जाता है। मेरे मूल कार्यान्वयन में, मेरे पास कोड था जो वर्ग घटक में इस तरह दिखता था:

componentDidUpdate (prevProps) { const { getData, someId, refreshRequest} = this.props; if (prevProps.refreshRequest!== this.props.refreshRequest) { getData(someId); } }

मैं एक ही व्यवहार को एक प्रभाव हुक के साथ लागू करने की कोशिश कर रहा हूं। लेकिन जैसा कि नमूने में लिखा गया है, लिंटर शिकायत करता है:

चेतावनी प्रतिक्रिया हुक उपयोग प्रभाव में निर्भरताएँ गायब हैं: 'getData' और 'someId'। या तो उन्हें शामिल करें या निर्भरता सरणी को हटा दें

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

उम्मीद है कि यह समझ में आता है। अगर कुछ अस्पष्ट है, तो मुझे और स्पष्ट करने में खुशी होगी। शुक्रिया!

मैंने अभी [email protected] प्रकाशित किया है जिसमें नंगे फ़ंक्शन निर्भरताओं का पता लगाने के लिए प्रयोगात्मक समर्थन है (जो useCallback बिना बहुत उपयोगी नहीं होते हैं)। यहां एक जीआईएफ है:

अच्छा लगेगा यदि आप इसे अपने प्रोजेक्ट्स में आज़मा सकें और देखें कि यह कैसा लगता है! (कृपया https://github.com/facebook/react/pull/15026 में उस विशिष्ट प्रवाह पर टिप्पणी करें।)

मैं कल इस धागे से उदाहरणों पर कोशिश करूँगा।

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

function Component() {
  useEffect(() => {
    handleChange
  }, [handleChange])

  return null

  function handleChange() {}
}

यह अच्छा होगा यदि नियम के पास किसी अन्य फ़ंक्शन को useEffect जैसा व्यवहार करने के लिए कॉन्फ़िगर करने का विकल्प हो, जहां तक ​​​​लिंटर का संबंध है। उदाहरण के लिए, मैंने इसे जोड़ा है ताकि मैं आसानी से एजेएक्स कॉल करने वाले प्रभावों के लिए एसिंक फ़ंक्शंस का उपयोग कर सकूं - हालांकि, इस तरह से मैं सभी exhaustive-deps लाइनिंग लाभ खो देता हूं:

const useAsyncEffect = (fn, ...args) => {
    /* eslint-disable react-hooks/exhaustive-deps */
    useEffect(() => {
        fn();
    }, ...args);
};

संपादित करें: कोई बात नहीं, मैंने अभी देखा है कि नियम के additionalHooks विकल्प का उपयोग करके यह पहले से ही संभव है।

नमस्ते,
मेरे पास एक उदाहरण है https://codesandbox.io/s/znnmwxol7l

मैं जो चाहता हूं वह नीचे है:

function App() {
  const [currentTime, setCurrentTime] = React.useState(moment());

  const currentMonth = React.useMemo(
    () => {
      console.log("RUN");
      return currentTime.format("MMMM");
    },
    [currentTime.format("MMMM")] // <= this proplem [currentTime]
  );

  return (
    <div className="App">
      <h1>Current month: {currentMonth}</h1>
      <div>
        <button
          onClick={() => setCurrentTime(currentTime.clone().add(1, "days"))}
        >
          + 1 day
        </button>
      </div>
      <div>{currentTime.toString()}</div>
    </div>
  );
}

लेकिन मुझे यही मिलता है:

  const currentMonth = React.useMemo(
    () => {
      console.log("RUN");
      return currentTime.format("MMMM");
    },
    [currentTime] // <= this proplem
  );

कभी भी currentTime परिवर्तन फिर currentMonth अनावश्यक पुनर्गणना करें

या किसी तरह मैं इसे नीचे कर सकता हूं:

  const currentMonth = React.useMemo(
    () => {
      return currentTime.format("MMMM");
    },
    [myEqualityCheck(currentTime)]
  );

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

@einarq मुझे लगता है कि आपको यह सुनिश्चित करने की ज़रूरत है कि आपके ऑन-माउंट useEffect में सभी संदर्भित मान कभी नहीं बदलेंगे। यह useMemo जैसे अन्य हुक का उपयोग करके हासिल किया जा सकता है। उसके बाद भले ही यह ESlint नियम सभी संदर्भों को सरणी (ऑटोफिक्स के साथ) में जोड़ता है या नहीं, कोड केवल एक बार निष्पादित किया जाएगा।

@einarq जैसा कि धागे में कहीं और कहा गया है, हम कोडसैंडबॉक्स के बिना आपकी मदद नहीं कर सकते। क्योंकि उत्तर वास्तव में आपके कोड पर निर्भर करता है।

@nghiepit आपका उदाहरण वास्तव में मुझे समझ में नहीं आता है। यदि आपका इनपुट currentTime.format("MMMM") तो useMemo आपके लिए कुछ भी अनुकूलित नहीं करता है क्योंकि आपने इसकी गणना पहले ही कर ली है । तो आप इसे अनावश्यक रूप से दो बार गणना कर रहे हैं।

क्या यह निर्दिष्ट करना संभव है कि कौन सा तर्क सूचकांक additionalHooks विकल्प पर कॉलबैक है? मैं देख रहा हूं कि हम अभी कोड में मान रहे हैं कि यह पहला होगा https://github.com/facebook/react/blob/9b7e1d1389e080d19e71680bbbe979ec58fa7389/packages/eslint-plugin-react-hooks/src/ExhaustiveDeps.js#L1051 - एल1081

फिलहाल संभव नहीं है। हमारा सामान्य मार्गदर्शन यह है कि कस्टम हुक को deps तर्क नहीं रखना चाहिए क्योंकि यह सोचना बहुत मुश्किल हो जाता है कि डिप्स कैसे लिखते हैं। यदि आप कोई फ़ंक्शन लेते हैं तो आप उपयोगकर्ताओं से इसके बजाय useCallback लिए कह सकते हैं।

@CarlosGines क्या आप कृपया एक कोडसैंडबॉक्स बना सकते हैं, जैसा कि ओपी पोस्ट में अनुरोध किया गया है। मैं यह एक कारण के लिए पूछ रहा हूँ - अन्यथा मेरे लिए परिवर्तनों को सत्यापित करना कठिन है। खासकर जब यह टाइपस्क्रिप्ट में लिखा हो।

मैंने उम्मीद से अधिक उपयोगी संदेशों और बेहतर अनुमान के साथ अभी [email protected] प्रकाशित किया है। स्थिर होने से पहले कृपया इसे अपनी परियोजनाओं पर आज़माएं।

मुझे उम्मीद है कि इस धागे में अधिकांश उदाहरणों के साथ, इसे उचित सलाह देनी चाहिए जिससे आपको समस्याओं को ठीक करने में मदद मिलनी चाहिए।

क्या वह [email protected] होना चाहिए?

हां।

वास्तव में अभी कुछ छोटे बदलावों के साथ [email protected] प्रकाशित हुआ है।

@gaearon क्या आप किसी भी संयोग से कोडसैंडबॉक्स के अंदर काम करने के लिए eslint प्राप्त करने में कामयाब रहे?

@einarq शायद ऐसा कुछ काम करेगा?

const useDidMount = fn => {
  const callbackFn = useCallback(fn)
  useEffect(() => {
    callbackFn()
  }, [callbackFn])
}

मैं वास्तव में यह कहते हुए शर्मिंदा हूं कि मुझे एक साधारण सीआरए ऐप ( मेरे स्निपेट के आधार पर) पर काम करने के लिए प्लगइन नहीं मिल रहा है।
कोडसैंडबॉक्स से फोर्कड रेपो यहां दिया गया है।

मैंने यह नोट डॉक्स में देखा है:

नोट: यदि आप क्रिएट रिएक्ट ऐप का उपयोग कर रहे हैं, तो कृपया प्रतिक्रिया-स्क्रिप्ट के संबंधित रिलीज़ की प्रतीक्षा करें जिसमें इसे सीधे जोड़ने के बजाय इस नियम को शामिल किया गया है।

लेकिन क्या इस समय सीआरए के साथ इसका परीक्षण करने का कोई तरीका नहीं है? मैं

हाँ, जब तक हम इसे वहाँ नहीं जोड़ते, तब तक आपको इसे ESLint कॉन्फ़िग में इजेक्ट करके जोड़ना होगा। आप एक शाखा में बेदखल कर सकते हैं और इसे मर्ज नहीं कर सकते। :-)

नमस्ते,

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

हमें एक कस्टम हुक के साथ एक समस्या है जिसे हमने Fetch API के आसपास बनाया है। मैंने इस मुद्दे को प्रदर्शित करने के लिए एक कोडसैंडबॉक्स बनाया है।

कोडसैंडबॉक्स पर उदाहरण

https://codesandbox.io/s/kn0km7mzv

नोट: समस्या (नीचे देखें) का परिणाम अनंत लूप में होता है और मैं डीडीओएस jsonplaceholder.typicode.com नहीं चाहता जिसका उपयोग मैं इस मुद्दे को प्रदर्शित करने के लिए कर रहा हूं। इसलिए, मैंने काउंटर का उपयोग करके एक साधारण अनुरोध सीमक शामिल किया है। इस मुद्दे को प्रदर्शित करने के लिए इसकी आवश्यकता नहीं है, लेकिन इस महान परियोजना के लिए असीमित मात्रा में अनुरोधों को आग लगाना गलत लगा।

व्याख्या

यह विचार एपीआई अनुरोध के 3 संभावित राज्यों को संभालना आसान बनाना है: लोड हो रहा है, सफलता और त्रुटि। इस प्रकार हमने एक कस्टम हुक useFetch() जो 3 गुण देता है isLoading , response और error. It makes sure that either प्रतिक्रिया or त्रुटि is set and updates isLoading . As the name implies, it uses the Fetch` API.

ऐसा करने के लिए, यह 3 useState हुक का उपयोग करता है:

  const [isLoading, setIsLoading] = useState(false);
  const [response, setResponse] = useState(null);
  const [error, setError] = useState(null);

और एक useEffect हुक:

useEffect(
    () => {
      fetch(url, fetchConfig)
        .then(/* Handle fetch response... See Codesandbox for the actual implementation */)
    },
    [url]
  );

यह तब तक ठीक काम करता है जब तक useEffect की निर्भरता सरणी में केवल [url] । यदि हम fetchConfig (= [url, fetchConfig] ) जोड़ते हैं, तो यह एक अनंत लूप में परिणत होता है। हमारे विशेष उपयोग के मामले में, यह केवल तभी प्रभाव को फिर से चलाने के लिए पर्याप्त होगा जब url बदलता है लेकिन लिंटर केवल [url] उपयोग करने की अनुमति नहीं देता है ( v1.4.0 साथ परीक्षण किया गया और v1.5.0-beta.1 )।

कस्टम हुक के अंत में, 3 राज्य चर एक वस्तु के रूप में लौटाए जाते हैं:

  return {
    error,
    isLoading,
    response
  };

मुझे यकीन नहीं है कि इस मुद्दे पर मार्गदर्शन मांगने के लिए यह सही जगह है क्योंकि लाइनिंग सुझाव समझ में आता है, मुझे लगता है। क्षमा करें यदि ऐसा नहीं है।

क्या होगा यदि fetchConfig बदल जाए? आप इसे स्थिर होने की उम्मीद क्यों करते हैं?

ठीक है। मैंने पिछले सप्ताह के सुधारों और सुधारों के साथ [email protected] जारी किया।
यह धागा समस्याओं का कारण बनने वाले विभिन्न पैटर्न खोजने में बेहद मददगार रहा है।

आप सभी का बहुत बहुत धन्यवाद। (खासकर वे जिन्होंने सैंडबॉक्स की आपूर्ति की। :-)

मैं व्यक्तिगत रूप से सभी को विस्तार से जवाब नहीं दूंगा क्योंकि यह बहुत सारे मामले हैं।

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

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

चीयर्स!

❤️

@timkraut आपको fetchConfig जोड़ने में सक्षम होना चाहिए, और घटक को इसे मेमो के साथ लपेटना चाहिए ताकि संदर्भ बना रहे।
एक उदाहरण: https://codesandbox.io/s/9l015v2x4w

इसके साथ मेरी समस्या यह है कि अब घटक को हुक के कार्यान्वयन विवरण के बारे में पता होना चाहिए ...

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

उदाहरण

https://codesandbox.io/s/40v54jnkyw

इस उदाहरण में, मैं समय-समय पर इनपुट मानों को स्वत: सहेजने का प्रयास कर रहा हूं।

व्याख्या

प्रत्येक 5 सेकंड में, कोड वर्तमान मानों को स्वतः सहेजने का प्रयास कर रहा है (अभी के लिए उन्हें स्क्रीन पर प्रिंट करें)। लिंटर को सभी इनपुट मानों को निर्भरता सरणी में शामिल करने की आवश्यकता होगी जो यह बदलेगा कि प्रभाव कितनी बार आग लगेगा।

  useEffect(
    () => {
      if (autoSaveTick % 5 === 0) {
        setAutosaveValue(
          `${input1Value.value}, ${input2Value.value}, ${input3Value.value}`
        );
      }
    },
    [autoSaveTick]
  );

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

मैं एक प्रभाव लिखने में सर्वोत्तम प्रथाओं की तलाश कर रहा हूं जो तब चलता है जब एक चर परिवर्तन (वेरिएबल ए) जो पिछले परिवर्तनीय परिवर्तन (वेरिएबल ए) के समय अन्य परिवर्तनीय मानों (वैरिएबल बी और वेरिएबल सी) का उपयोग करता है।

क्या होगा यदि fetchConfig बदल जाए? आप इसे स्थिर होने की उम्मीद क्यों करते हैं?

मैं इसे निर्भरता सरणी में जोड़ना ठीक रहेगा। हमारे विशेष व्यावसायिक मामले में, ऐसा कभी नहीं हो सकता है लेकिन मुझे लगता है कि इसे वैसे भी जोड़ना एक अच्छा विचार है।

इसके साथ मेरी समस्या यह है कि अब घटक को हुक के कार्यान्वयन विवरण के बारे में पता होना चाहिए ...

ठीक यही समस्या हमारे पास भी है: / हमारे कार्यान्वयन में, हमने शरीर को सेट करना आसान बनाने के लिए एक अतिरिक्त संपत्ति का भी उपयोग किया है, useMemo() जब भी हम इस हुक का उपयोग करते हैं तो हमें 2

आप एक उपयोग प्रभाव कैसे चला सकते हैं जिसमें एक खाली सरणी पास करते समय नियम की शिकायत किए बिना केवल एक बार निर्भरता होती है?

कहो, कुछ इस तरह:

useEffect(() => { init({ dsn, environment}) }, [])

इसके साथ मेरी समस्या यह है कि अब घटक को हुक के कार्यान्वयन विवरण के बारे में पता होना चाहिए ...

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

यदि व्यवहार में यह हमेशा स्थिर रहता है, तो आप इसे हुक कारखाने के लिए तर्क बना सकते हैं। createFetch(config) जो useFetch() लौटाता है। आप कारखाने को शीर्ष स्तर पर बुलाते हैं।

मैं समझता हूं कि यह थोड़ा अजीब है। जिस useSubscription पर हम काम कर रहे हैं, उसके साथ भी हमें ऐसी ही समस्या है। लेकिन चूंकि यह एक आम समस्या है, इसका मतलब यह हो सकता है कि useMemo वास्तव में एक वैध उत्तर है और लोगों को इन मामलों के लिए इसे करने की आदत डालनी चाहिए।

व्यवहार में — हम भविष्य में इस पर और अधिक ध्यान देंगे। लेकिन आपको संभावित गतिशील वस्तु को स्थिर के रूप में नहीं मानना ​​​​चाहिए क्योंकि तब उपयोगकर्ता इसे बदल नहीं सकता है।

@asylejmani आपने अपने उपयोग के मामलों के बारे में कोई विवरण नहीं दिया है, जैसा कि शीर्ष पोस्ट में अनुरोध किया गया है। आप क्यों उम्मीद करते हैं कि कोई आपके प्रश्न का उत्तर प्रदान कर सकता है?

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

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

@gaearon स्पष्ट नहीं होने के लिए खेद है (यह हमेशा किसी के सिर में स्पष्ट लगता है) :) मेरा सवाल यह है कि आप उपयोग के साथ घटकडिडमाउंट कैसे प्राप्त करेंगे।

मैं एक खाली सरणी की तुलना में इस धारणा के तहत था, लेकिन नियम मुझे बता रहा है कि हमेशा सरणी में निर्भरता शामिल करें।

@asylejmani मुझे लगता है कि वर्ग जीवन चक्र विधियों जैसे componentDidMount साथ सबसे बड़ा गोचा यह है कि हम इसे एक अलग विधि के रूप में सोचते हैं, लेकिन वास्तव में यह प्रवाह का हिस्सा है।
यदि आप componentDidMount में कुछ संदर्भित करते हैं, तो आपको संभवतः इसे componentDidUpdate में भी संभालने की आवश्यकता होगी, या आपका घटक छोटी गाड़ी हो सकता है।
यही नियम ठीक करने की कोशिश कर रहा है, आपको समय के साथ मूल्यों को संभालने की जरूरत है।

1. घटक घुड़सवार, एक प्रोप के साथ कुछ करें
2. घटक अपडेट किया गया (उदाहरण: प्रोप वैल्यू बदल गया है), नए प्रोप वैल्यू के साथ कुछ करें

नंबर 1 वह जगह है जहां आप तर्क को componentDidMount / useEffect शरीर में डालते हैं
नंबर 2 वह जगह है जहां आप componentDidUpdate / useEffect में तर्क डालते हैं

नियम शिकायत कर रहा है कि आप फ्लो का नंबर 2 भाग नहीं कर रहे हैं

@gaearon स्पष्ट नहीं होने के लिए खेद है (यह हमेशा किसी के सिर में स्पष्ट लगता है) :) मेरा सवाल यह है कि आप उपयोग के साथ घटकडिडमाउंट कैसे प्राप्त करेंगे।

मैं एक खाली सरणी की तुलना में इस धारणा के तहत था, लेकिन नियम मुझे बता रहा है कि हमेशा सरणी में निर्भरता शामिल करें।

मुझे लगता है कि मैं और @asylejmani यहां एक ही पृष्ठ पर हैं, लेकिन मुझे लगता है कि आप @gaearon जो कह रहे हैं वह
क्या यह उचित बयान है? मुझे लगता है कि मैं सोच रहा हूं कि एक खाली सरणी प्रदान करना "मुझे पता है कि मैं क्या कर रहा हूं" कहने जैसा है, लेकिन मुझे लगता है कि आप अभी भी नियम क्यों रखना चाहते हैं।

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

किसी भी मामले में, मुझे वह मिलता है जो आप कह रहे हैं, और सामान्य परिदृश्यों के तहत उन निर्भरताओं को शामिल करना शायद सबसे अच्छा है और यह न मानें कि यह केवल माउंट पर चलने के लिए पर्याप्त है।

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

@asylejmani https://github.com/facebook/react/issues/14920#issuecomment -466378650 के समान आपका उपयोग मामला है? मुझे नहीं लगता कि इस मामले में नियम के लिए परिदृश्य को समझना संभव है, इसलिए हमें उस प्रकार के कोड के लिए इसे मैन्युअल रूप से अक्षम करने की आवश्यकता होगी। अन्य सभी मामलों में नियम वैसा ही काम करता है जैसा उसे करना चाहिए।

सुनिश्चित नहीं है कि यह समझ में आता है, लेकिन एक परिदृश्य जो मेरे लिए काफी आम है वह ऐसा कुछ है:

useEffect(() => {
    if(!dataIsLoaded) { // flag from redux
        loadMyData(); // redux action creator
    }
}, []);

ये दोनों निर्भरताएँ redux से आ रही हैं। डेटा (इस मामले में) केवल एक बार लोड किया जाना चाहिए, और क्रिया निर्माता हमेशा समान होता है।

यह redux के लिए विशिष्ट है, और आपका एस्लिंट नियम यह नहीं जान सकता है, इसलिए मुझे लगता है कि इसे चेतावनी क्यों देनी चाहिए। अभी भी सोच रहा है कि क्या एक खाली सरणी प्रदान करना शायद नियम को अक्षम करना चाहिए? मुझे यह पसंद है कि नियम मुझे लापता डिपो के बारे में बताता है यदि मैंने कुछ प्रदान किया है लेकिन सभी को नहीं, या यदि मैंने कोई भी प्रदान नहीं किया है। खाली सरणी का मतलब मेरे लिए कुछ अलग है। लेकिन वह सिर्फ मैं ही हो सकता हूं :)

आपके कड़ी मेहनत के लिए धन्यवाद! और डेवलपर्स के रूप में हमारे जीवन को बेहतर बनाने के लिए :)

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

@einarq का उपयोग मामला कुछ ऐसा है जिसका मैंने कुछ बार उपयोग किया है, उदाहरण के लिए "

मैं यह भी मानता हूं कि इन मामलों में नियम इनलाइन को अक्षम करना सबसे अच्छा विकल्प है। उस स्थिति में आप ठीक-ठीक जानते हैं कि आप क्या कर रहे हैं।

मेरा मानना ​​​​है कि मेरा पूरा भ्रम [] बनाम [कुछ] था, और निश्चित रूप से धन्यवाद @gaearon भयानक काम के लिए :)

मुझे लगता है कि मैं और @asylejmani यहां एक ही पृष्ठ पर हैं, लेकिन मुझे लगता है कि आप @gaearon जो कह रहे हैं वह

हां। यदि आपका घटक किसी प्रोप के अपडेट को हैंडल नहीं करता है, तो यह आमतौर पर छोटी गाड़ी है। useEffect का डिज़ाइन आपको इसका सामना करने के लिए मजबूर करता है। आप निश्चित रूप से इसके आसपास काम कर सकते हैं, लेकिन डिफ़ॉल्ट रूप से आपको इन मामलों को संभालने के लिए प्रेरित करना है। यह टिप्पणी इसे अच्छी तरह से समझाती है: https://github.com/facebook/react/issues/14920#issuecomment -470913287।

ये दोनों निर्भरताएँ redux से आ रही हैं। डेटा (इस मामले में) केवल एक बार लोड किया जाना चाहिए, और क्रिया निर्माता हमेशा समान होता है।

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

अभी भी सोच रहा है कि क्या एक खाली सरणी प्रदान करना शायद नियम को अक्षम करना चाहिए?

नहीं। एक खाली सरणी प्रदान करना और फिर यह सोचना कि कुछ प्रॉप्स या अवस्था बासी क्यों है, वस्तुतः सबसे आम गलती है।

>

एक टन समझ में आता है, धन्यवाद

8 मार्च 2019 को, 15:27 बजे, डैन अब्रामोव नोटिफिकेशन @github.com ने लिखा:

मुझे लगता है कि मैं और @asylejmani यहां एक ही पृष्ठ पर हैं, लेकिन मुझे लगता है कि आप @gaearon जो कह रहे हैं वह

हां। यदि आपका घटक किसी प्रोप के अपडेट को हैंडल नहीं करता है, तो यह आमतौर पर छोटी गाड़ी है। UseEffect का डिज़ाइन आपको इसका सामना करने के लिए मजबूर करता है। आप निश्चित रूप से इसके आसपास काम कर सकते हैं, लेकिन डिफ़ॉल्ट रूप से आपको इन मामलों को संभालने के लिए प्रेरित करना है। यह टिप्पणी इसे अच्छी तरह से समझाती है: #14920 (टिप्पणी)।

ये दोनों निर्भरताएँ redux से आ रही हैं। डेटा (इस मामले में) केवल एक बार लोड किया जाना चाहिए, और क्रिया निर्माता हमेशा समान होता है।

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

अभी भी सोच रहा है कि क्या एक खाली सरणी प्रदान करना शायद नियम को अक्षम करना चाहिए?

नहीं। एक खाली सरणी प्रदान करना और फिर यह सोचना कि कुछ प्रॉप्स या अवस्था बासी क्यों है, वस्तुतः सबसे आम गलती है।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें, या थ्रेड को म्यूट करें।

@ भयभीत

इससे वास्तविक अद्यतन किए जाने से पहले साइड इफेक्ट होने का कारण होगा, जिसके कारण साइड इफेक्ट आपकी इच्छा से अधिक बार ट्रिगर हो सकता है।

मुझे यकीन नहीं है कि इसका क्या मतलब है। क्या आप एक उदाहरण प्रदान कर सकते हैं?

हमने आज @threepointone के साथ इन पर एक पास किया। यहाँ एक सारांश है:

लिंट नियम में फिक्स्ड

अतिरिक्त useEffect निर्भरताएं

• https://github.com/facebook/react/issues/14920#issuecomment -467195930 @ksaldana1 द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७२,१२,५६१ @bugzpodder द्वारा (पहले स्निपेट)
• https://github.com/facebook/react/issues/14920#issuecomment -466205376 @ dan-lee द्वारा

नियम आपको "बाहरी" विवरण को useEffect जोड़ने से नहीं रोकता है क्योंकि कानूनी परिदृश्य मौजूद हैं।

एक ही घटक में कार्य लेकिन प्रभाव के बाहर परिभाषित

• https://github.com/facebook/react/issues/14920#issuecomment -+४६,८५,१२,६२३ @jaydenseric द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७२,१२,५६१ @bugzpodder द्वारा (दूसरा टुकड़ा)

लिंटर उन मामलों के लिए चेतावनी नहीं देता है जहां यह अभी सुरक्षित है, लेकिन अन्य सभी मामलों में यह आपको बेहतर सुझाव देता है (जैसे प्रभाव के अंदर फ़ंक्शन को स्थानांतरित करना, या इसे useCallback लपेटना)।

उपयोगकर्ता कोड में वर्थ फिक्सिंग

प्रॉप्स चेंज पर स्टेट रीसेट करना

• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७१,०१,५९८ @MrLeebo द्वारा

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

"मेरा गैर-कार्य मान स्थिर है"

• https://github.com/facebook/react/issues/14920#issuecomment -468966055 @jamesmosier द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,६५,८७,६६१ @MoradiDavijani द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -466144466 @billyjanitsch द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४७,०६,०१,५२४ @timkraut द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७७,८५,८७३ @thsorens द्वारा (आंशिक रूप से)

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

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

const useFetch = createFetch({ /* config object */});
const useDebounce = createDebounce(500);
const FormInput = createInput({ rules: [emailValidator, phoneValidator] });

तब यह स्पष्ट रूप से तब तक नहीं बदल सकता जब तक आप इसे रेंडर के अंदर नहीं डालते। (जो आपके हुक का मुहावरेदार उपयोग नहीं होगा।) लेकिन यह कहना कि <Slider min={50} /> कभी नहीं बदल सकता है, वास्तव में मान्य नहीं है - कोई इसे आसानी से <Slider min={state ? 50 : 100} /> बदल सकता है। वास्तव में, कोई ऐसा कर सकता है:

let slider
if (isCelsius) {
  slider = <Slider min={0} max={100} />
} else {
  slider = <Slider min={32} max={212} />
}

अगर कोई राज्य में isCelsius स्विच करता है, तो min कभी नहीं बदलने वाला घटक अद्यतन करने में विफल रहेगा। इस मामले में यह स्पष्ट नहीं है कि Slider वही होगा (लेकिन ऐसा इसलिए होगा क्योंकि पेड़ में इसकी वही स्थिति है)। तो कोड में बदलाव करने के मामले में यह एक प्रमुख फुटगन है। रिएक्ट का एक प्रमुख बिंदु यह है कि अपडेट प्रारंभिक अवस्थाओं की तरह ही प्रस्तुत होते हैं (आप आमतौर पर यह नहीं बता सकते कि कौन सा है)। चाहे आप प्रोप वैल्यू बी प्रस्तुत करें, या चाहे आप प्रोप वैल्यू ए से बी तक जाएं - यह दिखना चाहिए और वही व्यवहार करना चाहिए।

हालांकि यह अस्वीकार्य है, कुछ मामलों में, प्रवर्तन तंत्र एक हुक हो सकता है जो मूल्य में परिवर्तन होने पर चेतावनी देता है (लेकिन पहला प्रदान करता है)। कम से कम तब इस पर ध्यान दिए जाने की अधिक संभावना है।

function useMyHook(a) {
  const initialA = usePossiblyStaleValue(a);
  // ...
}

function usePossiblyStaleValue(value) {
  const ref = useRef(value);

  if (process.env.NODE_ENV !== 'production') {
    if (ref.current !== value) { // Or your custom comparison logic
      console.error(
        'Unlike normally in React, it is not supported ' +
        'to pass dynamic values to useMyHook(). Sorry!'
      );
    }
  }

  return ref.current;
}

एक वैध मामला भी हो सकता है जहां आप अपडेट को संभाल नहीं सकते हैं । जैसे कि यदि निचले स्तर का एपीआई इसका समर्थन नहीं करता है, जैसे कि jQuery प्लगइन या DOM API। उस स्थिति में चेतावनी अभी भी उचित है ताकि आपके घटक का उपभोक्ता इसे समझ सके। वैकल्पिक रूप से, आप एक रैपर घटक बना सकते हैं जो असंगत अपडेट पर key को रीसेट करता है - ताजा प्रॉप्स के साथ एक साफ रिमाउंट को मजबूर करता है। यह शायद स्लाइडर या चेकबॉक्स जैसे पत्ते के घटकों के लिए बेहतर है।

"मेरा फ़ंक्शन मान स्थिर है"

• https://github.com/facebook/react/issues/14920#issuecomment -466399126 @btholt द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७४,२७,४८१ @joelmoss द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४७,०९,१५,९६९ @einarq द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -466416518 @svenanders द्वारा

सबसे पहले, यदि यह स्थिर है और शीर्ष स्तर के दायरे में फहराया गया है तो लिंटर शिकायत नहीं करेगा। लेकिन यह सहारा या संदर्भ से आने वाली चीजों में मदद नहीं करता है।

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

हालाँकि, यह एक गलत धारणा है कि फ़ंक्शन मान आवश्यक रूप से स्थिर होते हैं। वे विधि बंधन के कारण कक्षाओं में अधिक बार स्थिर होते हैं, हालांकि यह बग की अपनी सीमा बनाता है। लेकिन सामान्य तौर पर, किसी फ़ंक्शन घटक में किसी मान से अधिक बंद होने वाला कोई भी फ़ंक्शन स्थिर नहीं माना जा सकता है। लिंट रूल अब आपको यह बताने में अधिक स्मार्ट है कि आपको क्या करना है। (जैसे कि इसे प्रभाव के अंदर ले जाना - सबसे सरल सुधार - या इसे useCallback लपेटना।)

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

समस्या को ठीक करने के लिए आप अभी भी इसे useCallback में लपेट सकते हैं। याद रखें कि तकनीकी रूप से यह किसी फ़ंक्शन को बदलने के लिए मान्य है , और आप बग को जोखिम में डाले बिना इस मामले को अनदेखा नहीं कर सकते। जैसे onChange={shouldHandle ? handleChange : null} या एक ही स्थान पर foo ? <Page fetch={fetchComments /> : <Page fetch={fetchArticles /> रेंडर करना। या यहां तक ​​कि fetchComments जो मूल घटक स्थिति पर बंद हो जाता है। वही बदल सकता है। कक्षाओं के साथ, इसका व्यवहार चुपचाप बदल जाएगा लेकिन फ़ंक्शन संदर्भ वही रहेगा। तो आपका बच्चा उस अपडेट से चूक जाएगा - आपके पास वास्तव में बच्चे को अधिक डेटा पास करने के अलावा कोई विकल्प नहीं है। फ़ंक्शन घटकों और useCallback , फ़ंक्शन की पहचान स्वयं बदल जाती है - लेकिन केवल तभी जब आवश्यक हो। तो यह एक उपयोगी संपत्ति है और बचने में बाधा नहीं है।

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

useWarnAboutTooFrequentChanges([deps]);

यह आदर्श नहीं है और हमें इसे और बेहतर ढंग से संभालने के बारे में सोचना होगा। मैं मानता हूं कि इस तरह के मामले काफी घटिया होते हैं। नियम तोड़ने के बिना फिक्स rules स्थिर बनाना होगा, उदाहरण के लिए एपीआई को createTextInput(rules) बदलकर, और register और unregister को useCallback में लपेटना register और unregister हटा दें, और उन्हें एक अलग संदर्भ से बदलें जहां आप अकेले dispatch डालते हैं। फिर आप गारंटी दे सकते हैं कि आपके पास इसे पढ़ने से अलग फ़ंक्शन पहचान कभी नहीं होगी।

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

फ़ंक्शन निर्भरताओं को अनदेखा करना पूरी तरह से फ़ंक्शन घटकों और हुक के साथ खराब बग की ओर जाता है क्योंकि यदि आप ऐसा करते हैं तो वे पुराने प्रोप और स्थिति को देखते रहेंगे। इसलिए कोशिश करें कि जब आप कर सकते हैं तो न करें।

यौगिक मूल्य परिवर्तन पर प्रतिक्रिया

• https://github.com/facebook/react/issues/14920#issuecomment -+४६,७२,००,६०९ @aweary द्वारा

यह मेरे लिए अजीब है कि यह उदाहरण किसी ऐसी चीज़ के लिए प्रभाव का उपयोग क्यों करता है जो अनिवार्य रूप से एक ईवेंट हैंडलर है। एक ईवेंट हैंडलर में वही "लॉग" (मुझे लगता है कि यह एक फॉर्म सबमिट हो सकता है) करना अधिक उपयुक्त लगता है। यह विशेष रूप से सच है अगर हम सोचते हैं कि जब घटक अनमाउंट होता है तो क्या होता है। क्या होगा यदि यह प्रभाव निर्धारित होने के ठीक बाद अनमाउंट हो जाए? उस मामले में फॉर्म जमा करने जैसी चीजें सिर्फ "नहीं होनी चाहिए"। तो ऐसा लगता है कि प्रभाव वहां गलत विकल्प हो सकता है।

उस ने कहा कि आप अभी भी वही कर सकते हैं जो आपने कोशिश की थी - इसके बजाय fullName को setSubmittedData({firstName, lastName}) बनाकर, और फिर [submittedData] आपकी निर्भरता है, जिससे आप firstName पढ़ सकते हैं lastName ।

अनिवार्य/विरासत संहिता के साथ एकीकरण

• https://github.com/facebook/react/issues/14920#issuecomment -+४६,६३,७८,६५० @atomiks द्वारा
• https://github.com/facebook/react/issues/14920#issuecomment -+४६,८९,६६,०५५ @jamesmosier द्वारा

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

काश मैं किसी को नहीं भूलता! अगर मैंने किया या कुछ अस्पष्ट है तो मुझे बताएं। हम इससे सबक को जल्द ही कुछ डॉक्स में बदलने की कोशिश करेंगे।

@gaearon , मुद्दों में गोता लगाने और विभिन्न श्रेणियों में कार्रवाई वस्तुओं को सारांशित करने के लिए समय निकालने के लिए धन्यवाद। आपने अपने समापन सारांश टिप्पणी में मेरे नमूने (#14920 (टिप्पणी) @trevorgithub द्वारा) को याद किया । (मैं निश्चित रूप से सराहना करता हूं कि बहुत से लोगों से बहुत सारी प्रतिक्रिया हुई थी; मुझे लगता है कि मेरी मूल टिप्पणी छिपे हुए आइटम अनुभाग में कहीं न कहीं इस मुद्दे की टिप्पणियों के बीच में खो गई है)।

मुझे लगता है कि मेरा नमूना 'अनिवार्य/विरासत कोड के साथ एकीकरण' के अंतर्गत आएगा, हालांकि शायद अन्य श्रेणियां भी?

'अनिवार्य/विरासत संहिता के साथ एकीकरण' मुद्दों के मामले में, ऐसा लगता है कि ऐसा बहुत कुछ नहीं किया जा सकता है जो किया जा सकता है। उन मामलों में, कोई इस चेतावनी को कैसे नज़रअंदाज करेगा? मेरा अनुमान:
// eslint-disable-line react-hooks/exhaustive-deps

क्षमा करें मुझे यह याद आ गया।

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

आप इसके बारे में सोच रहे हैं "मैं किसी अन्य प्रोप तक किसी प्रोप में बदलाव को अनदेखा करना चाहता हूं"। लेकिन आप इसके बारे में यह भी सोच सकते हैं कि “मेरे घटक का राज्य में कार्य हो रहा है। जब दूसरा प्रोप बदलता है तो इसे प्रोप से अपडेट किया जाता है। ”

आम तौर पर व्युत्पन्न राज्य की अनुशंसा नहीं की जाती है लेकिन यहां ऐसा लगता है कि आप क्या चाहते हैं। इसे लागू करने का सबसे आसान तरीका कुछ ऐसा होगा:

const [currentGetData, setCurrentGetData] = useState(getData);
const [prevRefreshRequest, setPrevRefreshRequest] = useState(refreshRequest);

if (prevRefreshRequest !== refreshRequest) {
  setPrevRefreshRequest(refreshRequest);
  setCurrentGetData(getData);
}

useEffect(() => {
  currentGetData(someId);
}, [currentGetData, someId]);

आपको useCallback को getData आसपास रखना होगा जिसे आप पास कर रहे हैं।

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

एक ईवेंट हैंडलर में वही "लॉग" (मुझे लगता है कि यह एक फॉर्म सबमिट हो सकता है) करना अधिक उपयुक्त लगता है।

@gaearon जिस मुद्दे को मैं देख रहा हूं वह यह है कि ईवेंट हैंडलर में ऐसा करने का मतलब है कि अपडेट होने से पहले साइड इफेक्ट होता है। इस बात की कोई सख्त गारंटी नहीं है कि उस घटना के परिणामस्वरूप घटक सफलतापूर्वक फिर से प्रस्तुत हो जाएगा, इसलिए ईवेंट हैंडलर में ऐसा करना समय से पहले हो सकता है।

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

फिर ऐसा मामला है जहां यह दुष्प्रभाव async हो सकता है इसलिए useEffect से आपको सफाई कार्य मिलता है।

useReducer की समस्या भी है, जहां मैं जिस मूल्य को लॉग करना चाहता हूं वह ईवेंट हैंडलर में उपलब्ध नहीं होगा। लेकिन मुझे लगता है कि यह पहले से ही आप सभी के रडार पर है

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

मेरे पास अतिरिक्त पैरामीटर के साथ कार्यों को लपेटने और उन्हें पास करने के लिए एक सुविधा हुक है। यह इस तरह दिख रहा है:

function useBoundCallback(fn, ...bound) {
  return useCallback((...args) => fn(...bound, ...args), [fn, ...bound]);
}

(यह वास्तव में थोड़ा अधिक जटिल है क्योंकि इसमें कुछ अतिरिक्त विशेषताएं हैं लेकिन उपरोक्त अभी भी प्रासंगिक समस्या दिखाता है)।

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

इस प्रवाह का एक सरलीकृत उदाहरण यहां दिखाया गया है: https://codesandbox.io/s/vvv36834k5 ("जाओ!" पर क्लिक करना एक कंसोल लॉग दिखाता है जिसमें घटकों का पथ शामिल होता है)

समस्या यह है कि मुझे इस नियम के साथ 2 लिटर त्रुटियां मिलती हैं:

रिएक्ट हुक (एक्स) में एक लापता निर्भरता है: 'बाध्य'। या तो इसे शामिल करें या निर्भरता सरणी को हटा दें

रिएक्ट हुक (X) की निर्भरता सरणी में एक प्रसार तत्व है। इसका मतलब है कि हम सांख्यिकीय रूप से सत्यापित नहीं कर सकते कि आपने सही निर्भरताएँ पार की हैं या नहीं

मापदंडों की सूची का उपयोग करने के लिए इसे बदलना (यानी स्प्रेड ऑपरेटर का उपयोग नहीं करना) संस्मरण को नष्ट कर देगा, क्योंकि सूची प्रत्येक आह्वान के साथ बनाई गई है, भले ही पैरामीटर समान हों।

विचार:

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

हाय @gaearon , मुझे अभी यह चेतावनी मिली है, जिसकी चर्चा मैंने कहीं नहीं की है:

Accessing 'myRef.current' during the effect cleanup will likely read a different ref value because by this time React has already updated the ref. If this ref is managed by React, store 'myRef.current' in a variable inside the effect itself and refer to that variable from the cleanup function.

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

मेरा मामला, अगर दिलचस्प है: कोडसैंडबॉक्स
प्रसंग: कुछ कस्टम डेटा फ़ेचिंग हुक। मैं एक रेफरी में एक काउंटर का उपयोग दौड़ की स्थिति और अनमाउंट घटकों पर अपडेट दोनों को रोकने के लिए करता हूं।

मुझे लगता है कि मैं इस चेतावनी को किसी फ़ंक्शन के अंदर पढ़ने वाले रेफरी को छुपाकर, या क्लीनअप केस के लिए एक और बूलियन रेफरी बनाकर इस चेतावनी को रोक सकता हूं। लेकिन अगर मैं इस चेतावनी को अनदेखा कर सकता हूं तो मुझे अनावश्यक रूप से वर्बोज़ लगता है।

@ भयभीत

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

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

@ डेविडजे13

क्या यह पहली त्रुटि दिखाने लायक है जब दूसरी भी लागू होती है?

कृपया लिंट नियम को बदलने के प्रस्तावों के लिए एक नया मुद्दा दर्ज करें।

क्या कोई तरीका है जिससे मैं इस नियम को विशेष रूप से उन जगहों के लिए अक्षम कर सकता हूं जहां स्प्रेड ऑपरेटर का उपयोग किया जाता है?

आप हमेशा // eslint-disable-next-line react-hooks/exhaustive-deps यदि आपको लगता है कि आप जानते हैं कि आप क्या कर रहे हैं।

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

कृपया एक नया मुद्दा दर्ज करें।

@CarlosGines

मुझे यह संदेश थोड़ा भ्रमित करने वाला लगता है। मुझे लगता है कि यह मुझे चेतावनी देने की कोशिश करता है कि सफाई पर रेफरी वर्तमान मूल्य प्रभाव निकाय के मूल्य से अलग हो सकता है। सही?

हां।

यदि ऐसा है, और इसके बारे में जागरूक होने के कारण, क्या इस चेतावनी को अनदेखा करना सुरक्षित/वैध है?

उम्म्म .. अगर वह बग की ओर जाता है तो नहीं। मैं

प्रसंग: कुछ कस्टम डेटा फ़ेचिंग हुक। मैं एक रेफरी में एक काउंटर का उपयोग दौड़ की स्थिति और अनमाउंट घटकों पर अपडेट दोनों को रोकने के लिए करता हूं।

हाँ शायद यह उपयोग मामला वैध है। pls पर चर्चा करने के लिए एक नया मुद्दा दर्ज करें?

मैं इस मुद्दे को बंद करने जा रहा हूं क्योंकि हमें पर्याप्त प्रतिक्रिया मिली है और इसे शामिल किया गया है।

सामान्य प्रश्न और उत्तर: https://github.com/facebook/react/issues/14920#issuecomment -471070149

यदि आप useEffect और निर्भरता पर एक गहरा गोता लगाना चाहते हैं, तो यह यहाँ है: https://overreacted.io/a-complete-guide-to-useeffect/

हम जल्द ही दस्तावेज़ में और सामग्री भी जोड़ेंगे.

यदि आप नियम में कुछ बदलना चाहते हैं या सुनिश्चित नहीं हैं कि आपका मामला वैध है, तो एक नया मुद्दा दर्ज करें।