Component-Based Architecture ရဲ့ အားသာချက်များ

Component-Based Architecture ကို ဘာကြောင့် ဒီလောက်တောင် လူကြိုက်များရတာလဲ? အဓိက အားသာချက် (၄) ချက် ရှိပါတယ်။

၁။ ပြန်လည်အသုံးပြုနိုင်ခြင်း (Reusability)

ဒါက အထင်ရှားဆုံးနဲ့ အကောင်းဆုံး အားသာချက်ပါ။ ဥပမာ - Button Component တစ်ခုကို သေသေချာချာ ရေးထားပြီးရင်၊ အဲဒီ Button ကို Login Page မှာလည်း သုံးလို့ရသလို၊ Register Page မှာလည်း သုံးလို့ရပါတယ်။ Payment Page ရောက်လည်း သုံးလို့ရပါတယ်။ Code တွေကို နေရာတိုင်းမှာ ထပ်ခါထပ်ခါ ရေးနေစရာ မလိုတော့ပါဘူး။ “Write Once, Use Everywhere” (တစ်ခါရေးပြီး နေရာတိုင်း သုံးမယ်) ဆိုတဲ့ သဘောတရားပါပဲ။

၂။ ပြုပြင်ထိန်းသိမ်းရ လွယ်ကူခြင်း (Maintainability)

ဆိုပါစို့… Website တစ်ခုလုံးမှာ ရှိနေတဲ့ Button တွေ အကုန်လုံးကို အပြာရောင်ကနေ အနီရောင် ပြောင်းချင်တယ်။

• Old Way (အရင်ပုံစံ): HTML ဖိုင် တိုင်းကို လိုက်ဖွင့်၊ Button Code တွေ လိုက်ရှာပြီး အရောင်ကို တစ်ခုချင်း လိုက်ပြောင်းရပါမယ်။ (Button အခု ၁၀၀ ရှိရင် အခါ ၁၀၀ ပြင်ရမှာပါ)။
• Component Way (ခေတ်သစ်ပုံစံ): Button Component ဖိုင်တစ်ခုတည်းကိုပဲ ဖွင့်၊ အရောင်ပြောင်းလိုက်တာနဲ့ အဲဒီ Component ကို သုံးထားတဲ့ ကျန်တဲ့ နေရာအားလုံးမှာ အလိုလို လိုက်ပြောင်းသွားပါလိမ့်မယ်။

၃။ သီးခြားခွဲထုတ်ထားခြင်း (Encapsulation)

Component တစ်ခုဟာ သူ့ကမ္ဘာနဲ့သူ သီးခြား တည်ရှိပါတယ်။ ဥပမာ - Navbar Component ထဲမှာ ရေးထားတဲ့ CSS ဒီဇိုင်းက Footer Component ဆီကို သွားပြီး သက်ရောက်မှု မရှိပါဘူး။ အရင်တုန်းက CSS ဖိုင် အကြီးကြီးတစ်ခုတည်းမှာ အကုန်လုံးကို စုရေးတဲ့အခါ Class Name တွေ တူသွားပြီး ဒီဇိုင်းတွေ ပျက်စီးသွားတတ်ပါတယ်။ Component တွေကတော့ ကိုယ့်စည်း ကိုယ့်ဘောင်နဲ့ ကိုယ်စီ ရှိကြတဲ့အတွက် ပိုပြီး စိတ်ချရပါတယ်။

၄။ ပူးပေါင်းဆောင်ရွက်ရ လွယ်ကူခြင်း (Collaboration)

Team နဲ့ အလုပ်လုပ်တဲ့အခါ အရမ်း အဆင်ပြေပါတယ်။ ဥပမာ -

• Developer A က Header Component ကို ရေးနေချိန်မှာ
• Developer B က Sidebar Component ကို တစ်ပြိုင်နက် ရေးလို့ရတယ်။
• Developer C ကလည်း Content ကို သီးခြား ရေးလို့ရတယ်။

ဖိုင်တစ်ခုတည်းမှာ လူတွေ အများကြီး ဝိုင်းရေးပြီး Code တွေ ငြိတာ၊ တစ်ယောက်ရေးတာ တစ်ယောက် သွားဖျက်မိတာ (Merge Conflict) မျိုးတွေ အများကြီး သက်သာသွားပါတယ်။

သတိပြုရန် (Trade-offs)

ကောင်းကွက်တွေ အများကြီး ရှိသလို သတိထားရမယ့် အချက်တွေလည်း ရှိပါတယ်။ ၁။ Complexity (ရှုပ်ထွေးလာခြင်း): Component တွေ အရမ်းများလာတဲ့အခါ၊ ဘယ် Component က ဘယ်ဖိုင်မှာ ရှိလဲဆိုတာ ရှာရခက်လာတတ်ပါတယ်။ Folder တွေကို စနစ်တကျ ခွဲထားဖို့ လိုပါတယ်။ ၂။ Data Flow (ဒေတာ စီးဆင်းမှု): Component တစ်ခုကနေ နောက်တစ်ခုဆီကို Data လှမ်းပို့ရတဲ့အခါ (Props Drilling) အဆင့်ဆင့် ဖြတ်သွားရလို့ နည်းနည်း ရှုပ်ထွေးနိုင်ပါတယ်။ (ဒါကို ဖြေရှင်းဖို့အတွက် Redux လိုမျိုး State Management တွေ ပေါ်လာတာဖြစ်ပါတယ်)။