كيفية استخدام ميزة ملف التعريف التجريبية الجديدة في React

لذا جاء React 16.4.0! (ملاحظة المترجم - تمت إضافة هذه الميزة في الإصدار 16.4.0 ، ثم تمت كتابة هذا المنشور). وفي مثل هذه اللحظات ، أنت تفهم كيف أن جافا سكريبت كنت مهووسًا إذا كنت تتابع التحديثات البسيطة لإطارك المفضل. عظيم!



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

بالإضافة إلى ذلك ، هناك getDerivedStateFromProps لنوع من طريقة getDerivedStateFromProps الجديدة (الآن سيتم استدعاؤها في كل تقديم). لم أستخدم هذا بشكل كافٍ بعد ، لذا لم يكن هذا التحديث مهمًا بالنسبة لي.

ثم رأيت الإعلان ، المدفون تحت العناوين ، أنهم أضافوا مكونًا تجريبيًا جديدًا ، unstable_Profiler . بالنظر إلى أن حياتي الآن غير مستقرة تمامًا ( unstable_ ) ، قررت قراءة RFC وتجربتها .

TLDR

يحاول الأشخاص من فريق React جعل العرض غير متزامن . قد يجعل ذلك من الصعب تحديد وقت عرض المكونات عند التركيب / التحديث. لذلك ، فهم يعبثون بهذا المكون اللامع الجديد اللامع.

إذن ما الذي يمكنك استخدامه اليوم؟

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

باستخدام <Profiler />

تحذير : ربما لا يجب استخدام هذا في الإنتاج (حسنًا ، في الواقع ، هذا غير unstable_ ). في وقت لاحق سينتهون من القدرة على التشكيل الجانبي وكود الإنتاج.

بشكل أساسي ، Profiler هو مكون يمكن استخراجه من حزمة React الافتراضية. نظرًا لأنه يحتوي على اسم مشدد حذر يحذر العديد من الوبر منه ، يمكنك العمل حول هذا على النحو التالي:

 import React, { unstable_Profiler as Profiler } from 'react'; ... const Profiler = React.unstable_Profiler; 

الآن بعد أن أصبح لديك Profiler ، دعنا نميز المكونات! يمكنك لف أي جزء من شجرة JSX في Profiler لمعرفة ما يحدث لها. يقبل Profiler وظيفة onRender ، والتي تلتقط معلومات حول وقت التقديم. هنا مثال بسيط على العداد :

 import React, { unstable_Profiler as Profiler } from 'react'; class ComponentWithProfiling extends React.Component { state = { count: 0 }; logProfile = (id, phase, actualTime, baseTime, startTime, commitTime) => { console.log(`${id}'s ${phase} phase:`); console.log(`Actual time: ${actualTime}`); console.log(`Base time: ${baseTime}`); console.log(`Start time: ${startTime}`); console.log(`Commit time: ${commitTime}`); }; go = direction => () => this.setState(({ count }) => ({ count: direction === "up" ? count + 1 : count - 1 })); render() { return ( <Profiler id="app" onRender={this.logProfile}> <button onClick={this.go("up")}>️</button> <div>The count is {this.state.count}</div> <button onClick={this.go("down")}></button> </Profiler> ); } } 

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


7jroojkv30.codesandbox.io

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

بعد ذلك ، نحصل على الوقت actualTime baseTime . إنها مرتبطة بالوقت الفعلي الذي تقضيه شركة React في تقديم الحسابات ؛ أي معرفة ما الذي تغير. يرجى ملاحظة أن الوقت الفعلي (الوقت الأولي) للاتصال الأولي (التحميل) أطول من وقت التحديث (التحديث). هذا لأنه عند الاتصال الأولي ، كل شيء تقنيًا "جديد" من الناحية الفنية. أثناء التحديث ، يجب أن تكون الحسابات أكثر بساطة ، لأنني آمل أن يتم تحديث المكونات في الشجرة فقط إذا تغيرت بالفعل (أي عندما تتغير قيم prop / state).

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

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

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

الخلاصة

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

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

أتطلع إلى ما سيفعله فريق React مع Profiler في المستقبل. شكرا @ bvaughn لإضافة هذه الميزة الأنيقة !

من المترجم:
في الوقت الحالي (الإصدار الحالي 16.6.0) لا يعمل Profiler مع العرض من جانب الخادم. طلب الميزة موجود بالفعل.