این فصل دربارهٔ آن است که میان تغییرِ وضعیت واکنشگرای شما و بهروزرسانی پیکسلها روی صفحه چه اتفاقی میافتد. بهندرت لازم است به آن فکر کنید — اما درک این مدل توضیح میدهد چرا کدِ $mol بدون تلاش خاصی سریع میماند.
$mol درختِ مجازی را diff نمیکند. هر ویژگیِ نما مستقیماً به گره یا ویژگیِ DOM که کنترل میکند متصل است، از طریق همان سلولهای واکنشگرایی که پیشتر در وضعیت دیدید. وقتی یک سلول تغییر میکند، فقط همان اتصالهای دقیقی که آن را میخوانند دوباره اجرا میشوند — نه یک زیردرخت، نه یک تابعِ کامپوننت، فقط ویژگیهای متأثر.یعنی هیچ گذرِ آشتیدهیای برای بهینهسازی وجود ندارد، هیچ کلیدی برای تنظیم دستیِ diff فهرست نیست، و هیچ memo/shouldComponentUpdateای که به آن پناه ببرید. گراف وابستگیها از پیش کمینهمجموعهٔ بهروزرسانیها را میداند.
یک نما تنها زمانی ساخته میشود که چیزی آن را بخواهد. صفحهای که هرگز به آن نمیروید هرگز ساخته نمیشود؛ زبانهای که هرگز باز نمیکنید هیچ هزینهای ندارد. چون ساخت بر پایهٔ نیاز و کششده است، سرِهمکردنِ درختهای بزرگِ کامپوننت ارزان است — بخشهایی که لازم نیستند صرفاً هنوز وجود ندارند.
$mol تنها آنچه را که درون ناحیهٔ دید است رندر میکند. کامپوننتهایی که از دید بیرون اسکرول شدهاند بهعنوان DOMِ پنهان نگه داشته نمیشوند — اصلاً ساخته نمیشوند و همان لحظه که به محدوده اسکرول میشوند ساخته میشوند. این یک ویژگیِ معماریِ فریمورک است، نه یک قابلیتِ اختیاری و نه یک کامپوننتِ فهرستِ ویژه: هر چیدمانی مجازیسازی میشود، پس فهرستی با ده مورد و فهرستی با دههزار مورد تقریباً به یک اندازه برای نمایش هزینه دارند.اثر عملی این است که درختهای معمولیِ کامپوننت و فهرستهای بلند مینویسید بدون آنکه سراغ کتابخانههای windowing بروید.
ادعاهای کارایی تنها زمانی مفیدند که بتوانید بازتولیدشان کنید. بهجای نقلِ ارقام در اینجا، $mol در js-framework-benchmarkِ اجتماعی شرکت میکند؛ میتوانید نتایجش را بخوانید و مجموعه را خودتان دوباره اجرا کنید:نتایج js-framework-benchmarkآن را بهعنوان منبع حقیقت برای مقایسهها در نظر بگیرید — اندازهگیریشده، نسخهبندیشده و مستقل از این صفحه.
