تیم ری‌اکت دارن چیکار میکنن؟ (قسمت چهارم)

این کامیت یکم جذاب تر از کامیتای قبلیه, از این لحاظ که به API ربط نداره و مربوط به لایه هایی پایین تر ری‌اکته (خیلی پایینتر, تقریبا دور و بر خود Scheduler). ما هم حین بررسی کردنش سعی می‌کنیم یکم رویکردمون رو عوض کنیم و بیشتر کدهای ری‌اکت رو ورق بزنیم :)

خب, همه چی از اونجا شروع شد که بچه های فیسبوک تصمیم گرفتن اولین کانتریبیوتشون رو به W3C انجام بدن و یه api جدید معرفی کنن و توی WICG منتشرش کنن به اسم isInputPending که میتونید specification اش رو از اینجا بخونید. این api به ما اجازه میده که بفهمیم آیا کاربر درحال تعامل با صفحه وب هست یا نه. طرز استفاده اش هم به این شکله:

navigator.scheduling.isInputPending(arrayOfInputEventTypes)

که بعنوان آرگومان ورودی یه آرایه از eventType های مختلف رو میگیره و به ما میگه که آیا هیچکدوم از این event ها بدلیل بلاک شدن ترد توسط کد ما متوقف شدن یا نه. اگر هیچ آرگومانی هم ورودی ندیم همین کار رو برای همه eventType هایی که پشتیبانی می‌کنه انجام میده. راجب eventType های پشتیبانی شده اینجا گفتن که باید هر سه ایونت click, keydown و wheel ساپورت بشن و سایر ایونت ها مثل MediaCapture به عهده مرورگر هست که آیا پشتیبانی بکنه یا نه. (دقت کنید داریم راجب api خوده خود مرورگر ها صحبت می‌کنیم که ارتباطی با کار ری‌اکت نداره و الان تو ورژن ۷۵ کروم هم می‌تونید بصورت experimental استفاده کنید این api رو)

تو ویدیوی کوتاه زیر نحوه کار این api رو کامل ‌می‌بینید. من که به شخصه خیلی دوستش دارم :)

(اگه مرورگر کرومتون ورژنش بین ۷۴ و ۷۶ عه می‌تونید دموی بالا رو از اینجا امتحان کنید. سورسش هم اینجا موجوده.)

خب حالا این چه ربطی به ری‌اکت داره؟
داخل ارائه‌ام توی سومین دورهمی جامعه ری‌اکت ایران مفصل راجب fiber و پکیج scheduler و اینکه چجوری روی پرفورمنس اپ ما تاثیر میذارن صحبت کردم (لینک). و گفتیم ری‌اکت برای اینکه صفحه رو ریسپانسیو نگه داره مرتب کنترل رو به دست مرورگر برمیگردونه تا مرورگر کارهای خودش رو انجام بده, حتی اگه درواقع کاری وجود نداشته باشه حدود ۶۰ بار در ثانیه ری‌اکت رندر کردن خودش رو متوقف می‌کنه که باعث میشه یه کوچولو روی سرعت رندر کردنش تاثیر منفی بذاره. حالا به لطف این api, پکیج scheduler کم‌تر مزاحم ری‌اکت میشه و میتونه فقط مواقعی که کاربر تعاملی با صفحه داشته درخواست کنترل کنه.

ولی همچنان همونطور که تو این کامیت می‌بینیم ری‌اکت هر ۳۰۰ میلی‌ثانیه فارغ از اینکه چه اتفاقی افتاده یدور کنترل رو دست مرورگر برمیگردونه.

عمده تغییرات توی این فایل و داخل فانکشن shouldYieldToHost اتفاق افتاده‌ان. توی این خط چک کردیم که اگه هنوز از ۱۶ میلی‌ثانیه نگذشتیم (۶۰ بار در ثانیه) به کارمون ادامه بدیم و توجهی به هیچی نداشته باشیم. توی این خط چک شده که آیا isInputPending هست یا نه که اگه باشه وارد شرط نمی‌شیم و مستقیم true برمیگردونیم تا YieldToHost اتفاق بیافته و مرورگر کنترل رو دست بگیره. اما اگه نداره داخل بدنه شرط این عبارت رو برمیگردونیم که درواقع اگه ۳۰۰ میلی‌ثانیه از پایان زمان ۱۶ میلی‌ثانیه‌ای ما گذشته باشه true عه و کنترل به دست مرورگر برمگیرده و اگر نه همچنان false عه و کنترل دست ری‌اکت می‌مونه.

https://github.com/facebook/react/pull/15959

دیگر مقالات من: