Why DOM is slow
JS မှာ DOM ကိုထိရင် နှေးတယ်ပေ့ါ။ ဒါကြောင့်မို့ React လိုကောင်တွေမှာ DOM အစား Virtual DOM ကိုသုံးတယ်။
ပိုမြန်တယ်ပေ့ါ။ ဆိုချင်တာက DOM ကို ၃ ၄ ခါထိရမဲ့ကိစ္စတွေကို Virtual DOM ကိုသုံးတဲ့အတွက် ၁ ခေါက် လောက်ပဲထိရမယ်ဆိုပါစို့။
အဲ့လိုနည်းနဲ့ real DOM ကိုထိတာနည်းသွားတဲ့အတွက်ပိုမြန်တဲ့သဘောပေါ့။
ဘာလို့ DOM ကိုထိတာနဲ့ နှေးတာလဲပေ့ါ။ Browser မှာ အဓိကအားဖြင့် ၂ပိုင်းရှိတယ်။
Render နဲ့ JS Engine ပေ့ါ။ Render ဆိုတာ WebKit လိုကောင်ကိုပြောတာအဓိက HTML CSS layout UI စတာတွေကို
screen ပေါ်မှာမြင်ရအောင်လုပ်ပေးတဲ့ကောင်။ သူက C++ နဲ့များသောအားဖြင့်ရေးလေ့ရှိတယ်။
JS engine ကျတော့ Chrome ဆို V8 ပေ့ါ JavaScipt ကို interpret လုပ်ပေးတာ။
interpret လို့သာပြောပေမဲ့တကယ်တမ်းသုံးတာက အများအားဖြင့် bytecode လောက်ထုတ်ပြီး JIT လုပ်ကြတာများတယ်။
အဲ့တော့ JS code ကနေ DOM ကိုပြင်တဲ့ code ကိုခေါ်ပြီဆိုပါစို့။
element.innerHTML = “some html tag”
ထားပါတော့ innerHTML သည် DOM element ရဲ့ကောင်ကို ကြိုက်တဲ့ tag or set of tag နဲ့အစားထိုးလို့ရတယ်။
အဲ့တော့ JS engine V8(Chrome သုံးနေတယ်ဆိုပါစို့) ကနေ ခုနက Rendering module (WebKit) ကိုလှမ်းပြီး context switch ရမယ်။
ဆိုချင်တာက လုပ်လက်စ run လက်စ JS က state တွေခနထား C++ ချင်းဆို C++ call နဲ့ Rendering Engine က method ကိုလှမ်းခေါ်။
Rendering engine က ခုနက innerHTML လုပ်ဖို့ကျတော့ innerHTML ထဲက HTML ကို parse လုပ်ရပြန်ရော။
အဲ့မှာတင် တခါလေး၊ နောက်သူက element တခုကိုပြင်ပေမဲ့ အဲ့ effect ကြောင့် တခြား element တွေ ရဲ့ position တွေ
box model တွေပါထိနိုင်တယ်။အဲ့တော့ DOM tree ကြီးတခုလုံးကို layout ပြန်ချဖို့ ဟိုး root အစကနေပြန်တွက်ရလိမ့်မယ်။
ပြီးတော့မှ အဲ့တွက်ထားတဲ့ layout ကို repaint ပြန်လုပ်ပေ့ါ။ (Screen မှာမြင်ရအောင် low level graphic api call တွေနဲ့ပုံတွေဆွဲပေ့ါ)။
အဲ့တော့ Graphic driver ဘာညာက IO သွားထိပေ့ါ။ ခုနက ပြန်ပြီးတွက် layout ချပြန်ဆွဲရတဲ့ process ကို page reflow လို့ခေါ်တယ်။
အဲ့တာတွေလုပ်ရတော့ နှေးတယ်ပေါ့။
React Virutal DOM မှာကျတော့ မလိုအပ်ရင်မလုပ်ပဲ batch လိုက်စုလုပ်သလိုလုပ်တော့မြန်တဲ့သဘောပေါ့။
Original link
SPM' Notes 