React: Devtools V4: أين توجد تحديثات مميزة؟

تم إنشاؤها على ١٧ أغسطس ٢٠١٩  ·  31تعليقات  ·  مصدر: facebook/react

إذا فهمت بشكل صحيح ، فهذا هو المستودع الصحيح لـ devtools v4 ، أليس كذلك؟

لقد لاحظت للتو أنه تم تحديث أداة devtool التفاعلية. أفتقد وظيفة "تمييز التحديثات".
كيف يمكنني تفعيله؟

image

image

الإصدار: 4.0.2 (8/15/2019)

Developer Tools Discussion Feature Request

التعليق الأكثر فائدة

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

أتفهم مخاوفgaearon بشأن إعطاء فكرة خاطئة ،

1. اختر لون المخطط التفصيلي بناءً على مدة العرض

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

2. تختلف سرعة تتلاشى المخطط التفصيلي

يجب أن تكون الرسوم المتحركة للخبو المخطط التفصيلي مرتبطة بمدة العرض. يجب أن يتلاشى العرض السريع على الفور ، ويجب أن يتلاشى العرض البطيء بشكل أبطأ.

3. التفريق بين المناطق المعاد طلاؤها

كنت أستخدم أحيانًا Highlight Updates مع متصفح Chrome Paint Flashing . أدى هذا إلى إبراز الصور التي أدت إلى إعادة الرسم بشكل مختلف عن العروض التي ليس لها تأثير DOM. أعتقد أن DevTools يجب أن يكون مدمجًا بوظيفة مماثلة.

  • يجب أن يكون العرض المكلف بدون إعادة طلاء هو الهدف الأساسي لتحسين الأداء.
  • من الواضح أن إعادة الرسم تقوم ببعض الأعمال التي يجب القيام بها.
  • لا بأس من تجاهل عمليات العرض السريعة التي لا ينتج عنها إعادة رسم.

ربما يكون لديك إعداد يومض فقط أول ما سبق (مع بعض العتبة القابلة للتكوين).

ال 31 كومينتر

نفس المشكلة هنا. اختفى تمييز التحديثات.
كنت أتساءل عما إذا كان على المرء استخدام منشئ ملفات التعريف الآن ، لتتبع التحديثات؟

https://www.reddit.com/r/reactjs/comments/cqx554/introducing_the_new_react_devtools/ex1r9nb/

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

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

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

تم التعديل لإضافة تعليق مضمّن

بعض المناقشات السابقة ذات الصلة https://github.com/bvaughn/react-devtools-experimental/issues/244

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

أتفهم مخاوفgaearon بشأن إعطاء فكرة خاطئة ،

1. اختر لون المخطط التفصيلي بناءً على مدة العرض

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

2. تختلف سرعة تتلاشى المخطط التفصيلي

يجب أن تكون الرسوم المتحركة للخبو المخطط التفصيلي مرتبطة بمدة العرض. يجب أن يتلاشى العرض السريع على الفور ، ويجب أن يتلاشى العرض البطيء بشكل أبطأ.

3. التفريق بين المناطق المعاد طلاؤها

كنت أستخدم أحيانًا Highlight Updates مع متصفح Chrome Paint Flashing . أدى هذا إلى إبراز الصور التي أدت إلى إعادة الرسم بشكل مختلف عن العروض التي ليس لها تأثير DOM. أعتقد أن DevTools يجب أن يكون مدمجًا بوظيفة مماثلة.

  • يجب أن يكون العرض المكلف بدون إعادة طلاء هو الهدف الأساسي لتحسين الأداء.
  • من الواضح أن إعادة الرسم تقوم ببعض الأعمال التي يجب القيام بها.
  • لا بأس من تجاهل عمليات العرض السريعة التي لا ينتج عنها إعادة رسم.

ربما يكون لديك إعداد يومض فقط أول ما سبق (مع بعض العتبة القابلة للتكوين).

لا يعد تحديد عرض "رخيص" أو "سريع" أمرًا مباشرًا كما يبدو ، بسبب عوامل مثل:

  • تكون عمليات التطوير أبطأ بكثير من عمليات بناء الإنتاج.
  • تعد أجهزة الكمبيوتر المحمولة للمطورين أسرع بشكل عام من أجهزة الكمبيوتر المحمولة للمستخدم النهائي.

الشيء الجميل في منشئ ملفات التعريف هو أنه يُبلغ عن السرعة كنسبي ، مما يتيح لك التركيز على أبطأ جزء من التطبيق في أي جلسة معينة. (عليك أن تقرر متى يكون الجزء الأبطأ سريعًا بدرجة كافية.) لا يمكن القيام بذلك إلا في وقت لاحق.

يمنحك أيضًا لقطة ثابتة للالتزامات ، وأي من الدعائم / الحالة تغيرت ، مما يتيح لك رؤية ليس فقط عدد المرات التي تم فيها عرض مكون معين (هل كان أكثر مما كنت تتوقعه؟) ولكن أيضًا على وجه التحديد _لماذا _ تمت إعادة عرضه ، وماذا أيضًا معاد تقديمه.

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

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

لا أرى طريقة للتحقق من ذلك مع المحلل الجديد

ماذا حاولت؟ يجب أن يُظهر المحلل بوضوح ما إذا كان أحد الأطفال يعيد العرض أم كثير.

كنت أستخدم "Highlight updates" بشكل متكرر. كانت ميزة أدوات التطوير التي استخدمتها أكثر من غيرها. فقط لمعرفة ما تم تحديثه ، وليس عدد المرات. بالتأكيد ، يمكنك استخدام أداة التعريف للقيام بذلك ولكن هذا أكثر تعقيدًا بكثير من وجود مؤشر مرئي سريع.

بالنسبة لي ، كانت "تسليط الضوء على التحديثات" هي "الميزة القاتلة" ...

نسمعك :-) لا أعتقد أن التعليقات الإضافية التي تقول "لقد استخدمت هذا" ستساعد بشكل كبير في هذا الموضوع ، لما يستحق. نعلم أن هناك أشخاصًا يستخدمون هذه الميزة ، ونفكر في الطريقة الصحيحة لإعادتها. شكرا لملاحظاتك!

كان هذا الخيار مكونًا أساسيًا لعملية عملي اليومية للإشارة إلى مشكلة العرض على الفور. لذلك سأكون سعيدًا حقًا ، إذا كان بإمكانك إعادة هذه الميزة الرائعة قريبًا.

+1 عند إعادة بعض إصدارات هذه الميزة التي تتيح عرضًا سريعًا عالي المستوى لعمليات إعادة العرض (حتى بالنسبة لعمليات إعادة العرض التي تكون جيدة تمامًا مثل عندما نقوم بتحديث السياق).

+1 على العودة

لذلك سأكون سعيدًا حقًا ، إذا كان بإمكانك إعادة هذه الميزة الرائعة قريبًا.

كما هو مطلوب أعلاه:

لا أعتقد أن التعليقات الإضافية التي تقول "لقد استخدمت هذا" ستساعد بشكل كبير

لإعادة صياغة هذا بشكل أكثر وضوحًا:

لقد سمعناك!

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

قبل التعليق ، يرجى التأكد من إضافة شيء لم يقال من قبل. إذا رأيت تعليقًا مشابهًا لما تريد كتابته ، فما عليك سوى إضافة 👍 رد فعل عليه بدلاً من ذلك.

شكرا لتفهمك.
نحن نقدر ملاحظاتك ولكن ما يكفي للمساعدة في ترتيب أولويات المهام.

أنك تضيف شيئًا لم يُقال من قبل.

أود أن أسأل ، هل هناك طريقة لتثبيت الإصدار السابق من الامتداد؟ في الواقع ، كسر التحديث التدفق الذي اعتدت عليه. لسوء الحظ ، لا يسمح لك سوق ملحقات Chrome بتثبيت الإصدار السابق مثل "npm". هل لديك ارتباط بامتداد مترجم؟ شكرا لك.
_ (حاولت تثبيت إصدار مستقل ، لكن هذا الرابط من v3 repo معطل ، الارتباط بامتداد Crome يؤدي إلى الإصدار الأحدث) _

تشتمل DevTools الجديدة على أداة تعريف من المفترض أن تساعدك في العثور على مشاكل الأداء الفعلية في التعليمات البرمجية الخاصة بك.

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

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

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

أود أن أسأل ، هل هناك طريقة لتثبيت الإصدار السابق من الامتداد؟

يتم تغطية إرشادات تثبيت https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get- النسخة القديمة من الخلف

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

تثبيت React Dev Tools V3 (تعليمات خطوة بخطوة) :
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

إذا جاز لي الصراخ قليلاً ، بينما على المستوى التقني قد يبدو الأمر مثل "أدوات التنميط المتعمق"> "ميزة تسليط الضوء السخيفة" ، فنحن جميعًا مجرد بشر ونجمع الكثير من المعلومات بسرعة من الإشارات المرئية البسيطة ، لذلك من بعض النواحي ، تعد ميزة الإبراز مشكلة كبيرة جدًا نظرًا لأنها سهلة الاستخدام. بالنسبة لي ، هذا هو سبب فتح أدوات React Dev Tools بنسبة 90٪ من الوقت.

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

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

كما قلنا أعلاه ، وأعتقد أن هناك فرصة جيدة يمكننا أن نضيف نوعا من التحديث وامض آلية إلى DevTools كجزء من التعريف.

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

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

بالنسبة لأولئك الذين يفتقدون الميزة ، قد تجد https://github.com/welldone-software/why-did-you-render أكثر

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

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

ما زلت أجد ميزة إعادة العرض مفيدة للتوضيحات حول كيفية عمل React.

بشكل افتراضي ، يقوم WhyDidYouRender بمقارنة قيمة عميقة ويبلغ فقط عندما لا تتغير الأشياء فعليًا بين عمليات إعادة العرض.

يبدو هذا بطيئًا للغاية بالنسبة للتطبيقات التي تعاني بالفعل من مشاكل في الأداء. من المؤكد أن أي نوع من المقارنة العميقة ليس شيئًا نرغب في القيام به دائمًا. في الوقت الذي تقوم فيه بتشغيله (للاشتراك في الأداء البطيء) ، فلماذا لا تبدأ فقط في ملف التعريف؟

هذا من شأنه أن يوجه تحسينات أكثر تفكيرًا (بالإضافة إلى أنه تمييز لا يوفره المحلل).

يوفر منشئ ملفات التعريف نسخة من هذا:
Video demonstrating profiler "why did this render?" feature

إذا رأيت مكونًا تمت إعادة تصييره ، ولكن لم يكن لديه أي عناصر / حالة / خطافات متغيرة ، فهذا ما تصفه على ما أعتقد.

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

bvaughn أحب "لماذا هذا العرض؟" الميزة (في هذه الأثناء بينما يتم إعادة التفكير في Highlight Updates ) ، ولكن بعد قراءة جميع الوثائق المتاحة وتصفح برنامج youtube التعليمي ، ما زلت غير متأكد من كيفية تفسيره في حالات قليلة:

ما تعنيه الشرطة السفلية ليس بديهيًا:

لماذا هذا العرض؟

  • تغيرت الدعائم: (__)

أنا أستخدم فقط الخطافات api ، لكني ما زلت غير متأكد من المعنى:

لماذا هذا العرض؟

  • تغير الخطاف

هل هناك أي فرصة لوجود جملة أو تفسيرين لهذه الحالات وربما حالات أخرى لم أواجهها بعد إلى جانب الحالة الواضحة حيث تسرد فعليًا props / state التي تغيرت؟

ما تعنيه الشرطة السفلية ليس بديهيًا:

يبدو أن شيئًا ما في تطبيقك يمر في دعامة باسم __ وهذه الخاصية تتغير بين الالتزامات 😄

أنا فقط أستخدم الخطافات api ، لكني ما زلت غير متأكد من المعنى

من فضلك انظر # 16477

أهلا

كنت أستخدم Highlight Updates كثيرًا. أقوم بتطوير تطبيق يتم تحديثه باستمرار وكان هذا المستقبل ضروريًا بالنسبة لي في عملي اليومي.

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

هل مازلت تقوم بتنفيذ هذا العودة ؟؟ إذا لم يكن الأمر كذلك ، فكيف يمكنني الرجوع إلى إصدار سابق من أدوات React Dev ، لأنني ببساطة لا يمكنني التطوير بدونها.

هل مازلت تقوم بتنفيذ هذا العودة ؟؟ إذا لم يكن الأمر كذلك ، فكيف يمكنني الرجوع إلى إصدار سابق من أدوات React Dev ، لأنني ببساطة لا يمكنني التطوير بدونها.

أجبت بالفعل من قبلoztune.

كيف يمكنني استعادة النسخة القديمة؟
https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the-old-version-back

أريد النسخة القديمة مرة أخرى من فضلك. هناك الكثير من الوظائف التي تم فقدها في الوظيفة الجديدة وهي غير مفيدة بشكل مستحيل

أريد النسخة القديمة مرة أخرى من فضلك. هناك الكثير من الوظائف التي تم فقدها في الوظيفة الجديدة وهي غير مفيدة بشكل مستحيل

إليك كيفية استعادة الإصدار القديم ، الذي كان يعمل معي:
https://gist.github.com/oztune/01be16a2f90283aad82422b37221d522

مرحبًا einarq في الواقع ، أود أن

يرجى إعادة الوظائف المفقودة إلى الإصدار الجديد.

في كلامي ، الإصدار الجديد يعني أن لديك: إعادة تصميم وتحسينات للأقدم والعقود الآجلة الجديدة المضافة. لم تتم إزالتها وإضافة وظائف جديدة مختلفة عن سابقتها.

أيضا لماذا لا أستطيع الآن تغيير قيم الدولة ؟؟

والدعائم Booleans ليست مربعات اختيار بعد الآن ؟؟ كان هذا رائعًا جدًا. وذهب مرة أخرى.

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

مزعج للغاية.

مرحبًا PMustard ،

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

أنا متأكد من أن الفريق الذي يعمل على أدوات التطوير (بشكل رئيسي Brian Vaughn على ما أعتقد؟) سيأخذ مخاوفك في الاعتبار إذا قمت بإنشاء بعض المشكلات المنفصلة لهم.

ولا تنس أن تظهر بعض التقدير أيضًا. نحصل على هذه الأدوات مجانًا :)
ردود الفعل البناءة فقط.

يعتبر،

اينار

إذا كنت بحاجة ماسة إلى هذه الميزة ، فيمكنك استخدام إصدار قديم كحل بديل: https://reactjs.org/blog/2019/08/15/new-react-devtools.html#how -do-i-get-the -النسخة القديمة. أنا أيضا أشجعك على محاولة استخدام منشئ ملفات التعريف. على الرغم من أنه يتطلب مجهودًا أكبر قليلاً للتشغيل ، إلا أنه يخبرك أي عمليات إعادة تصيير مهمة وأيها ليست كذلك. غالبًا ما يكون مجرد حساب أرقام العرض بمثابة إلهاء عن مشكلات الأداء الفعلية.

نحن نتفهم أن وجود طريقة سهلة لاكتشاف عمليات إعادة العرض غير المتوقعة يعد أمرًا ذا قيمة. لقد أوضحنا في https://github.com/facebook/react/issues/16437#issuecomment -523629000 أن هذا على رادارنا وأن المزيد من التعليقات التي تقول "أحتاج هذا" ليست مفيدة. نظرًا لأن هذا الموضوع استمر مع ذلك في جمع تعليقات "أنا بحاجة إلى هذا" ، فسوف أقفله لتقليل فيضان الإشعارات. يرجى أن تطمئن إلى أن صوتك مسموع.

لقد قمت بتطبيق هذه الميزة في DevTools الجديد (# 16989) مع التحذيرات التالية:

  • يتم تمكينه فقط في امتداد المتصفح (وحزمة react-devtools-inline NPM) في الوقت الحالي ، لذا فهو يدعم React DOM فقط.
  • لم يتم تنفيذه للعارضين القدامى (الإصدار 15) على الرغم من أنه يمكن إضافته بواسطة شخص ما إذا أراد إرسال متابعة خاصة بالعلاقات العامة.

إغلاق هذه المشكلة الآن بعد هبوط # 16989. من المرجح أن يتم إصدار 4.2 مع الميزة الجديدة اليوم.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات