TypeScript ടീം 6.0 റിലീസിലൂടെ ഒരു പുതിയ കംപൈലർ ഫ്ലാഗ് പുറത്തിറക്കിയിട്ടുണ്ട് – --noPropertyAccessFromIndexSignature. ഇത് പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ, ഇൻഡക്സ് സിഗ്നേച്ചറിൽ (index signature) നിന്നുള്ള പ്രോപ്പർട്ടികൾ ഡോട്ട് നോട്ടേഷൻ (dot-notation) ഉപയോഗിച്ച് ആക്സസ് ചെയ്യുന്നത് കംപൈലർ തടയുന്നു. ഇത് ഡെവലപ്പർമാരെ ബ്രാക്കറ്റ് നോട്ടേഷൻ (bracket notation) ഉപയോഗിക്കാൻ നിർബന്ധിക്കുകയും, പ്രൊഡക്ഷനിൽ സംഭവിക്കാവുന്ന undefined മൂല്യങ്ങളെ കംപൈൽ സമയത്ത് തന്നെ കണ്ടെത്താൻ സഹായിക്കുകയും ചെയ്യുന്നു.

ഈ ഫ്ലാഗിന്റെ പ്രാധാന്യം

JavaScript-ൽ, ഒബ്‌ജക്റ്റുകൾ പലപ്പോഴും ഡിക്ഷണറികളായി ഉപയോഗിക്കാറുണ്ട്. TypeScript-ൽ ഇത്തരം ഘടനകളെ ഒരു ഇൻഡക്സ് സിഗ്നേച്ചർ ഉപയോഗിച്ച് ടൈപ്പ് ചെയ്യാൻ സാധിക്കും, ഉദാഹരണത്തിന് Record<string, T>. obj.key, obj["key"] എന്നിവയെ ഈ ഭാഷ ഒരേപോലെയാണ് കണക്കാക്കുന്നത്, അതിനാൽ കീ (key) റൺടൈമിൽ മാത്രം അറിയാൻ കഴിയുന്നതാണെങ്കിൽ പോലും പ്രോപ്പർട്ടി നിലവിലുണ്ടെന്ന് കംപൈലർ അനുമാനിക്കുന്നു. ഈ നിശബ്ദമായ അനുമാനം (silent assumption) പല ക്രാഷുകൾക്കും കാരണമാകുന്നു: obj.missingProp ആക്സസ് ചെയ്യുന്ന കോഡ് കംപൈൽ ചെയ്യുമ്പോൾ പ്രശ്നമില്ലാതെ കാണപ്പെടുമെങ്കിലും, റൺടൈമിൽ ആ മൂല്യം undefined ആയതുകൊണ്ട് എറർ സംഭവിക്കുന്നു.

ഡോട്ട് നോട്ടേഷൻ ഒരു പരോക്ഷമായ ഉറപ്പ് (implicit guarantee) നൽകുന്നു – പ്രോപ്പർട്ടി തീർച്ചയായും ഉണ്ടെന്ന് ഇത് വായനക്കാരെയും ടൈപ്പ് ചെക്കറെയും അറിയിക്കുന്നു. നേരെമറിച്ച്, ബ്രാക്കറ്റ് നോട്ടേഷൻ അനിശ്ചിതത്വം സൂചിപ്പിക്കുന്നു – കീ ഇല്ലാതിരിക്കാൻ സാധ്യതയുണ്ടെന്നും ഫലം undefined ആകാം എന്നും ഇത് വ്യക്തമാക്കുന്നു. --noPropertyAccessFromIndexSignature ഈ ദൃശ്യപരവും സെമാന്റിക് (semantic) ആയതുമായ വ്യത്യാസം നടപ്പിലാക്കുന്നു, അതുവഴി റൺടൈം എററുകളെ കംപൈൽ-ടൈം ഡയഗ്നോസ്റ്റിക്സുകളാക്കി മാറ്റുന്നു.

ഈ ഫ്ലാഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നു

ഫ്ലാഗ് ഓൺ ചെയ്യുമ്പോൾ, ഇൻഡക്സ് സിഗ്നേച്ചറിലൂടെ ഡോട്ട് നോട്ടേഷൻ ഉപയോഗിച്ച് ഒരു പ്രോപ്പർട്ടി ആക്സസ് ചെയ്യുന്ന ഏത് എക്സ്പ്രഷനും ഒരു എററായി കാണിക്കും. കോഡ് ബ്രാക്കറ്റുകൾ ഉപയോഗിച്ച് മാറ്റിയെഴുതേണ്ടതുണ്ട്:

// Before
const name = userData.name;          // OK even if "name" is not in the index

// After enabling the flag
const name = userData["name"];       // Error unless brackets are used

ബ്രാക്കറ്റ് ആക്സസിനായി കംപൈലർ നിലവിൽ ഉപയോഗിക്കുന്ന അതേ undefined-ഹാൻഡ്ലിംഗ് നിയമങ്ങൾ ഇതിനും ബാധകമാക്കുന്നു. --noUncheckedIndexedAccess കൂടി പ്രവർത്തനക്ഷമമാണെങ്കിൽ, userData["name"]-ന്റെ ടൈപ്പ് T | undefined ആയി മാറും, ഇത് ഡെവലപ്പർ ആ മൂല്യം ഉണ്ടോ എന്ന് പരിശോധിക്കാൻ നിർബന്ധിക്കുന്നു.

പ്രായോഗികമായ മൈഗ്രേഷൻ ഘട്ടങ്ങൾ

  1. ഫ്ലാഗ് പ്രവർത്തനക്ഷമമാക്കുക: tsconfig.json-ൽ ഫ്ലാഗ് ചേർക്കുക:

    {
  "compilerOptions": {
    "noPropertyAccessFromIndexSignature": true
  }
}

  2. ടൈപ്പ് ചെക്കർ റൺ ചെയ്യുക. ഇൻഡക്സ് സിഗ്നേച്ചർ കീകൾ ഉപയോഗിച്ചുള്ള എല്ലാ ഡോട്ട് നോട്ടേഷൻ ആക്സസുകളും എററുകളായി കാണിക്കും.

  3. ഡോട്ടുകൾക്ക് പകരം ബ്രാക്കറ്റുകൾ ഉപയോഗിക്കുക. ഈ മാറ്റം മെക്കാനിക്കൽ ആണ്; ഇത് റൺടൈം പെർഫോമൻസിനെ ബാധിക്കില്ല.

  4. ലഭിക്കുന്ന undefined ടൈപ്പുകൾ പരിഹരിക്കുക. ആവശ്യമുള്ള ഇടങ്ങളിൽ nullish coalescing, optional chaining അല്ലെങ്കിൽ എക്സ്പ്ലിസിറ്റ് ചെക്കുകൾ ചേർക്കുക.

  5. മികച്ച സുരക്ഷയ്ക്കായി --noUncheckedIndexedAccess-നോടൊപ്പം ഇത് ഉപയോഗിക്കുന്നത് പരിഗണിക്കുക. ഇവ രണ്ടും ചേർന്ന് ഒരു ഡിക്ഷണറി ശൈലിയിലുള്ള ആക്സസ് ഏത് സമയത്തും ഇല്ലാതിരിക്കാൻ സാധ്യതയുണ്ടെന്ന് ഉറപ്പാക്കുന്നു.

എപ്പോഴാണ് എക്സ്പ്ലിസിറ്റ് പ്രോപ്പർട്ടികൾ ഉപയോഗിക്കേണ്ടത്

ഒരു ഫീൽഡ് സ്ഥിരമായ ഒരു API കോൺട്രാക്റ്റിന്റെ ഭാഗമാണെങ്കിൽ, ഇൻഡക്സ് സിഗ്നേച്ചറിൽ ആശ്രയിക്കുന്നതിന് പകരം അതിനെ ഒരു എക്സ്പ്ലിസിറ്റ് പ്രോപ്പർട്ടിയായി പ്രഖ്യാപിക്കുക. എക്സ്പ്ലിസിറ്റ് പ്രോപ്പർട്ടികൾ ഡോട്ട് നോട്ടേഷൻ അനുവദിക്കുന്നു, ഇത് ആ ഫീൽഡ് എപ്പോഴും ഉണ്ടാകുമെന്ന ഉറപ്പ് നിലനിർത്തുന്നു (ടൈപ്പ് സിസ്റ്റത്തിന് പരിശോധിക്കാൻ കഴിയുന്നിടത്തോളം). കീ മുൻകൂട്ടി അറിയാൻ കഴിയാത്ത ഡൈനാമിക് ഡാറ്റയ്ക്ക് മാത്രം ഇൻഡക്സ് സിഗ്നേച്ചറുകൾ ഉപയോഗിക്കുക.

മറ്റൊരു വശം: വർബോസിറ്റി (verbosity) കൂടുന്നു

ഫ്ലെക്സിബിൾ ഒബ്‌ജക്റ്റുകൾ കൂടുതലായി ഉപയോഗിക്കുന്ന കോഡ്ബേസുകളിൽ, അധിക ബ്രാക്കറ്റുകൾ അനാവശ്യമായി (noisy) തോന്നാം. ഈ ഫ്ലാഗ് കർശനമായ ഒരു അച്ചടക്കം ആവശ്യപ്പെടുന്നു, ഇത് പഴയ പ്രോജക്റ്റുകളിൽ വലിയ തോതിലുള്ള റീഫാക്ടറിംഗ് (refactor) ആവശ്യമായി വന്നേക്കാം. അത്തരം സാഹചര്യങ്ങളിൽ, പുതിയ മോഡ്യൂളുകളിൽ മാത്രം ഈ ഫ്ലാഗ് പരിമിതപ്പെടുത്തിക്കൊണ്ട് ഘട്ടംഘട്ടമായി ഇത് നടപ്പിലാക്കാം.

ഇനി ശ്രദ്ധിക്കേണ്ടവ

ടൈപ്പ് സേഫ്റ്റി (type safety) വർദ്ധിപ്പിക്കുന്നതിനുള്ള TypeScript 6.0-ലെ വലിയൊരു നീക്കത്തിന്റെ ഭാഗമാണ് ഈ ഫ്ലാഗ്. ഭാവി റിലീസുകളിൽ ഒബ്‌ജക്റ്റ് സ്പ്രെഡ് (object spread), ഓപ്ഷണൽ ചെയിനിംഗ് (optional chaining) അല്ലെങ്കിൽ ഇൻഫേർഡ് any ഉപയോഗം എന്നിവയെക്കുറിച്ചുള്ള കൂടുതൽ പരിശോധനകൾ വന്നേക്കാം. ഡെലിവറി ഷെഡ്യൂളുകളെ ബാധിക്കാതെ അടുത്ത സുരക്ഷാ ഫീച്ചറുകൾ എപ്പോൾ സ്വീകരിക്കണമെന്ന് തീരുമാനിക്കാൻ TypeScript റോഡ്മാപ്പ് ശ്രദ്ധിക്കുന്നത് ടീമുകളെ സഹായിക്കും.

Takeaway: --noPropertyAccessFromIndexSignature പ്രവർത്തനക്ഷമമാക്കുന്നതിലൂടെ, "ഈ പ്രോപ്പർട്ടി ഉറപ്പായും ഉണ്ട്" എന്നും "ഈ പ്രോപ്പർട്ടി ഇല്ലാതിരിക്കാൻ സാധ്യതയുണ്ട്" എന്നും കോഡിൽ വ്യക്തമായി വേർതിരിച്ചറിയാൻ സാധിക്കുന്നു. ഇത് പ്രൊഡക്ഷനിൽ എത്തുന്നതിന് മുമ്പ് തന്നെ ഒരു കൂട്ടം ബഗുകളെ കണ്ടെത്താൻ സഹായിക്കുന്നു. നിശബ്ദമായ ഒരു റൺടൈം പരാജയത്തെ കംപൈൽ-ടൈം എറർ ആക്കി മാറ്റുന്നത്, വിശ്വാസ്യതയിൽ വലിയ സ്വാധീനം ചെലുത്തുന്ന ചെറിയൊരു മാറ്റമാണ്.