এই অধ্যায় হলো আপনার রিয়্যাক্টিভ স্টেট বদলানো আর স্ক্রিনে পিক্সেল আপডেট হওয়ার মাঝে কী ঘটে সে সম্পর্কে। আপনাকে এটি নিয়ে খুব কমই ভাবতে হয়——কিন্তু মডেলটি বোঝা ব্যাখ্যা করে কেন $mol কোড কোনো বিশেষ চেষ্টা ছাড়াই দ্রুত থাকে।
$mol একটি ভার্চুয়াল ট্রি diff করে না। প্রতিটি ভিউ প্রপার্টি সরাসরি সেই DOM নোড বা অ্যাট্রিবিউটে বাঁধা থাকে যেটি এটি নিয়ন্ত্রণ করে, সেই একই রিয়্যাক্টিভ সেলের মাধ্যমে যেগুলো আপনি ইতিমধ্যে স্টেট-এ দেখেছেন। একটি সেল বদলালে শুধু যে বাইন্ডিংগুলো এটি পড়ে সেগুলোই পুনরায় চলে——কোনো সাবট্রি নয়, কোনো কম্পোনেন্ট ফাংশন নয়, শুধু প্রভাবিত প্রপার্টিগুলো।এর মানে অপ্টিমাইজ করার মতো কোনো রিকনসিলিয়েশন পাস নেই, লিস্ট diff-এর জন্য হাতে টিউন করার মতো কোনো কী নেই, আর হাত বাড়ানোর মতো কোনো memo/shouldComponentUpdate নেই। ডিপেন্ডেন্সি গ্রাফ ইতিমধ্যে আপডেটের ন্যূনতম সেটটি জানে।
একটি ভিউ কেবল তখনই তৈরি হয় যখন কিছু এটির অনুরোধ করে। যে স্ক্রিনে আপনি কখনো যান না তা কখনো তৈরি হয় না; যে ট্যাব আপনি কখনো খোলেন না তার কোনো খরচ নেই। যেহেতু তৈরি হওয়া চাহিদা অনুযায়ী ও ক্যাশড, বড় কম্পোনেন্ট ট্রি কম্পোজ করা সস্তা——যে অংশগুলো দরকার নেই সেগুলো কেবল এখনো অস্তিত্বেই নেই।
$mol শুধু ভিউপোর্টের ভেতরে যা আছে তাই রেন্ডার করে। দৃষ্টির বাইরে স্ক্রল হয়ে যাওয়া কম্পোনেন্টগুলো লুকানো DOM হিসেবে রাখা হয় না——সেগুলো আদৌ তৈরি হয় না, এবং যে মুহূর্তে সেগুলো পরিসরে স্ক্রল হয় তখনই তৈরি হয়। এটি ফ্রেমওয়ার্কের একটি স্থাপত্যগত বৈশিষ্ট্য, কোনো অপশনাল ফিচার বা বিশেষ লিস্ট কম্পোনেন্ট নয়: যেকোনো লেআউট ভার্চুয়ালাইজড, তাই দশটি আইটেমের একটি লিস্ট আর দশ হাজারের একটি লিস্ট দেখাতে প্রায় একই খরচ হয়।বাস্তব প্রভাব হলো, আপনি সাধারণ কম্পোনেন্ট ট্রি ও লম্বা লিস্ট লেখেন কোনো উইন্ডোয়িং লাইব্রেরির দ্বারস্থ না হয়ে।
পারফরম্যান্সের দাবি কেবল তখনই কাজের যখন আপনি সেগুলো পুনরুৎপাদন করতে পারেন। এখানে সংখ্যা উদ্ধৃত করার বদলে, $mol কমিউনিটির js-framework-benchmark-এ অংশ নেয়; আপনি এর ফলাফল পড়তে পারেন এবং স্যুটটি নিজে আবার চালাতে পারেন:js-framework-benchmark ফলাফলএটিকে তুলনার সত্যের উৎস হিসেবে ধরুন——পরিমাপকৃত, সংস্করণকৃত, এবং এই পৃষ্ঠা থেকে স্বাধীন।
