Definitelytyped: [@ प्रकार/प्रतिक्रिया] RefObject.current अब केवल पढ़ने के लिए नहीं होना चाहिए

एक जनसंपर्क की सराहना की जाएगी! यह एक बहुत ही आसान एक लाइन परिवर्तन होना चाहिए

@ferdaber ,
नमस्ते, मैं इस मुद्दे को चुनना पसंद करता हूं। जैसा कि मैं टाइपस्क्रिप्ट के लिए नया हूं (सिर्फ एक सप्ताह) और ओपन सोर्स में यह मेरा पहला योगदान होगा।

मैं node_modules/@types/react/index.d.ts से गुजरा हूं और लाइन नंबर 61 पर निम्नलिखित कोड है जो करंट को रीडोनली घोषित करता है।

interface RefObject<T> {
        readonly current: T | null;
    }

अगर यह मुद्दा है, तो मैं हल कर सकता हूं। क्या आप मेरे पहले पीआर के लिए मार्गदर्शन कर सकते हैं?
अपना समय देने के लिए धन्यवाद :)

हां, यह सिर्फ उस लाइन पर readonly संशोधक को हटा रहा है।

React.useRef एक MutableRefObject $ लौटाता है जिसकी current संपत्ति readonly नहीं है। मुझे लगता है कि सवाल यह है कि क्या रेफ ऑब्जेक्ट प्रकारों को एकीकृत किया जाना चाहिए।

उन्हें एकीकृत किया जाना चाहिए, रिएक्ट रनटाइम की current द्वारा बनाई गई संपत्ति पर कोई सीमा नहीं है React.createRef() , वस्तु स्वयं सील है लेकिन जमी नहीं है।

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

यदि आप एक परिवर्तनीय रेफ ऑब्जेक्ट चाहते हैं जो शून्य मान से शुरू होता है, तो सामान्य तर्क को | null भी देना सुनिश्चित करें। यह इसे उत्परिवर्तनीय बना देगा, क्योंकि आप इसे "स्वामित्व" करते हैं और प्रतिक्रिया नहीं करते हैं।

शायद यह मेरे लिए समझना आसान है क्योंकि मैंने पहले भी अक्सर सूचक-आधारित भाषाओं के साथ काम किया है और उनमें स्वामित्व _very_ महत्वपूर्ण है। और यही रेफरी हैं, एक सूचक। .current सूचक को संदर्भित कर रहा है।

यह उचित है, मैं केवल एक पॉइंटर बनाने के लिए एक सहायक फ़ंक्शन के रूप में React.createRef() का उपयोग कर रहा हूं, क्योंकि रिएक्ट इसे तब तक प्रबंधित नहीं करेगा जब तक कि इसे ref प्रोप के रूप में पारित नहीं किया जाता है, लेकिन आप बस के रूप में कर सकते हैं अच्छी तरह से एक ही संरचना के साथ एक साधारण सूचक वस्तु बनाएं।

हम समान अधिभार तर्क रखने के लिए createRef को संशोधित कर सकते हैं, लेकिन क्योंकि कोई तर्क नहीं है, इसे सशर्त प्रकार की वापसी के साथ होना होगा। यदि आप | null शामिल करते हैं तो यह MutableRefObject लौटाएगा, यदि आप नहीं करते हैं तो यह (अपरिवर्तनीय) RefObject होगा।

क्या यह उन लोगों के लिए काम करेगा जिनके पास strictNullTypes सक्षम नहीं है, हालांकि?

मैं

क्या हमें वास्तव में उन लोगों के लिए गलत कोड लिखना आसान बनाना चाहिए जिनमें _do_ में strictNullTypes सक्षम है?

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

चूंकि यह मुद्दा स्वयं useRef पर आधारित था और createRef पर नहीं था, इसलिए मैं इसे बंद करने के साथ भी ठीक हूं क्योंकि वहां बहुत कम लोग createRef में सीधे संदर्भित सूचक मान को संशोधित करते हैं।

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

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

मैं ऐसा ही सोच रहा था। @ कोवेन्स्की आपके क्या विचार हैं?

@ferdaber useRef जैसा कि अभी परिभाषित किया गया है, हमेशा परिवर्तनशील _और_ अशक्त नहीं होगा जब तक कि आप दोनों इसे स्पष्ट रूप से एक सामान्य तर्क नहीं देते हैं जिसमें | null और null का प्रारंभिक मूल्य शामिल नहीं है।

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

रिएक्ट के दस्तावेज़ीकरण और प्रारंभिक मूल्य के बिना useRef का उपयोग करने में समस्या यह है कि रिएक्ट टीम null और undefined के बीच के अंतर के बारे में ज्यादा परवाह नहीं करती है। यह एक फ्लो चीज हो सकती है।

वैसे भी, जिस तरह से मैंने useRef परिभाषित किया है वह बिल्कुल @bschlenk के उपयोग के मामले में फिट बैठता है, केवल null "छोड़े गए" मान है, जिन कारणों से मैंने ऊपर उल्लेख किया है।

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

मुझे लगता है कि यह वैसे ही ठीक है, बस थोड़ा अजीब है कि चाहे आप | null शामिल करें, current का प्रकार अभी भी शून्य हो सकता है, बस परिवर्तनशीलता बदल गई है। साथ ही, प्रतिक्रिया दस्तावेज़ हमेशा स्पष्ट रूप से शून्य हो जाते हैं, तो क्या यह प्रारंभिक वैल्यू को छोड़ने के लिए भी मान्य है?

यह आम तौर पर नहीं है, और कम से कम अतीत में जब मैंने बताया कि दस्तावेज़ के कुछ टुकड़े में रिएक्ट टीम ने कहा था कि "भले ही यह काम करता हो" इसे छोड़े जाने का इरादा नहीं है।

यही कारण है कि createContext के लिए पहला तर्क आवश्यक है, उदाहरण के लिए, भले ही आप किसी संदर्भ को undefined से शुरू करना चाहते हों। आपको वास्तव में undefined पास करना होगा।

ऐसा लगता है कि कुछ उपयोगों में यह पैरामीटर का उपयोग नहीं कर रहा है:

https://reactjs.org/docs/hooks-faq.html#is -there-something-like-instance-variables
https://reactjs.org/docs/hooks-faq.html#how -to-get-the-previous-props-or-state
https://reactjs.org/docs/hooks-faq.html#how -to-read-an-often-changeing-value-from-usecallback

@ferdaber ऐसा इसलिए है क्योंकि वे वहां के प्रकारों की परवाह नहीं कर रहे हैं। useRef() (कोई तर्क नहीं) में किस प्रकार का current होना चाहिए? undefined ? any ? जो भी हो, भले ही आप एक सामान्य तर्क दें, इसे | एड के साथ undefined होना चाहिए। _And_ यदि यह एक रेफरी है जिसे आप प्रतिक्रिया तत्व रेफरी के रूप में उपयोग करते हैं (न केवल थ्रेड स्थानीय भंडारण के रूप में) तो आपको | null भी करना होगा क्योंकि प्रतिक्रिया वहां null लिख सकती है।

अब आप स्वयं को केवल T $ के बजाय current के रूप में T | null | undefined के रूप में पाते हैं।

// you should always give an argument even if the docs sometimes miss them
// $ExpectError
const ref1 = useRef()
// this is a mutable ref but you can only assign `null` to it
const ref2 = useRef(null)
// this is also a mutable ref but you can only assign `undefined`
const ref3 = useRef(undefined)
// this is a mutable ref of number
const ref4 = useRef(0)
// this is a mutable ref of number | null
const ref5 = useRef<number | null>(null)
// this is a mutable ref with an object
const ref6 = useRef<React.CSSProperties>({})
// this is a mutable ref that can hold an HTMLElement
const ref7 = useRef<HTMLElement | null>(null)
// this is the only case where the ref is immutable
// you did not say in the generic argument you want to be able to write
// null into it, but you gave a null anyway.
// I am taking this as the sign that this ref is intended
// to be used as an element ref (i.e. owned by React, you're only sharing)
const ref8 = useRef<HTMLElement>(null)
// not allowed, because you didn't say you want to write undefined in it
// this is essentially what would happen if we allowed useRef with no arguments
// to make it worse, you can't use it as an element ref, because
// React might write a null into it anyway.
// $ExpectError
const ref9 = useRef<HTMLElement>(undefined)

हाँ यह डीएक्स मेरे लिए काम करता है, और दस्तावेज़ीकरण ए ++ है इसलिए मुझे नहीं लगता कि ज्यादातर लोग इस पर भ्रमित होंगे। इस विस्तार के लिए धन्यवाद! ईमानदारी से आपको इस मुद्दे को टाइपडॉक में सिर्फ परमालिंक करना चाहिए :)

useRef<T>() का समर्थन करने और इसे useRef<T | undefined>(undefined) के समान व्यवहार करने का मामला हो सकता है; लेकिन इसके साथ आप जो भी रेफरी बनाते हैं उसे अभी भी एक तत्व रेफरी के रूप में उपयोग नहीं किया जा सकता है, जैसे थ्रेड स्थानीय स्टोरेज।

समस्या यह है कि... क्या होता है यदि आप एक सामान्य तर्क देते हैं, जिसकी अनुमति है? टाइपस्क्रिप्ट केवल {} अनुमान लगाएगा। सही डिफ़ॉल्ट प्रकार unknown है लेकिन हम इसका उपयोग नहीं कर सकते।

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

~~~ जेएस
//...
अंतराल रेफ = उपयोग करने दें(शून्य); // let . के बजाय const के साथ भी प्रयास किया
//...
उपयोग प्रभाव (() => {
कास्ट अंतराल = सेटइंटरवल (() => {/* कुछ करें */}, 1000);
इंटरवल रेफ। करंट = अंतराल; // इस पंक्ति में मुझे त्रुटि मिल रही है

return () => {
    clearInterval(intervalRef.current);
}

})
//...
~और जब मैं यहां readonly हटाता हूं तो यह काम करता है:~ जेएस
इंटरफ़ेस RefObject{
रीडओनली करंट: टी | शून्य;
}
~~~

मैं रीक हुक और टाइपस्क्रिप्ट दोनों के साथ नया हूं (बस उन्हें एक साथ आज़मा रहा हूं) इसलिए मेरा कोड गलत हो सकता है

डिफ़ॉल्ट रूप से यदि आप null डिफ़ॉल्ट मान के साथ एक रेफरी बनाते हैं और इसके सामान्य पैरामीटर को निर्दिष्ट करते हैं तो आप संदर्भ को "स्वयं" प्रतिक्रिया देने के अपने इरादे को इंगित कर रहे हैं। यदि आप अपने स्वयं के रेफरी को बदलने में सक्षम होना चाहते हैं तो आपको इसे इस तरह घोषित करना चाहिए:

const intervalRef= useRef<NodeJS.Timeout | null>(null) // <-- the generic type is NodeJS.Timeout | null

@ferdaber इसके लिए धन्यवाद!

इसे एक चरण और आगे ले जाना और current के रिटर्न प्रकार को देखते हुए, क्या यह शायद T के बजाय T | null #$1$#$ होना चाहिए? हुक के आगमन के साथ, हमारे पास _हमेशा नहीं_ यह मामला है कि सभी रेफरी null हो सकते हैं, विशेष रूप से अक्सर ऐसे मामले में जहां useRef को गैर-शून्य प्रारंभकर्ता के साथ बुलाया जाता है।

उत्कृष्ट उदाहरण सूची से आगे बढ़ते हुए https://github.com/DefinitelyTyped/DefinitelyTyped/issues/31065#issuecomment -446660394, अगर मैं लिखता हूं:

const numericRef = useRef<number>(42);

numericRef.current किस प्रकार का होना चाहिए? इसके number | null होने के लिए कोई _need_ नहीं है।

यदि हम प्रकारों और कार्यों को इस प्रकार परिभाषित करते हैं:

interface RefObject<T> {
  current: T;
}

function useRef<T>(initialValue: T): RefObject<T>;
function useRef<T>(initialValue: T|null): RefObject<T | null>;

function createRef<T>(): RefObject<T | null>;

जो निम्नलिखित उपयोगों और प्रकारों का उत्पादन करेगा:

const r1 = useRef(42);
// r1 is of type RefObject<number>
// r1.current is of type number (not number | null)

const r2 = useRef<number>(null);
// r2 is of type RefObject<number | null>
// r2.current is of type number | null

const r3 = useRef(null);
// r3 is of type RefObject<null>
// r3.current is of type null

const r4 = createRef<number>();
// r4 is of type RefObject<number | null>
// r4.current is of type number | null

क्या वहां कुछ गलत है?

रिएक्ट टीम के अनुसार, "एक अपरिमेय useRef का प्रकार क्या है?" के उत्तर के लिए, उत्तर यह है कि वह कॉल (दस्तावेजीकरण के बावजूद) गलत है।

मैंने डीओएम/घटक रेफरी के लिए सुविधा अधिभार के रूप में |null _specifically_ के साथ अधिभार जोड़ा, क्योंकि वे हमेशा शून्य शुरू करते हैं, वे हमेशा अनमाउंट पर शून्य पर रीसेट हो जाते हैं, और आप कभी भी वर्तमान को पुन: असाइन नहीं करते हैं, केवल प्रतिक्रिया करते हैं।

वास्तविक जावास्क्रिप्ट फ्रोजन ऑब्जेक्ट/गेटर-ओनली प्रॉपर्टी के प्रतिनिधित्व की तुलना में लॉजिक त्रुटियों से बचाव के लिए केवल पढ़ने के लिए और भी कुछ है।

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

आह, हाँ, अब मैं देख रहा हूँ कि MutableRefObject<T> की तुलना में RefObject<T> | null मामले को पहले ही हटा दिया गया है। तो useRef<number>(42) मामला पहले से ही सही ढंग से काम करता है। स्पष्टीकरण के लिए धन्यवाद!

हमें createRef के साथ क्या करने की ज़रूरत है? अभी यह एक अपरिवर्तनीय RefObject<T> लौटाता है, जो हमारे कोडबेस में समस्याएं पैदा कर रहा है क्योंकि हम उन्हें पास करना चाहते हैं और उन्हें उसी तरह (म्यूटेबल) useRef रेफ ऑब्जेक्ट्स के रूप में उपयोग करना चाहते हैं। क्या कोई तरीका है जिससे हम createRef टाइपिंग में बदलाव कर सकते हैं ताकि इसे म्यूटेबल रेफ ऑब्जेक्ट बनाने की अनुमति मिल सके?

(और ref विशेषता को Ref<T> प्रकार के रूप में परिभाषित किया गया है जिसमें RefObject<T> शामिल है, जिससे सब कुछ अपरिवर्तनीय हो जाता है। यह हमारे लिए एक बड़ी समस्या है: भले ही हमें एक परिवर्तनीय useRef से देखें, हम इस तथ्य का उपयोग नहीं कर सकते हैं कि यह forwardRef कॉल के माध्यम से अपरिवर्तनीय है।)

हम्म ... शायद हम एक ही चाल का उपयोग कर सकते हैं, केवल इसलिए कि इसमें कोई तर्क नहीं है (और हमेशा शून्य के रूप में शुरू होता है) इसे एक सशर्त प्रकार की आवश्यकता होगी।

: null extends T ? MutableRefObject<T> : RefObject<T> को उसी तर्क को करना चाहिए और उसका उपयोग करना चाहिए। यदि आप कहते हैं कि आप इसमें नल डालना चाहते हैं तो यह परिवर्तनशील है, यदि आप नहीं करते हैं तो यह अभी भी वर्तमान अर्थ में अपरिवर्तनीय है।

यह बहुत अच्छा विचार है। चूंकि createRef कोई पैरामीटर नहीं लेता है, इसलिए संभवतः इसे हमेशा | null विकल्प शामिल करने की आवश्यकता होती है ( useRef के विपरीत), ताकि शायद MutableRefObject<T | null> कहने की आवश्यकता हो?

मैं या तो टीएस में काम करने में सक्षम नहीं हूं। यहाँ TS खेल का मैदान इसके साथ कॉन्फ़िगर किया गया है:
https://tinyurl.com/y75c32y3

प्रकार को हमेशा MutableRefObject के रूप में पहचाना जाता है।

आपको क्या लगता है कि हम forwardRef के साथ क्या कर सकते हैं? यह ref को Ref<T> घोषित करता है, जिसमें MutableRefObject की संभावना शामिल नहीं है।

(हमारा उपयोग मामला जो कठिनाई पैदा कर रहा है वह mergeRefs फ़ंक्शन का है जो रेफरी की एक सरणी लेता है, जो या तो कार्यात्मक रेफरी या रेफरी ऑब्जेक्ट हो सकता है, और एक संयुक्त रेफरी [एक कार्यात्मक रेफरी] बनाता है जिसे पारित किया जा सकता है एक घटक के लिए। वह संयुक्त रेफरी तब किसी भी आने वाले संदर्भित तत्व को सभी प्रदान किए गए रेफरी को वितरित करता है, या तो उन्हें कॉल करके यदि वे कार्यात्मक रेफरी हैं, या .current सेट करके यदि वे रेफरी ऑब्जेक्ट हैं। लेकिन अस्तित्व अपरिवर्तनीय RefObject<T> और MutableRefObject<T> in Ref<T> को शामिल करने की कमी इसे कठिन बना देती है। क्या मुझे फॉरवर्डरेफ और रेफ के लिए एक अलग मुद्दा उठाना चाहिएमुश्किलें?)

हम ऊपर वर्णित कारणों के लिए useRef के प्रकार को नहीं बदल रहे हैं (हालांकि createRef अभी भी चर्चा में है), क्या आपके पास तर्क पर कोई प्रश्न हैं?

क्या मुझे https://github.com/DefinitelyTyped/DefinitelyTyped/issues/31065#issuecomment -457650501 में शामिल वस्तुओं के लिए एक अलग मुद्दा उठाना चाहिए?

हाँ, चलिए इसे अलग करते हैं।

यदि आप एक परिवर्तनीय रेफ ऑब्जेक्ट चाहते हैं जो शून्य मान से शुरू होता है, तो सामान्य तर्क को | null भी देना सुनिश्चित करें। यह इसे उत्परिवर्तनीय बना देगा, क्योंकि आप इसे "स्वामित्व" करते हैं और प्रतिक्रिया नहीं करते हैं।

इसके लिए धन्यवाद! useRef जेनेरिक में शून्य जोड़ने से यह मेरे लिए हल हो गया।

पहले

const ref = useRef<SomeType>(null) 

// Later error: Cannot assign to 'current' because it is a constant or a read-only property.

बाद

const ref = useRef<SomeType | null>(null)

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

मैंने निम्नलिखित हुक बनाया:

export const useCombinedRefs = <T>(...refs: Ref<T>[]) =>
    useCallback(
        (element: T) =>
            refs.forEach(ref => {
                if (!ref) {
                    return;
                }

                if (typeof ref === 'function') {
                    ref(element);
                } else {
                    ref.current = element; // this line produces error
                }
            }),
        refs,
    );

और मुझे एक त्रुटि मिलती है: "'वर्तमान' को असाइन नहीं किया जा सकता क्योंकि यह केवल-पढ़ने के लिए संपत्ति है।"
क्या current को लिखने योग्य में बदले बिना इसे हल करने का कोई तरीका है?

इसके लिए आपको धोखा देना पड़ेगा।

(ref.current as React.MutableRefObject<T> ).current = element;

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

हम समान अधिभार तर्क रखने के लिए createRef को संशोधित कर सकते हैं, लेकिन क्योंकि कोई तर्क नहीं है, इसे सशर्त प्रकार की वापसी के साथ होना होगा। यदि आप | null शामिल करते हैं तो यह MutableRefObject लौटाएगा, यदि आप नहीं करते हैं तो यह (अपरिवर्तनीय) RefObject होगा।

बहुत - बहुत धन्यवाद

(ref.current as React.MutableRefObject<T>).current = element;

होना चाहिए:

(ref as React.MutableRefObject<T>).current = element;

आप प्रतिक्रिया के आंतरिक व्यवहार की नकल कर रहे हैं

क्या इसका मतलब यह है कि यहां दस्तावेज़ पुराने हैं? क्योंकि वे स्पष्ट रूप से इसे एक इच्छित कार्यप्रवाह के रूप में वर्णित करते हैं, आंतरिक व्यवहार के रूप में नहीं।

उस मामले में दस्तावेज़ आपके स्वामित्व वाले रेफरी का जिक्र कर रहे हैं, लेकिन उन रेफरी के लिए जिन्हें आप एक HTML तत्व के लिए ref विशेषता के रूप में पास करते हैं, तो उन्हें केवल पढ़ने के लिए _to you_ होना चाहिए।

function Component() {
  // same API, different type semantics
  const countRef = useRef<number>(0); // not readonly
  const divRef = useRef<HTMLElement>(null); // readonly

  return <button ref={divRef} onClick={() => countRef.current++}>Click me</button>
}

मेरा बुरा, आगे स्क्रॉल करना चाहिए था। मेरे स्वामित्व वाले रेफरी के लिए readonly के बारे में एक त्रुटि मिली और मान लिया कि यह वही मामला था। (मैं अब एक अलग वर्कफ़्लो का उपयोग करता हूं और अब और त्रुटि को पुन: उत्पन्न नहीं कर सकता, दुर्भाग्य से ...)

वैसे भी, स्पष्टीकरण के लिए बहुत बहुत धन्यवाद!

मैं अस्पष्ट हूं कि विषय का createRef भाग स्थानांतरित हो गया है - लेकिन मैं यहां भी पोस्ट करूंगा।

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

क्या रिएक्ट नेटिव का प्रकार अलग होना चाहिए?

देखें: https://reactnavigation.org/docs/navigating-without-navigation-prop

@sylvanaar
नेविगेशन शुरू करते समय मुझे भी इस समस्या का सामना करना पड़ा, क्या आपको कोई समाधान मिला है?

जो मैंने अभी पढ़ा है उसका सारांश: createRef<T> द्वारा बनाए गए रेफरी के लिए मान सेट करने का एकमात्र तरीका यह है कि हर बार जब आप इसका इस्तेमाल करते हैं तो इसे डालना है? इसके पीछे क्या तर्क है? उस स्थिति में readonly व्यावहारिक रूप से सेटिंग्स को रेफरी के लिए एक मान को रोक रहा है, इसलिए फ़ंक्शन के पूरे उद्देश्य को हरा रहा है।

TLDR: यदि आपका प्रारंभिक मान null (विवरण: या प्रकार पैरामीटर के बाहर कुछ और) है, तो अपने प्रकार पैरामीटर में | null जोड़ें, और इससे .current सक्षम होना चाहिए सामान्य पसंद करने के लिए सौंपा जाना।