React: क्या ComponentDidMount के भीतर नए संदर्भ एपीआई का उपयोग करने का एक तरीका है?

एक उदाहरण जोड़ना कि मैं यह काम करने की कोशिश कर रहा हूं: https://codesandbox.io/s/l20yn296w7

EDIT: https://github.com/reactjs/rfcs/blob/master/text/0002-new-version-of-context.md#class -based-api से दिशानिर्देशों का पालन

नई एपीआई के साथ इसे हासिल किया जा सकता है।

class BaseMapElement extends React.Component {
  componentDidMount() {
    console.log(this.props.context);
  }

  render() {
    return null;
  }
}

const MapElement = () => (
  <Context.Consumer>
    {context =>
      <BaseMapElement context={context} />
    }
  </Context.Consumer>
)

तो componentDidMount माध्यम से पहुंचने का एकमात्र तरीका प्रॉप्स में पुनर्निर्देशित करना है?

संपादित करें: componentDidMount बदला गया

उच्च क्रम घटक जो प्रॉप्स को फिर से विभाजित करता है वह एक अच्छा पैटर्न है, लेकिन ऐसे मामलों के लिए जहां अतिरिक्त घटक आमतौर पर वाट नहीं होता है I मैं घटक के उदाहरण पर संदर्भ मूल्य को संग्रहीत करता हूं जैसे: this.contextValue = value तब इसे एक्सेस करें जीवन चक्र हुक। यह थोड़ा बदसूरत है, लेकिन यह ठीक है आम तौर पर मुझे लगता है कि आपके विकल्प के रूप में निकर, हॉक, पैटर्न को ऑप्टिमाइज़ करने के बाद

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

घटक उदाहरण पर संदर्भ मान को संग्रहीत करें: this.contextValue = मान फिर इसे जीवन चक्र हुक में एक्सेस करें

मुझे पूरा यकीन है कि यह async मोड में असुरक्षित है। कृपया ऐसा न करें। cc @acdlite

हाँ यह हमारे घटक को दूसरे घटक में लपेटकर हल किया जा सकता है! लेकिन एक समाधान की तुलना में अधिक समाधान की तरह लगता है।

मैं इस से सहमत हूँ। componentDidMount और componentWillUnmount माध्यम से मूल रूप से उपयोग करना अच्छा होगा / चीजों को आरम्भ करने में सक्षम होने के लिए,

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

tl; dr: अप्रत्यक्ष रूप से प्रॉप्स का उपयोग करें। और अतिरिक्त घटक के बारे में बहुत चिंता न करें।

मुझे पूरा यकीन है कि यह async मोड में असुरक्षित है। कृपया ऐसा न करें।

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

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

क्षमा करें, अगर ऊपर से गुस्सा / गुस्सा आ रहा है, तो मैंने उस स्वर का इरादा नहीं किया है! फहुओन पर

इसने गुस्से में हाहा किया लेकिन मुझे आपकी बात समझ में आ गई और मैं आपके सवालों को साझा करता हूं कि यह कैसे / क्यों असुरक्षित होगा

यह एक बूगीमैन की तरह महसूस करने लगा है जो व्यवहार तर्कहीन और अप्रत्याशित है

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

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

यह कैसे असुरक्षित होगा (और किस तरीके से)?

क्या आपको मेरी बात देखने का मौका मिला? यह समझाने में थोड़ा मुश्किल होगा कि अगर आपने इसका दूसरा भाग नहीं देखा है, क्योंकि यह स्पष्ट नहीं होगा कि हम ऐसा

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

Async में, अंगूठे का नियम है: केवल जीवन चक्र जैसे componentDidMount , componentDidUpdate , और componentWillUnmount और Ref कॉलबैक प्रॉप्स और राज्य के साथ समय पर अच्छी तरह से परिभाषित बिंदुओं पर निष्पादित होते हैं जो कि अनुरूप होते हैं स्क्रीन पर क्या है। सौभाग्य से हमारे पास केवल कुछ अन्य जीवन चक्र हैं जो बड़े करीने से इस तस्वीर में फिट नहीं होते हैं, और हम उनके लिए बेहतर विकल्प पेश कर रहे हैं ( getDerivedPropsFromState , getSnapshotBeforeUpdate )। यह एक क्रमिक प्रवासन होगा। फिर, यह सब ब्लॉग पोस्ट में होने जा रहा है।

अब इस मुद्दे की जड़ तक। Async मोड में, React कब और किस क्रम में render पद्धति को कॉल करता है, इस render में एक फ़ील्ड को संग्रहीत करना और फिर इसे एक जीवनचक्र में पढ़ना "सुरक्षित" नहीं है, क्योंकि आप उस समय एक फ़ील्ड स्टोर कर सकते हैं, जिसे रिएक्ट render विभिन्न प्रॉप्स के साथ (जैसे कि एक निलंबित पेड़ के लिए) अभी तक तैयार नहीं है)।

जीवन-चक्र विधियों में संदर्भ तक पहुंचने या कॉल करने का एक आसान तरीका होना चाहिए।
हाँ यह हमारे घटक को दूसरे घटक में लपेटकर हल किया जा सकता है! लेकिन एक समाधान की तुलना में अधिक समाधान की तरह लगता है।

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

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

class Button extends React.Component {
  componentDidMount() {
    alert(this.props.theme);
  }

  render() {
    const { theme, children } = this.props;
    return (
      <button className={theme ? 'dark' : 'light'}>
        {children}
      </button>
    );
  }
}

export default React.forwardRef((props, ref) => (
  <ThemeContext.Consumer>
    {theme => <Button {...props} theme={theme} ref={ref} />}
  </ThemeContext.Consumer>
));

यह contextTypes परिभाषा के रूप में लगभग समान राशि है।

हाँ यह हमारे घटक को दूसरे घटक में लपेटकर हल किया जा सकता है! लेकिन एक समाधान की तुलना में अधिक समाधान की तरह लगता है।

डैन ने यह कहना चाहा कि चाइल्ड फंक्शन / रेंडर प्रॉपर अप्रोच नए संदर्भ के लिए _official API_ है, इसलिए कृपया इसका उपयोग करें और रिएक्ट को यह सुनिश्चित करने की चिंता करने दें कि यह जल्दी है (यह!)

यह कैसे असुरक्षित होगा (और किस तरीके से)?

ड्राफ्ट स्ट्रिक्ट मोड डॉक्स इस बात को भी छूते हैं कि क्यों कुछ उदाहरणों को बदलना (जो कि एक अन्य प्रकार का साइड इफेक्ट है) async मोड में खतरनाक है।

हमारे यहां प्रस्तावित दिशानिर्देशों के बाद हमारी एक प्रयोगात्मक शाखा है। किसी को देखने के लिए अगर यह समझ में आता है कर सकते हैं? https://github.com/commodityvectors/react-mapbox-gl/pull/11

मैं इस लाइब्रेरी से परिचित नहीं हूं, इसलिए मुझे नहीं पता कि क्या लोग कभी भी इसके घटकों के साथ रेफ का उपयोग करते हैं- लेकिन अगर उन्होंने किया, तो उस पीआर पर withContext मिक्सिन हो सकता है, यह एक अच्छा उपयोग मामला हो सकता है नया forwardRef API ।

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

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

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

const MapElement = (props) => (
  <Context.Consumer>
    {context =>
      <RunOnLifecycle
        runOnMount={() => { /*use context*/ }}
        runOnUnMount={() => { /*use context*/ }}
        runOnUpdate={(prevProps) => { /*use context - compare prevProps with props */ }}
        { ...props }
      />
    }
  </Context.Consumer>
)

और वह सहायक घटक <RunOnLifecycle/> :

export interface IPropsRunOnLifecycle {
  runOnMount?: () => void;
  runOnUpdate?: (prevProps: object) => void;
  runOnUnMount?: () => void;
  children?: JSX.Element | ReactNode;
  [prop: string]: any;
}

export class RunOnLifecycle extends React.Component<IPropsRunOnLifecycle> {
  componentDidUpdate(prevProps, prevState, snapshot) {
    if (this.props.runOnUpdate != null) {
      this.props.runOnUpdate(prevProps);
    }
  }

  componentDidMount() {
    if (this.props.runOnMount != null) {
      this.props.runOnMount();
    }
  }

  componentWillUnmount() {
    if (this.props.runOnUnMount != null) {
      this.props.runOnUnMount();
    }
  }

  render() { return this.props.children || null; }
}

आश्चर्य है कि यह लाइन के नीचे किसी भी सिरदर्द का कारण बनने वाला है। अभी भी लगता है कि बहुत मानक प्रतिक्रिया की तरह, अगर एक हैक के कुछ।

कुछ सूक्ष्म अंतर हैं जो एक बुरे विचार के दृष्टिकोण को बना सकते हैं। उदाहरण के लिए, यदि MapElement एक वर्ग घटक था जो Refs का उपयोग करता था, तो जब runOnMount कॉलबैक चलाया जाता था, तो refs को सेट नहीं किया जाएगा।

😄 मैं इसके बदले HOC दृष्टिकोण का उपयोग करने का सुझाव दूंगा:
https://reactjs.org/docs/context.html#consuming -context-with-a-hoc

इस तरह की चीज़ के लिए HOC का उपयोग करने का एकमात्र वास्तविक पहलू forwardRef API द्वारा कम कर दिया गया है:
https://reactjs.org/docs/react-api.html#reactforwardref

हमने प्रतिक्रिया डॉक्स की तरह दृष्टिकोण लिया और लोगों ने यहां क्या कहा। यह हमारे लिए अब तक अच्छा काम कर रहा है।

https://github.com/commodityvectors/react-mapbox-gl/blob/master/src/Map.js#L63

कुछ सूक्ष्म अंतर हैं जो एक बुरे विचार के दृष्टिकोण को बना सकते हैं। उदाहरण के लिए, यदि MapElement एक वर्ग घटक था जो Refs का उपयोग करता था, तो जब तक RunOnMount कॉलबैक चलाया गया था, तो Refs सेट नहीं होंगे।

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

अगर मुझे कुछ भी करने की आवश्यकता है, जो रेफ के साथ बातचीत करता है, तो ध्यान रखें।

ज़रा सुनिए सभी,

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

मैं वास्तव में इसकी सराहना करूंगा अगर कोई साझा कर सकता है कि मैं इस परिदृश्य के लिए परीक्षण के मामले कैसे लिख सकता हूं।

मैं एंजाइम, एंजाइम-एडेप्टर-रिएक्शन -16 और जेस्ट का उपयोग कर रहा हूं लेकिन ऐसा करने में कुछ परेशानी हो रही है।

@AmnArora

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

उदाहरण के लिए

// MyComponent.js
export class MyComponent extends Component { /* ... */ }
export default HOC()(MyComponent)

// MyComponent.spec.js
import { MyComponent } from '...'

// OtherComponents.js
import MyComponent from '...'

साथ ही, इस चर्चा को जोड़ते हुए, हमने एक ही मुद्दे का सामना किया और इस https://www.npmjs.com/package/react-context-consumer-hoc को बनाया जो कई संदर्भों का उपभोग करता है।

सब कुछ उम्मीद के मुताबिक काम कर रहा है। लेकिन अब, मैं घटकों के लिए इकाई परीक्षण मामलों को लिखना चाहता हूं, लेकिन मैं ऐसा करने में असमर्थ हूं।

@AnnArora आप एक यूनिट टेस्ट लिखने में असमर्थ क्यों हैं? आपने क्या प्रयास किया है? आप क्या त्रुटि देख रहे हैं?

@pgarciacamou सबसे पहले त्वरित उत्तर के लिए धन्यवाद। खैर, वेब पर कुछ भी नहीं खोजने के बाद और यहां क्वेरी पोस्ट करें। मैं उसी समाधान के साथ आया था जिसका आपने उल्लेख किया था।

टेस्ट के मामले अभी काम कर रहे हैं लेकिन ऐसा लगता है कि यह एक काम है। मैं https://www.npmjs.com/package/react-context-consumer-hoc पर एक नज़र

धन्यवाद। : 100:

@bvaughn बात पहले की है जब मैं राज्य प्रबंधन के लिए

लेकिन संदर्भ एपीआई का उपयोग करते समय इनमें से कोई भी तरीका उपलब्ध नहीं था।

और जब मैं इनमें से किसी भी तरीके का उपयोग नहीं कर रहा था तो मुझे निम्नलिखित त्रुटि मिल रही थी: _unknown नोड टैग 12_ के साथ

पकड़ लिया।

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

मुझे redux और unistore (बहुत सारे कोड प्रदूषण / अतिरिक्त मूविंग पार्ट्स imo) के लिए बड़े पैमाने पर अरुचि हुई, जिसने मुझे निम्नलिखित सेटअप तक पहुँचाया, जो हमारे नेस्टेड घटकों को एक एकल वैश्विक स्थिति तक पहुंचने की अनुमति देता है। बाकी सब कुछ जो वैश्विक स्थिति में नहीं होना चाहिए (यानी पाठ इनपुट मान, टॉगल मान) प्रत्येक नेस्टेड घटकों की स्थानीय स्थिति में संग्रहीत किए जाते हैं।

https://github.com/davalapar/session-context

नमस्ते,

क्या यह समस्या हल हो गई है?

मेरे पास एक परिदृश्य है जहां मेरे 3 घटक थे। निर्माता, प्रदर्शन, सेल।
सेल में मेरा रेंडर लॉजिक है जो क्रिएटर और डिस्प्ले दोनों में उपयोग किया जाता है।

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

वहाँ एक कर दिया गया है कि कैसे उपयोग करने के लिए दिखा ऊपर टिप्पणी की जोड़ी Context.Consumer में मानों componentDidMount । क्या आपने उन्हें आजमाया? क्या उन्होंने किसी कारण से काम नहीं किया?

ध्यान दें कि प्रतिक्रिया 16.6 ने कक्षाओं के लिए एक नया contextType API जोड़ा है जो componentDidMount आसान में नया संदर्भ बनाता है।

https://reactjs.org/docs/context.html#classcontexttype

हाँ, बशर्ते आपको अपने घटक में एक ही संदर्भ का उपयोग करने की आवश्यकता है - contextType एक सुविधाजनक विकल्प है।

ध्यान दें कि प्रतिक्रिया 16.6 ने कक्षाओं के लिए एक नया contextType API जोड़ा है जो componentDidMount आसान में नया संदर्भ बनाता है।

ऐसा नहीं होता। यहां तक ​​कि अगर एक भी संदर्भ प्रकार पर्याप्त है, तो Class.contextType वंशानुक्रम को तोड़ता है। एचओसी के बारे में भी यही सच है।

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

contextType API निश्चित रूप से _does_ componentDidMount (जो इस धागे के बारे में है) में संदर्भ मूल्यों तक पहुंचना आसान बनाता है।

हम अपने डॉक्स में वंशानुक्रम पर रचना की सिफारिश करने के बारे में बहुत स्पष्ट हैं ...

यह बहुत व्यापक है ...

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

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

... जो इस धागे के बारे में है ...

हां, यह टिप्पणी थोड़ा हटकर है।

संदर्भ बदलना

ध्यान दें कि प्रतिक्रिया 16.6 ने कक्षाओं के लिए एक नया संदर्भ टाइप एपीआई जोड़ा है जो घटकडिमाउंट में नए संदर्भ को पढ़ना आसान बनाता है।

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

क्या MyCoolComponent.contextType उन्हें असाइन करने से पहले संदर्भों की रचना करने का कोई तरीका नहीं है?

मेरा पढ़ा है कि अब के लिए, अगर हम एक घटक है कि कर सकते हैं:

क) कई संदर्भों का उपभोग करें
ख) उन संदर्भों की चीजों का उपयोग render अलावा अन्य तरीकों से करें

इसका मतलब यह है कि हम वर्णित पैटर्न के साथ फंस गए हैं जहां आवरण संदर्भ का उपभोग करता है और बच्चे को सहारा देता है।

मुझे लगता है कि एक आदर्श स्थिति यह होगी कि मैं ऐसा कुछ लिख सकता हूं, और दोनों दुनिया के सर्वश्रेष्ठ (यानी पूरे वर्ग में उपलब्ध कई संदर्भ) प्राप्त कर सकता हूं:

MyCoolComponent.contextType =  composeContexts(OneContext, TwoContext, RedContext, BlueContext)

क्या इसे करने का कोई तरीका है?

यह रेंडर विधि के लिए काम करता है, लेकिन किसी अन्य विधि के लिए काम नहीं कर रहा है .... कोई विचार ??

सुनो।
क्या किसी वर्ग घटक के निर्माता में नए संदर्भ एपीआई का उपयोग करने की कोई संभावना है?

हम अपनी परियोजनाओं को v15.x से v16.x पर माइग्रेट कर रहे हैं, कार्यों में से एक नए संदर्भ एप का उपयोग करना है
हमारी परियोजना में, हम सीएसएस-मॉड्यूल + आइसोमोर्फिक-स्टाइल-लोडर का उपयोग करते हैं, बाद वाले घटक में स्टाइलशीट को डोम में इंजेक्ट करने के लिए कुछ एपीआई को उजागर करते हैं।

V15 में, हम उन एपीआई को पुराने संदर्भ एपीआई में डालते हैं, और प्रत्येक घटक को कुछ इस तरह से प्राप्त करने देते हैं

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

V15 में, हम इसे कंपोनेंटमाउंट में डाल सकते हैं। यह सुनिश्चित करेगा कि घटक को प्रस्तुत करने से पहले सही शैली मिल जाए।

V16 में, हालांकि, कंपोनेंटमाउंट को असुरक्षित के रूप में चिह्नित किया गया है और भविष्य में इसे हटा दिया जाएगा।
इसलिए हमारा तात्कालिक विचार यह होगा कि हम अपने संदर्भ.संग्रह को घटक के निर्माण में कहें।

हालाँकि, दस्तावेज़ से देखा गया,

यदि संदर्भ घटक एक घटक के भीतर परिभाषित किया गया है, तो निम्न जीवनचक्र विधियों को एक अतिरिक्त पैरामीटर प्राप्त होगा, संदर्भ वस्तु:

निर्माता (सहारा, संदर्भ)

इस उपयोग (एक 2 पैरामीटर के रूप में संदर्भ के साथ) को भी हटा दिया जाएगा।

मैंने MyComp.contextType = StyleContext को असाइन करते हुए नए संदर्भ एपी की कोशिश की
फिर भी मुझे लगता है कि मुझे यह मिल जाता है। कंस्ट्रक्टर में अपरंपरागत अपरिभाषित है।

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

क्या कंस्ट्रक्टर में संदर्भ का उपयोग करने के बारे में कोई व्यावहारिक गाइड है?

कोई सलाह?

सुनो।
क्या किसी वर्ग घटक के निर्माता में नए संदर्भ एपीआई का उपयोग करने की कोई संभावना है?

हम अपनी परियोजनाओं को v15.x से v16.x पर माइग्रेट कर रहे हैं, कार्यों में से एक नए संदर्भ एप का उपयोग करना है
हमारी परियोजना में, हम सीएसएस-मॉड्यूल + आइसोमोर्फिक-स्टाइल-लोडर का उपयोग करते हैं, बाद वाले घटक में स्टाइलशीट को डोम में इंजेक्ट करने के लिए कुछ एपीआई को उजागर करते हैं।

V15 में, हम उन एपीआई को पुराने संदर्भ एपीआई में डालते हैं, और प्रत्येक घटक को कुछ इस तरह से प्राप्त करने देते हैं

    class MyComp extends Component {
        static contextTypes = {
                insertCss: PropTypes.func
           }
         ....
         componentWillMount () {
                // insert a style tag for this component
               this.removeCss = this.context.insertCss(myStyles)
         }
    }

V15 में, हम इसे कंपोनेंटमाउंट में डाल सकते हैं। यह सुनिश्चित करेगा कि घटक को प्रस्तुत करने से पहले सही शैली मिल जाए।

V16 में, हालांकि, कंपोनेंटमाउंट को असुरक्षित के रूप में चिह्नित किया गया है और भविष्य में इसे हटा दिया जाएगा।
इसलिए हमारा तात्कालिक विचार यह होगा कि हम अपने संदर्भ.संग्रह को घटक के निर्माण में कहें।

हालाँकि, दस्तावेज़ से देखा गया,

यदि संदर्भ घटक एक घटक के भीतर परिभाषित किया गया है, तो निम्न जीवनचक्र विधियों को एक अतिरिक्त पैरामीटर प्राप्त होगा, संदर्भ वस्तु:

निर्माता (सहारा, संदर्भ)

इस उपयोग (एक 2 पैरामीटर के रूप में संदर्भ के साथ) को भी हटा दिया जाएगा।

मैंने MyComp.contextType = StyleContext को असाइन करते हुए नए संदर्भ एपी की कोशिश की
फिर भी मुझे लगता है कि मुझे यह मिल जाता है। कंस्ट्रक्टर में अपरंपरागत अपरिभाषित है।

    class MyComp extends Component {
        static contextType = StyleContext

         constructor (props) {
             super(props)
             console.log(this.context) // undefined
         }

    }

क्या कंस्ट्रक्टर में संदर्भ का उपयोग करने के बारे में कोई व्यावहारिक गाइड है?

कोई सलाह?

आप संदर्भप्रकार का उपयोग करने के बजाय ऐसा कर सकते हैं

class MyComponent extends React.Component {
   render(){
       const {
         //props including context props
       } = this.props;
       return(<View />);
   }
};

const withContext = () => (
  <MyContext.Consumer>
    { (contextProps) => (<MyComponent {...contextProps}/>)}
  </MyContext.Consumer>
);

export default withContext;

मेरे जैसा कोई भी अपने रेंडर फ़ंक्शन के बाहर इसका उपयोग करने के लिए संघर्ष कर रहा है, बस अपने उप-घटक में निम्नलिखित का उपयोग करें:

useContext ()

उदाहरण के लिए:

const context = useContext(yourContext)

MainComponent.Subcomponent = () => {
 const context = useContext(context)

  useEffect(()=> {
    console.log(context)
  })
}