React: هل هناك طريقة للوصول إلى واجهة برمجة تطبيقات جديدة للسياق داخل ComponentDidMount؟

إضافة مثال أحاول تشغيله: https://codesandbox.io/s/l20yn296w7

تحرير: اتباع الإرشادات من 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 هي إعادة التوجيه إلى Props؟

تحرير: تم التغيير إلى componentDidMount

يعد مكون الترتيب الأعلى الذي يتم إعادة توجيهه إلى الدعائم نمطًا جيدًا ، ولكن بالنسبة للحالات التي لا تريد فيها المكون الإضافي عادةً ما أقوم بتخزين قيمة السياق في مثيل المكون مثل: this.contextValue = value ثم الوصول إليه في خطافات دورة الحياة. إنه أمر قبيح بعض الشيء ولكن هذا جيد بشكل عام أعتقد أنه منذ إلغاء الاشتراك في النمط الأجمل والمخصص كأداة تحسين

أواجه نفس المعضلة.
يجب أن تكون هناك طريقة سهلة للوصول أو استدعاء السياق في طرق دورة الحياة.
قد نحتاج إلى تهيئة العناصر وفحص البيانات وجلبها أو حتى التنظيف عند إلغاء التحميل.
يفعل الناس ذلك الآن مع السياق الحالي المفترض أنه معطل.
نعم يمكن حلها بلف مكوننا في مكون آخر! لكن يبدو وكأنه حل بديل أكثر من حل.

قم بتخزين قيمة السياق على مثيل المكون مثل: this.contextValue = value ثم الوصول إليها في خطافات دورة الحياة

أنا متأكد من أن هذا غير آمن في الوضع غير المتزامن. من فضلك لا تفعل هذا. ccacdlite

نعم يمكن حلها بلف مكوننا في مكون آخر! لكن يبدو وكأنه حل بديل أكثر من حل.

أنا أتفق مع ذلك. سيكون من الجيد الوصول أصلاً من خلال componentDidMount و componentWillUnmount لتتمكن من تهيئة / تنظيف الأشياء ،

بشكل عام ، فإن استخدام متغيرات المثيل ليكون ذكيًا ويخدع تدفق البيانات العادي سيؤدي إلى حدوث مشكلات في عدم التزامن. فقط لا تفعل. إنه أمر محير بعض الشيء اليوم ، لأن متغيرات الأمثلة هي الطريقة الوحيدة للقيام بأشياء معينة ، مثل أجهزة ضبط الوقت. قبل أن نصدر غير متزامن ، سننشر توصيات أكثر وضوحًا - وفي يوم من الأيام سيكون لدينا مكون جديد لواجهة برمجة تطبيقات لا تعتمد كثيرًا على المثيلات.

TL ؛ د: استخدام المراوغة الدعائم. ولا تقلق كثيرًا بشأن المكون الإضافي.

أنا متأكد من أن هذا غير آمن في الوضع غير المتزامن. من فضلك لا تفعل هذا.

كيف سيكون هذا غير آمن (وبأي طريقة)؟ إنه أمر غير واضح في كل هذا الحديث عن الوضع غير المتزامن ، ماذا تعني كلمة "غير آمن". لقد بدأ يشعر وكأنه رجل مخادع يتسم بسلوك غير منطقي ولا يمكن التنبؤ به ، والذي لا يملأ الناس بالكثير من التأكيد في نظام محبوب بشكل عام لأنه نموذج تدفق بيانات مباشر وسهل الفهم. أشعر أن المكونات عادت إلى ما قبل 0.13 أرض حيث أصبحت كائنات سحرية مرة أخرى.

من السهل أيضًا أن تقول "أضف مكونًا آخر فقط" ، ولكن هذا غالبًا ما يكون مرهقًا ، ويقدم فئة خاصة به من الأخطاء والتحديات. لم أبدأ بالشعور بأن على الناس ابتكار أفكار مجردة عبر واجهة برمجة تطبيقات تفاعلية لكي يكونوا "آمنين".

آسف ^ إذا كانت الأصوات أعلاه مزعجة / غاضبة ، لم أكن أنوي هذه النغمة! على phhhhooone

لقد بدا الأمر غاضبًا ، لكنني فهمت وجهة نظرك وأشارك أسئلتك حول كيف / لماذا سيكون غير آمن

لقد بدأ يشعر وكأنه رجل بعبع يتصرف بطريقة غير عقلانية ولا يمكن التنبؤ بها

أنا آسف ، لكننا نعمل على إرشادات مع اقتراحات محددة لأكثر من شهر الآن. يرجى منحنا الوقت لجمعها ونشرها كمدونة. من الصعب أيضًا مناقشتها بدون استخدام ألفا الفعلي ، وهو أيضًا شيء نعمل بجد عليه.

لذلك علينا إما عدم قول أي شيء على الإطلاق ، أو التحذير مقدمًا من الأشياء التي لن تعمل بشكل جيد. نحن نخطئ في جانب التحذير ولكن يمكنني أن أرى كيف يمكن أن يبدو أننا نجعل الأمر أكثر صعوبة بالنسبة لك. أنا متأكد من أنه بمجرد إخراج الكود ويمكنك اللعب به ، سترى ما نعنيه ، وسيصبح أكثر منطقية.

كيف سيكون هذا غير آمن (وبأي طريقة)؟

هل حصلت على فرصة لمشاهدة حديثي ؟ سيكون من الصعب بعض الشيء شرح ذلك إذا لم ترَ الجزء الثاني منه ، لأنه لن يكون من الواضح سبب قيامنا بذلك. لذا أطلب منك مشاهدته. آمل أن يقنعك حديثي بأننا نهدف إلى حل فئة واسعة من المشكلات التي ابتليت بها React منذ البداية ، وأن هذه الميزات تستحق إعادة النظر في بعض الافتراضات التي ربما اعتدنا عليها.

بافتراض أنك شاهدت الحديث ، فإليك شرحًا أكثر تحديدًا لهذه الحالة بالذات. لكي تكون قادرًا على "تعليق" العرض كما عرضت في العرض التوضيحي ، يجب أن يكون React قادرًا على الاتصال بـ render() في أي وقت من الأوقات ، مع احتمال أن يكون ذلك باستخدام دعامات مختلفة. على سبيل المثال ، إذا كان من الممكن تعيين this.props و this.state للدعائم من شاشة جديدة (يتم تحميلها) ، فاتصل بـ render ، ولكن قم بتعيينها على this.props و this.state عند العرض استجابة لتفاعل على الإصدار الحالي من الشجرة (على سبيل المثال ، إذا ضغطت على شيء ما أثناء تحميل الشاشة الجديدة).

في حالة عدم التزامن ، القاعدة الأساسية هي: تنفيذ دورات الحياة فقط مثل componentDidMount و componentDidUpdate و componentWillUnmount و ref في نقاط محددة جيدًا في الوقت مع الدعائم والحالة التي تتوافق لما يظهر على الشاشة. لحسن الحظ ، ليس لدينا سوى عدد قليل من دورات الحياة الأخرى التي لا تتناسب تمامًا مع هذه الصورة ، ونقدم لهم بدائل أفضل ( getDerivedPropsFromState ، getSnapshotBeforeUpdate ). ستكون هذه هجرة تدريجية. مرة أخرى ، سيكون كل شيء في منشور المدونة.

الآن إلى جذر هذه القضية. في الوضع غير المتزامن ، لا تقدم React ضمانات حول متى وبأي ترتيب تستدعي طريقة render . وهو حقًا شيء لم تضمنه React أبدًا في المقام الأول - تصادف أن تكون بنفس الترتيب في كل مرة. لا يعد تخزين حقل في render ثم قراءته في دورة حياة "آمنًا" لأنك قد تخزن حقلاً في الوقت الذي يُدعى React 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 .

نعم يمكن حلها بلف مكوننا في مكون آخر! لكن يبدو وكأنه حل بديل أكثر من حل.

أردت فقط أن نثني على ما قاله دان بأن نهج التابع / عرض الخاصية التابع هو واجهة برمجة التطبيقات الرسمية للسياق الجديد - لذا يرجى استخدامه ودع React تقلق بشأن التأكد من أنها سريعة. (سيكون ذلك!)

كيف سيكون هذا غير آمن (وبأي طريقة)؟

تتطرق مسودة مستندات الوضع الصارم أيضًا إلى بعض أسباب خطورة تغيير المثيل (وهو مجرد نوع آخر من الآثار الجانبية) في الوضع غير المتزامن.

لدينا فرع تجريبي باتباع الإرشادات المقترحة هنا. هل يمكن لأي شخص إلقاء نظرة لمعرفة ما إذا كان ذلك منطقيًا؟ https://github.com/commodityvectors/react-mapbox-gl/pull/11

لست على دراية بهذه المكتبة ، لذلك لا أعرف ما إذا كان الأشخاص قد استخدموا المراجع بمكوناتها - ولكن إذا فعلوا ذلك ، فقد يكون مزيج withContext في تلك العلاقات العامة حالة استخدام جيدة لـ واجهة برمجة تطبيقات جديدة forwardRef .

هذا معقول. شكرا للإشارة. سأغلق هذه القضية الآن.

واجهت هذه المشكلة لأنني كنت أحاول معرفة ما إذا كان بإمكاني تحقيق نفس الشيء.

لذلك ، مما يمكنني جمعه من كل هذا ، فإنه ليس من الممكن في المكون الذي يستخدم 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; }
}

أتساءل عما إذا كان هذا سيسبب أي صداع أسفل الخط. لا يزال يبدو وكأنه React قياسي جدًا ، إذا كان نوعًا من الاختراق.

هناك بعض الاختلافات الدقيقة التي قد تجعل هذا النهج فكرة سيئة. على سبيل المثال ، إذا كان MapElement مكون فئة يستخدم المراجع ، فلن يتم تعيين المراجع بعد عند تشغيل رد الاتصال runOnMount .

😄 أود أن أقترح استخدام نهج 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 عبارة عن مكون فئة يستخدم المراجع ، فلن يتم تعيين المراجع بعد عند تشغيل رد نداء runOnMount.

شكرا لملاحظاتك @ bvaughn . في الوقت الحالي ، أستخدمه تمامًا كنوع من مكون وكيل الحالة الذي يضيف / يزيل الأشياء من واجهة المستخدم اعتمادًا على ما يتم تثبيته داخل شجرة السياق. نوع من البوابات المماثلة ولكن داخل شجرة مكونات React. لذلك ليس في الواقع تقديم الأطفال أو التعامل مع الحكام على الإطلاق.

سوف أضع في الاعتبار إذا كنت بحاجة إلى فعل أي شيء يتفاعل مع الحكام.

مرحبا جميعا،

أحتاج إلى بيانات السياق في طرق دورة الحياة. لذلك ، اتبعت نهج HOC بعد رؤية التعليقات القليلة الأولى ومرر بيانات السياق كدعامات.
كل شيء يعمل كما هو متوقع. ولكن الآن ، أريد أن أكتب حالات اختبار الوحدة للمكونات ولكن لا يمكنني القيام بذلك.

سأكون ممتنًا حقًا إذا كان بمقدور شخص ما مشاركة كيفية كتابة حالات الاختبار لهذا السيناريو.

أنا أستخدم إنزيم ، محول إنزيم ، رد فعل -16 ومازح ولكن لدي بعض المشاكل في القيام بذلك.

تضمين التغريدة

في الشركة التي أعمل بها ، نقوم بما يلي (ملاحظة ، قد لا يكون هذا هو الإجماع) ، كما نقوم بتصدير المكون "العاري" أيضًا ثم نستورده في اختباراتنا ونمرر الدعائم يدويًا.

على سبيل المثال

// 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 الذي يستهلك سياقًا متعددًا.

كل شيء يعمل كما هو متوقع. ولكن الآن ، أريد أن أكتب حالات اختبار الوحدة للمكونات ولكن لا يمكنني القيام بذلك.

AmnArora لماذا لا تستطيع كتابة اختبار الوحدة؟ ماذا حاولت؟ ما الخطأ الذي تراه؟

pgarciacamou أولا شكرا على الرد السريع. حسنًا ، بعد عدم العثور على أي شيء على الويب ونشر الاستعلام هنا. لقد توصلت إلى نفس الحل الذي ذكرته.

تعمل حالات الاختبار الآن ولكن هذا يبدو وكأنه حل بديل. سألقي نظرة على https://www.npmjs.com/package/react-context-consumer-hoc وأناقش مع فريقي.

شكر. : 100:

bvaughn كان الشيء سابقًا عندما كنت أستخدم redux لإدارة الحالة ، قمت بنسخ المكون واستخدمت أساليب dive ()

ولكن لم تكن أي من هذه الطرق متاحة عند استخدام سياق API.

وعندما لم أستخدم أيًا من هذه الطرق ، تلقيت الخطأ التالي: _عقدة غير معروفة بالعلامة 12_

مسكتك.

يبدو أن كلا من هذه المشكلات في إصدار Enzyme الذي تستخدمه لا يدعم بشكل صحيح واجهة برمجة تطبيقات السياق الجديدة. هذا مؤسف.

لقد شعرت بنفور شديد مقابل redux و unistore (الكثير من تلوث الكود / الأجزاء المتحركة الإضافية imo) مما قادني إلى الإعداد التالي الذي يسمح لمكوناتنا المتداخلة بالوصول إلى حالة عالمية واحدة. كل شيء آخر لا ينبغي أن يكون في الحالة العامة (مثل قيم إدخال النص ، قيم التبديل) يتم تخزينه داخل الحالة المحلية لكل مكون متداخل.

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

مرحبا،

هل حلت هذه المشكلة؟

لدي سيناريو حيث كان لدي 3 مكونات. الخالق ، العرض ، الخلايا.
الخلية لديها منطق التجسيد الخاص بي والذي يتم استخدامه في كل من المنشئ والعرض.

أحتاج حاليًا إلى تمرير الحالة إذا كان يتم إنشاء العنصر أو يجب عرضه. لقد استخدمت الخلايا في مواقع مختلفة ، لذا أحتاج إلى تمرير الحالة كدعامات بشكل منفصل. لذلك أردت استخدام سياق للحالة ولكن المشكلة هي أنني أردت تعديل السياق فقط إذا تم تركيب مكون العرض. هل يمكننا تحقيق أن هذه هي إصدارات React الحالية؟ (أنا أستخدم React 16.7)

كان هناك زوجان من التعليقات أعلاه توضح كيفية الوصول إلى قيم Context.Consumer في componentDidMount . هل جربتهم؟ ألم يعملوا لسبب ما؟

لاحظ أن React 16.6 أضاف واجهة برمجة تطبيقات جديدة contextType للفئات مما يجعل قراءة السياق الجديد في componentDidMount أمرًا سهلاً.

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

نعم ، بشرط أنك تحتاج فقط إلى استخدام سياق واحد في المكون الخاص بك - contextType هو خيار مناسب.

لاحظ أن React 16.6 أضاف واجهة برمجة تطبيقات جديدة contextType للفئات مما يجعل قراءة السياق الجديد في componentDidMount أمرًا سهلاً.

لم يحدث ذلك. حتى إذا كان نوع سياق واحد كافياً ، فإن Class.contextType يقطع التوريث. نفس الشيء ينطبق على HOC.

نحن صريحون جدًا في مستنداتنا حول التوصية بالتركيب على الميراث لإعادة استخدام الكود بين المكونات. أبعد من ذلك ، أنا لا أفهم حقًا ما تقوله.

تجعل واجهة contextType API بالتأكيد من السهل الوصول إلى قيم السياق في componentDidMount (وهو ما يدور حوله هذا الموضوع).

نحن صريحون جدًا في مستنداتنا بشأن التوصية بالتركيب على الميراث ...

هذا واسع جدًا ...

الحالة التي أواجهها الآن ، هي أن لدي مجموعة من المكونات مع مجموعة من الوظائف المشتركة اللازمة لدعم تنفيذها. تم تصميم كل شيء من خلال الميراث بشكل مثالي ، باستثناء ... بتات السياق!

بالنظر إلى أنه يبدو أنني العبث بالسياق فقط في مثل هذه المواقف ، فإن واجهة برمجة تطبيقات السياق محبطة للغاية.

... وهو ما يدور حوله هذا الموضوع ...

نعم ، هذا التعليق خارج الموضوع قليلاً.

يؤدي تغيير السياق النوع باستخدام فئة السياق إلى كسر متجر redux: /

لاحظ أن React 16.6 أضاف واجهة برمجة تطبيقات ContextType جديدة للفئات مما يجعل قراءة سياق جديد في componentDidMount أمرًا سهلاً.

نعم ، بشرط أن تحتاج فقط إلى استخدام سياق واحد في المكوِّن الخاص بك - يعد ContextType خيارًا مناسبًا.

ألا توجد طريقة لتكوين سياقات قبل تعيينها إلى MyCoolComponent.contextType ؟

قراءتي هي أنه في الوقت الحالي ، إذا أردنا مكونًا يمكنه:

أ) تستهلك سياقات متعددة
ب) استخدم أشياء من تلك السياقات بطرق أخرى غير render

هذا يعني أننا عالقون مع النمط الموصوف حيث يستهلك الغلاف السياق ويمرر الدعائم إلى الطفل.

أشعر أن الوضع المثالي هو أنه يمكنني كتابة شيء كهذا ، والحصول على أفضل ما في العالمين (أي سياقات متعددة متاحة في جميع أنحاء الفصل بأكمله):

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

هل هناك أي طريقة للقيام بذلك؟

يعمل على طريقة التصيير ولكن لا يعمل لأي طريقة أخرى .... أي فكرة ؟؟

مرحبا.
هل هناك أي إمكانية لاستخدام واجهة برمجة تطبيقات السياق الجديدة في منشئ مكون الفئة؟

نقوم بترحيل مشاريعنا من الإصدار v15.x إلى الإصدار 16.x ، وإحدى المهام هي استخدام واجهة برمجة تطبيقات السياق الجديدة
في مشروعنا ، نستخدم css-modules + isomorphic-style-loader ، حيث يعرض الأخير بعض واجهات برمجة التطبيقات (API) لحقن أوراق أنماط المكونات في DOM.

في 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 ، يمكننا وضع هذا في componentWillMount. سيضمن هذا حصول المكون على النمط الصحيح قبل التصيير.

ومع ذلك ، في الإصدار 16 ، تم وضع علامة على componentWillMount على أنه غير آمن وسيتم إهماله في المستقبل.
لذا فإن أفكارنا المباشرة هي وضع استدعاء Context.insertCss الخاص بنا في مُنشئ المكون.

ومع ذلك ، من المستند ،

إذا تم تعريف ContextTypes داخل أحد المكونات ، فستتلقى أساليب دورة الحياة التالية معلمة إضافية ، كائن السياق:

مُنشئ (دعائم ، سياق)

هذا الاستخدام (مع السياق كمعامل ثاني) سيتم إهماله أيضًا.

لقد جربت واجهة برمجة تطبيقات السياق الجديدة ، مع تعيين MyComp.contextType = StyleContext
ومع ذلك ، أجد أنني أحصل على this.context غير معرف في المنشئ.

    class MyComp extends Component {
        static contextType = StyleContext

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

    }

هل هناك أي دليل عملي حول كيفية استخدام السياق في المُنشئ؟

اي نصيحه؟

مرحبا.
هل هناك أي إمكانية لاستخدام واجهة برمجة تطبيقات السياق الجديدة في منشئ مكون الفئة؟

نقوم بترحيل مشاريعنا من الإصدار v15.x إلى الإصدار 16.x ، وإحدى المهام هي استخدام واجهة برمجة تطبيقات السياق الجديدة
في مشروعنا ، نستخدم css-modules + isomorphic-style-loader ، حيث يعرض الأخير بعض واجهات برمجة التطبيقات (API) لحقن أوراق أنماط المكونات في DOM.

في 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 ، يمكننا وضع هذا في componentWillMount. سيضمن هذا حصول المكون على النمط الصحيح قبل التصيير.

ومع ذلك ، في الإصدار 16 ، تم وضع علامة على componentWillMount على أنه غير آمن وسيتم إهماله في المستقبل.
لذا فإن أفكارنا المباشرة هي وضع استدعاء Context.insertCss الخاص بنا في مُنشئ المكون.

ومع ذلك ، من المستند ،

إذا تم تعريف ContextTypes داخل أحد المكونات ، فستتلقى أساليب دورة الحياة التالية معلمة إضافية ، كائن السياق:

مُنشئ (دعائم ، سياق)

هذا الاستخدام (مع السياق كمعامل ثاني) سيتم إهماله أيضًا.

لقد جربت واجهة برمجة تطبيقات السياق الجديدة ، مع تعيين MyComp.contextType = StyleContext
ومع ذلك ، أجد أنني أحصل على this.context غير معرف في المنشئ.

    class MyComp extends Component {
        static contextType = StyleContext

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

    }

هل هناك أي دليل عملي حول كيفية استخدام السياق في المُنشئ؟

اي نصيحه؟

يمكنك القيام بذلك بدلاً من استخدام ContextType

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)
  })
}