Traditional useEffect vs RTK Query

web developer တွေနဲ့ API call တွေဟာ အမြဲထိတွေ့ရတာ ဖြစ်ပါတယ်။ website တစ်ခုတည်ဆောက်တဲ့ အခါမှာ api call တွေက မပါမဖြစ် ဖြစ်သလိုပဲ website performance တွေဟာလဲ ဒီ API call တွေနဲ့ ဆက်စပ်နေပါတယ်။ ဒါကြောင့် medium to large scale project တွေမှာ API call တွေကို efficient ဖြစ်ဖြစ် ကိုင်တွယ်ဖို့နဲ့ website performance ကို ကောင်းမွန်စေဖို့ အတွက် သိထားသင့် react query အကြောင်းအပြင် traditional way ထက် အားသာတဲ့အချက်တွေကို နှိုင်းယှဉ်ပြီး ပြောပြပေးထားပါတယ်။

react developer တွေအနေနဲ့ API တစ်ခုကို call လုပ်မယ်ဆိုရင် အသုံးများတာကတော့ useEffect hook နဲ့ fetch / axios ဒါမျိုးနဲ့ တွဲသုံးကြတာ များပါတယ်။ ဒါက react app တွေမှာ API call တွေအတွက် standard way တစ်ခုဖြစ်ပါတယ်။ ဒါပေမဲ့ ဒီ standard way တစ်ခုထဲနဲ့တော့ react app တွေကို မတည်ဆောက်သင့်ပါဘူး။ အထူးသဖြင့် Growth ဖြစ်လာမဲ့ project တွေ နဲ့ large project တွေမှာ မသုံးသင့်ပါဘူး။

ဒီ standard way ရဲ့ အားနည်းချက်တွေကတော့

Own state တွေကိုပဲ management ပြုလုပ်ရတာ။

ဥပမာအားဖြင့် react component တစ်ခုရှိမယ်။ အာ့ component ထဲမှာ သာမန် API call တစ်ခုကို လုပ်ဆောင်မယ်ဆိုရင်တော့ အနည်းဆုံး state သုံးခုကို declare ပြုလုပ်ရမှာပါ။

1. response state

2. error state

3. loading state 

ဒီသုံးခုလိုအပ်မှာဖြစ်ပါတယ်။ နောက်ပြီး ဒီ state တွေဟာ ဒီ component တစ်ခုထဲမှာပဲ အသုံးပြုနိုင်မှာ ဖြစ်ပြီးတော့ တခြား component တွေကနေ အသုံးပြုချင်ရင်တော့ state management library တွေသုံးတာမျိုး / context ထဲမှာ သိမ်းတာမျိုး ထပ်လုပ်ရမှာဖြစ်ပါတယ်။

နောက်ထပ်ပြဿနာတွေက ဘာတွေလဲ။

ပထမတစ်ခုကတော့ duplicate request တွေ များလာနိုင်တာပါ။ မတူညီတဲ့ component တွေမှာ တူညီတဲ့ API request တွေ လုပ်မယ်ဆိုရင် component တွေများလာတဲ့အခါမှာ မလိုအပ်တဲ့ duplicate request တွေ အများကြီးဖြစ်နေမှာဖြစ်ပြီး မလိုအပ်ဘဲ component တွေကို ခနခန re-render ပြုလုပ်နေစေမှာဖြစ်ပါတယ်။ ဒါက website performance ကို အတော်လေးထိခိုက်နိုင်ပါတယ်။

ဒုတိယတစ်ခုကတော့ နည်းနည်းလေး ကသိကအောက်ဖြစ်ရတဲ့ error state တွေ loading state တွေ အတွက် manually handle ပြုလုပ်ရမှာဖြစ်ပါတယ်။ ဒါကလဲ API call တစ်ခါလုပ်တိုင်းမှာ တစ်ခါ handle ရမှာဆိုတော့ call တွေများလာတဲ့ အခါမှာ boilerplate code ( လိုတာထက်ပိုတဲ့ ရှုပ်ထွေးတဲ့ ကုဒ်) တွေ များလာမှာပါ။

တတိယတစ်ခုကတော့ အဆိုးဆုံးပါပဲ။ ဒါကတော့ caching မပါဝင်တာဖြစ်ပါတယ်။ cache management မပါတဲ့ website performance က တော်တော်ကြီးကို ဆိုးဝါးပါတယ်။ render ချတိုင်း ရရှိပြီးသား တူညီတဲ့ data ကြီးကို နောက်ထပ်တစ်ခေါက် ပြန် request လုပ်နေရတာကြီးက တော်တော်ကို အဆင်မပြေတာပါ။

ဒါဆိုရင် ဒီ traditional way ကြီးကို မသုံးရတော့ဘူးလား ?

အာ့လိုလဲမဟုတ်ပါဘူး။ အပေါ်မှာပြောခဲ့သလိုပဲ saas project လိုဟာမျိုးတွေ နဲ့ large project တွေမှာပဲ ဒီလို traditional way ကို ရှောင်ရှားပြီး react query လိုမျိုး ဒါမှမဟုတ် redux store ကို သုံးထားမယ်ဆိုရင် redux toolkit ရဲ့ built-in ပါဝင်တဲ့ RTK query လိုမျိုး tools တွေကို အသုံးပြုပြီး အစထဲက develop ပြုလုပ်သင့်ပါတယ်။

ဒီနေရာမှာ react query နဲ့ RTK query တို့က ညီအကိုတွေလိုမို့ တစ်ခုကို သေချာအသုံးပြုဖူးရင် နောက်ထပ်တစ်ခုကို အသုံးပြုတတ်ဖို့က အေးဆေးပါပဲ။ သူတို့တွေက အပေါ်က traditional way ရဲ့ အားနည်းချက်တွေကို မရှိတော့အောင် လုပ်ပေးနိုင်ပါတယ်။

အားသာချက်တွေကတော့

1. ပိုပြီး maintain ပြုလုပ်ရလွယ်ကူမယ်။

2. refactor လုပ်ရတာမြန်ဆန်စေတယ်။

3. boilerplate code တွေကို လျှော့ချပေးတယ်။

4. error/loading တွေအတွက် built-in state တွေ ပါဝင်ပြီးသားဖြစ်တယ်။

5. request တွေ efficient ဖြစ်ဖြစ် handle ပြုလုပ်ဖို့အတွက် auto-refetching / polling လိုမျိုး feature တွေ support လုပ်သလို built-in caching ပါဝင်တာမို့ cache management အပိုင်းကိုလဲ စိတ်ပူစရာမလိုတော့ပါဘူး။

အနှစ်ချုပ်ရမယ်ဆိုရင်တော့ ကိုယ်ရဲ့ website လေးက ရိုးရှင်းမယ်။ simple ဖြစ်မယ်။ response data တွေကိုလဲ global state အနေနဲ့ မလိုဘူးဆိုရင်တော့ သာမန် useEffect + fetch / axios (traditional way) နဲ့တင် လုံလောက်ပါတယ်။ အာ့လိုမဟုတ်ဘဲ ကိုယ့်ရဲ့ project က caching တွေလိုမယ် large ဖြစ်မယ် response data တွေကို component တွေအများကြီးကနေလဲ လိုအပ်မယ် ဆိုရင်တော့ react query ဒါမှမဟုတ် redux toolkit နဲ့ ရေးသားထားရင်တော့ RTK query လိုမျိုး tool တွေကို အသုံးပြုပြီး efficient ဖြစ်ဖြစ် ကိုင်တွယ်သင့်ပါတယ်။