satisfies ကို မိတ်ဆက်ခြင်း: အကောင်းဆုံးနှစ်ခုပေါင်းစပ်ခြင်း (The Best of Both Worlds)

💡 ရည်ရွယ်ချက်

satisfies Operator ရဲ့ အသုံးပြုရမယ့် Syntax နဲ့ သူဘယ်လို အလုပ်လုပ်သလဲ (Behavior) ကို လေ့လာဖို့၊ ပြီးတော့ မူရင်း Object ရဲ့ အတိအကျ Type ကို မပျောက်ပျက်စေဘဲ စည်းမျဉ်းနဲ့ ကိုက်ညီမှု ရှိ/မရှိ ကို ဘယ်လို စစ်ဆေး (Validate) ပေးသလဲဆိုတာ သိရှိဖို့ ဖြစ်ပါတယ်။

ဖြေရှင်းနည်း: The satisfies Operator

TypeScript (Version 4.9 ကစပြီး) satisfies ဆိုတဲ့ Operator အသစ်ကို မိတ်ဆက်ပေးခဲ့ပါတယ်။ အရင် သင်ခန်းစာတွေမှာ ကြုံတွေ့ခဲ့ရတဲ့ ပြဿနာ (Type Annotation ရဲ့ ကျယ်ပြန့်သွားမှု နဲ့ Type Assertion ရဲ့ မလုံခြုံမှု) တွေကို ဒီ satisfies Operator က ပြေလည်အောင် ဖြေရှင်းပေးမှာ ဖြစ်ပါတယ်။

Syntax: expression satisfies Type

ဘယ်လို အလုပ်လုပ်သလဲ: ပြောင်းလဲခြင်းမရှိဘဲ စစ်ဆေးခြင်း (Validation without Transformation)

စောစောက AppConfig ဥပမာကိုပဲ satisfies Operator သုံးပြီး ပြန်ရေးကြည့်ရအောင်။

config.ts

interface AppConfig {
  env: "development" | "production" | "test";
  port: number;
  featureFlags: Record<string, boolean>;
}

// ကျွန်တော်တို့ရဲ့ မူရင်း အတိအကျ Object
const myConfig = {
  env: "development",
  port: 3000,
  featureFlags: {
    darkMode: true,
    newOnboarding: false
    // extraFeature: "yes" // ဒီ property ကို စမ်းပြီး ထည့်ကြည့်ပါ၊ TypeScript က ချက်ချင်း Error ပြပါလိမ့်မယ်!
  }
} satisfies AppConfig; // ဒီနေရာမှာ satisfies operator ကို အသုံးပြုလိုက်ပါတယ်

satisfies AppConfig လို့ ရေးလိုက်တာက ဘာလုပ်ပေးတာလဲ ဆိုရင် -

• Validation Check (မှန်ကန်မှု စစ်ဆေးပေးခြင်း):

  satisfies AppConfig ဟာ သူ့ရဲ့ ဘယ်ဘက်ခြမ်းမှာရှိတဲ့ Object Literal ကြီးဟာ AppConfig Interface ရဲ့ စည်းမျဉ်းတွေနဲ့ ကိုက်ညီမှု ရှိ/မရှိ ကို TypeScript ကို သေချာ စစ်ဆေးခိုင်းတာ ဖြစ်ပါတယ်။

  • port ကို စာလုံးပေါင်း မှားပြီး prt လို့ ရေးမိရင် TypeScript က ချက်ချင်း Error ပြပါမယ်။
  • env နေရာမှာ "staging" လို့ ထည့်မိရင်လည်း (AppConfig.env ရဲ့ Union ထဲမှာ မပါဝင်တဲ့အတွက်) TypeScript က Error ပြပါမယ်။
  • featureFlags.darkMode နေရာမှာ Number တစ်ခုခု ထည့်မိရင်လည်း (boolean မဟုတ်တဲ့အတွက်) TypeScript က Error ပြပါမယ်။ (Record<string, boolean> က boolean Values တွေကိုသာ လက်ခံလို့ပါ)

• Specificity ကို ထိန်းသိမ်းပေးခြင်း (တိကျမှုကို မပျောက်ပျက်စေခြင်း):

  အရေးအကြီးဆုံး အချက်ကတော့ myConfig ရဲ့ Type ဟာ Type Annotation (:) သုံးတုန်းကလို Type Widening (Type ကို ယေဘုယျ ဆန်အောင် ကျယ်ပြန့်ပစ်လိုက်တာမျိုး) လုံးဝ မဖြစ်သွားပါဘူး။ မူလ သတ်မှတ်ထားတဲ့ အတိအကျ Type ပုံစံအတိုင်း ဆက်လက် တည်ရှိနေစေပြီး၊ တစ်ချိန်တည်းမှာပဲ AppConfig ရဲ့ စည်းမျဉ်းတွေနဲ့ ကိုက်ညီမှု ရှိ/မရှိ ကိုပါ ယှဉ်တွဲ စစ်ဆေးပေးသွားတာ ဖြစ်ပါတယ်။

config.ts

// typeof myConfig ရဲ့ Type ဟာ အခုအချိန်အထိ အတိအကျ ဆက်လက် တည်ရှိနေဆဲပါ (STILL specific):
// {
//   env: "development";
//   port: number; // (ဒါမှမဟုတ် Literal အဖြစ် 3000 လို့ သိနိုင်တယ်)
//   featureFlags: {
//     darkMode: boolean; // (ဒါမှမဟုတ် true)
//     newOnboarding: boolean; // (ဒါမှမဟုတ် false)
//   };
// }

အကျိုးကျေးဇူးများ

အခုဆိုရင် Object ထဲမှာရှိတဲ့ အတိအကျ Properties လေးတွေကို Safely Access (Type-safe ဖြစ်ဖြစ် လုံလုံခြုံခြုံ ခေါ်သုံး) နိုင်သွားပါပြီ။

config.ts

console.log(myConfig.env); // Type ဟာ "development" အတိအကျ ဖြစ်ပါတယ်

// myConfig.env = "production";
// ဒီနေရာမှာ myConfig.env ရဲ့ Type က "development" အတိအကျ ဖြစ်နေသေးတဲ့အတွက်၊ တခြား "production" လိုမျိုး ပြန်ပြောင်းဖို့ ကြိုးစားရင် TypeScript က Error ပြပါလိမ့်မယ်။

console.log(myConfig.featureFlags.darkMode); // အဆင်ပြေပြေ အလုပ်လုပ်ပါတယ်။ Type က boolean (ဒါမှမဟုတ် true) ဖြစ်ပါတယ်။

// console.log(myConfig.featureFlags.someOtherFlag);
// ဒါကတော့ Error ပြပါမယ်။ ဘာလို့လဲဆိုတော့ 'someOtherFlag' ဆိုတာ မူရင်း myConfig Object ထဲမှာ မပါဝင်လို့ပါပဲ။

ဥပမာ ခိုင်းနှိုင်းချက် -

• “satisfies ကို စစ်ဆေးရေးမှူး (Inspector) တစ်ယောက်က Checklist (ဥပမာ - AppConfig) တစ်ခုကိုင်ပြီး စစ်ဆေးနေတာမျိုး စိတ်ကူးကြည့်ပါ။”
• “သင်က အဲ့ဒီ Inspector ကို သင်ကိုယ်တိုင် အတိအကျ ဖန်တီးထားတဲ့ ပစ္စည်းတစ်ခု (myConfig Object Literal) ပေးလိုက်တယ်။”
• “Inspector က သင်ပေးလိုက်တဲ့ ပစ္စည်းဟာ Checklist ထဲက စံနှုန်းတွေနဲ့ ကိုက်ညီမှု ရှိ/မရှိ သေချာ စစ်ဆေးပါတယ်။ မကိုက်ညီရင် ချက်ချင်း ငြင်းပယ်ပါလိမ့်မယ် (TypeScript Error ပြပါမယ်)။”
• “အကယ်၍ စစ်ဆေးမှု အောင်မြင်သွားရင်တော့ သင့်ရဲ့ ပစ္စည်းကို ဘာမှ မပြင်ဆင်၊ မပြောင်းလဲဘဲ မူလအတိုင်း သင့်ဆီ ပြန်ပေးပါလိမ့်မယ်။ သူတို့က ပစ္စည်းကို ပြုပြင်ပြောင်းလဲတာ ဒါမှမဟုတ် Checklist ထဲက Generic Version (ယေဘုယျ ပုံစံ) ကြီးနဲ့ အစားထိုးလိုက်တာမျိုး လုံးဝ မလုပ်ပါဘူး။ သင်က သင့်ရဲ့ မူရင်း အတိအကျ ပစ္စည်းကို ပြန်ရမှာ ဖြစ်သလို၊ တစ်ချိန်တည်းမှာပဲ ဒါဟာ သတ်မှတ်ထားတဲ့ Standards တွေနဲ့ ကိုက်ညီတယ် ဆိုတဲ့ အာမခံချက်ကိုပါ ရရှိမှာ ဖြစ်ပါတယ်။”