டைப்ஸ்கிரிப்ட் கூடுதல் பண்பு சோதனைகள்: உங்கள் ஆப்ஜெக்ட் வகை பாதுகாப்பை வலுப்படுத்துதல்

நவீன மென்பொருள் உருவாக்கத் துறையில், குறிப்பாக ஜாவாஸ்கிரிப்டுடன் பணிபுரியும்போது, உங்கள் குறியீட்டின் ஒருமைப்பாடு மற்றும் கணிக்கக்கூடிய தன்மையை உறுதி செய்வது மிக முக்கியமானது. ஜாவாஸ்கிரிப்ட் மகத்தான நெகிழ்வுத்தன்மையை வழங்கினாலும், சில நேரங்களில் எதிர்பாராத தரவு கட்டமைப்புகள் அல்லது பண்புப் பொருத்தமின்மைகள் காரணமாக இயக்க நேரப் பிழைகளுக்கு வழிவகுக்கும். இந்த இடத்தில்தான் டைப்ஸ்கிரிப்ட் சிறந்து விளங்குகிறது, இது நிலையான வகைப்படுத்தல் திறன்களை வழங்கி, பல பொதுவான பிழைகளை அவை உற்பத்தியில் வெளிப்படுவதற்கு முன்பே கண்டறிகிறது. டைப்ஸ்கிரிப்டின் மிகவும் சக்திவாய்ந்த ஆனால் சில சமயங்களில் தவறாகப் புரிந்துகொள்ளப்பட்ட அம்சங்களில் ஒன்று அதன் கூடுதல் பண்பு சோதனை (excess property check) ஆகும்.

இந்த இடுகை டைப்ஸ்கிரிப்டின் கூடுதல் பண்பு சோதனைகளை ஆழமாக ஆராய்கிறது, அவை என்ன, ஆப்ஜெக்ட் வகை பாதுகாப்பிற்கு அவை ஏன் முக்கியமானவை, மேலும் வலுவான மற்றும் கணிக்கக்கூடிய பயன்பாடுகளை உருவாக்க அவற்றை எவ்வாறு திறம்படப் பயன்படுத்துவது என்பதை விளக்குகிறது. உலகெங்கிலும் உள்ள டெவலப்பர்கள், அவர்களின் பின்னணியைப் பொருட்படுத்தாமல், இந்த முக்கிய டைப்ஸ்கிரிப்ட் பொறிமுறையைப் பயன்படுத்த உதவ, பல்வேறு காட்சிகள், பொதுவான இடர்ப்பாடுகள் மற்றும் சிறந்த நடைமுறைகளை நாங்கள் ஆராய்வோம்.

முக்கியக் கருத்தைப் புரிந்துகொள்ளுதல்: கூடுதல் பண்பு சோதனைகள் என்றால் என்ன?

டைப்ஸ்கிரிப்டின் கூடுதல் பண்பு சோதனை என்பது அடிப்படையில் ஒரு கம்பைலர் பொறிமுறையாகும், இது ஒரு ஆப்ஜெக்ட் லிட்டரலை, அந்த கூடுதல் பண்புகளை வெளிப்படையாக அனுமதிக்காத ஒரு வகையைக் கொண்ட மாறிக்கு நீங்கள் ஒதுக்குவதைத் தடுக்கிறது. எளிமையான சொற்களில், நீங்கள் ஒரு ஆப்ஜெக்ட் லிட்டரலை வரையறுத்து, அதை ஒரு குறிப்பிட்ட வகை வரையறையுடன் (இன்டர்ஃபேஸ் அல்லது டைப் அலியாஸ் போன்றவை) ஒரு மாறிக்கு ஒதுக்க முயற்சித்தால், அந்த லிட்டரல் வரையறுக்கப்பட்ட வகையின் அறிவிக்கப்படாத பண்புகளைக் கொண்டிருந்தால், டைப்ஸ்கிரிப்ட் அதை தொகுக்கும்போது பிழையாகக் குறிக்கும்.

ஒரு அடிப்படை எடுத்துக்காட்டுடன் இதை விளக்குவோம்:

interface User {
  name: string;
  age: number;
}

const newUser: User = {
  name: 'Alice',
  age: 30,
  email: 'alice@example.com' // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'email' என்பது 'User' வகையின் இல்லை.
};

இந்தக் குறியீட்டுத் துண்டில், `name` மற்றும் `age` ஆகிய இரண்டு பண்புகளுடன் `User` என்ற `interface`-ஐ வரையறுக்கிறோம். `email` என்ற கூடுதல் பண்புடன் ஒரு ஆப்ஜெக்ட் லிட்டரலை உருவாக்கி, அதை `User` என வகையிடப்பட்ட ஒரு மாறிக்கு ஒதுக்க முயற்சிக்கும்போது, டைப்ஸ்கிரிப்ட் உடனடியாக பொருத்தமின்மையைக் கண்டறிகிறது. `email` பண்பு ஒரு 'கூடுதல்' பண்பு ஆகும், ஏனெனில் அது `User` இன்டர்ஃபேஸில் வரையறுக்கப்படவில்லை. இந்தச் சோதனை குறிப்பாக நீங்கள் ஒதுக்கீட்டிற்காக ஒரு ஆப்ஜெக்ட் லிட்டரலைப் பயன்படுத்தும்போது செய்யப்படுகிறது.

கூடுதல் பண்பு சோதனைகள் ஏன் முக்கியமானவை?

கூடுதல் பண்பு சோதனைகளின் முக்கியத்துவம், உங்கள் தரவிற்கும் அதன் எதிர்பார்க்கப்படும் கட்டமைப்பிற்கும் இடையே ஒரு ஒப்பந்தத்தை அமல்படுத்தும் திறனில் உள்ளது. அவை பல முக்கிய வழிகளில் ஆப்ஜெக்ட் வகை பாதுகாப்பிற்கு பங்களிக்கின்றன:

• தட்டச்சுப் பிழைகள் மற்றும் எழுத்துப்பிழைகளைத் தடுத்தல்: ஜாவாஸ்கிரிப்டில் பல பிழைகள் எளிய தட்டச்சுப் பிழைகளிலிருந்து எழுகின்றன. நீங்கள் `age`-க்கு ஒரு மதிப்பை ஒதுக்க எண்ணி, தற்செயலாக `agee` என தட்டச்சு செய்தால், ஒரு கூடுதல் பண்பு சோதனை இதை 'எழுத்துப்பிழையுள்ள' பண்பாகக் கண்டறிந்து, `age` `undefined` அல்லது காணாமல் போகக்கூடிய இயக்க நேரப் பிழையைத் தடுக்கும்.
• API ஒப்பந்த இணக்கத்தை உறுதி செய்தல்: குறிப்பிட்ட வடிவங்களைக் கொண்ட ஆப்ஜெக்ட்களை எதிர்பார்க்கும் API-கள், லைப்ரரிகள் அல்லது செயல்பாடுகளுடன் தொடர்பு கொள்ளும்போது, நீங்கள் அந்த எதிர்பார்ப்புகளுக்கு இணங்க தரவை அனுப்புகிறீர்கள் என்பதை கூடுதல் பண்பு சோதனைகள் உறுதி செய்கின்றன. இது பெரிய, பரவலாக்கப்பட்ட குழுக்களில் அல்லது மூன்றாம் தரப்பு சேவைகளுடன் ஒருங்கிணைக்கும்போது மிகவும் மதிப்புமிக்கது.
• குறியீட்டின் வாசிப்புத்திறன் மற்றும் பராமரிப்பை மேம்படுத்துதல்: ஆப்ஜெக்ட்களின் எதிர்பார்க்கப்படும் கட்டமைப்பை தெளிவாக வரையறுப்பதன் மூலம், இந்த சோதனைகள் உங்கள் குறியீட்டை சுய-ஆவணப்படுத்துகின்றன. டெவலப்பர்கள் சிக்கலான தர்க்கத்தின் மூலம் பின்னோக்கிச் செல்லத் தேவையில்லாமல், ஒரு ஆப்ஜெக்ட் என்ன பண்புகளைக் கொண்டிருக்க வேண்டும் என்பதை விரைவாகப் புரிந்து கொள்ள முடியும்.
• இயக்க நேரப் பிழைகளைக் குறைத்தல்: மிகவும் நேரடியான நன்மை இயக்க நேரப் பிழைகளைக் குறைப்பதாகும். உற்பத்தியில் `TypeError` அல்லது `undefined` அணுகல் பிழைகளை எதிர்கொள்வதற்குப் பதிலாக, இந்த சிக்கல்கள் தொகுப்பு நேரப் பிழைகளாக வெளிப்படுத்தப்படுகின்றன, இது அவற்றை சரிசெய்வதை எளிதாகவும் மலிவாகவும் ஆக்குகிறது.
• மறுகட்டமைப்பை எளிதாக்குதல்: நீங்கள் உங்கள் குறியீட்டை மறுகட்டமைத்து, ஒரு இன்டர்ஃபேஸ் அல்லது வகையின் வடிவத்தை மாற்றும்போது, உங்கள் ஆப்ஜெக்ட் லிட்டரல்கள் எங்கு இணங்காமல் போகலாம் என்பதை கூடுதல் பண்பு சோதனைகள் தானாகவே எடுத்துக்காட்டுகின்றன, இது மறுகட்டமைப்பு செயல்முறையை நெறிப்படுத்துகிறது.

கூடுதல் பண்பு சோதனைகள் எப்போது பொருந்தும்?

டைப்ஸ்கிரிப்ட் இந்தச் சோதனைகளை எந்த குறிப்பிட்ட நிபந்தனைகளின் கீழ் செய்கிறது என்பதைப் புரிந்துகொள்வது முக்கியம். அவை முதன்மையாக ஆப்ஜெக்ட் லிட்டரல்களுக்கு ஒரு மாறிக்கு ஒதுக்கப்படும்போது அல்லது ஒரு செயல்பாட்டிற்கு வாதமாக அனுப்பப்படும்போது பயன்படுத்தப்படுகின்றன.

காட்சி 1: ஆப்ஜெக்ட் லிட்டரல்களை மாறிகளுக்கு ஒதுக்குதல்

மேலே உள்ள `User` எடுத்துக்காட்டில் கண்டது போல, கூடுதல் பண்புகளுடன் கூடிய ஒரு ஆப்ஜெக்ட் லிட்டரலை நேரடியாக ஒரு வகையிடப்பட்ட மாறிக்கு ஒதுக்குவது சோதனையைத் தூண்டுகிறது.

காட்சி 2: ஆப்ஜெக்ட் லிட்டரல்களை செயல்பாடுகளுக்கு அனுப்புதல்

ஒரு செயல்பாடு ஒரு குறிப்பிட்ட வகையின் வாதத்தை எதிர்பார்க்கும்போது, நீங்கள் கூடுதல் பண்புகளைக் கொண்ட ஒரு ஆப்ஜெக்ட் லிட்டரலை அனுப்பினால், டைப்ஸ்கிரிப்ட் அதை பிழையாகக் குறிக்கும்.

interface Product {
  id: number;
  name: string;
}

function displayProduct(product: Product): void {
  console.log(`Product ID: ${product.id}, Name: ${product.name}`);
}

displayProduct({
  id: 101,
  name: 'Laptop',
  price: 1200 // பிழை: '{ id: number; name: string; price: number; }' வகையின் வாதம் 'Product' வகையின் அளவுருவிற்கு ஒதுக்கத்தக்கதல்ல.
             // ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'price' என்பது 'Product' வகையின் இல்லை.
});

இங்கே, `displayProduct`-க்கு அனுப்பப்பட்ட ஆப்ஜெக்ட் லிட்டரலில் உள்ள `price` பண்பு ஒரு கூடுதல் பண்பு ஆகும், ஏனெனில் `Product` இன்டர்ஃபேஸ் அதை வரையறுக்கவில்லை.

கூடுதல் பண்பு சோதனைகள் *எப்போது* பொருந்தாது?

குழப்பத்தைத் தவிர்க்கவும், மாற்று உத்திகள் எப்போது தேவைப்படலாம் என்பதை அறியவும் இந்தச் சோதனைகள் எப்போது தவிர்க்கப்படுகின்றன என்பதைப் புரிந்துகொள்வது சமமாக முக்கியம்.

1. ஒதுக்கீட்டிற்கு ஆப்ஜெக்ட் லிட்டரல்களைப் பயன்படுத்தாதபோது

நீங்கள் ஒரு ஆப்ஜெக்ட் லிட்டரல் அல்லாத ஒரு ஆப்ஜெக்டை ஒதுக்கினால் (எ.கா., ஏற்கனவே ஒரு ஆப்ஜெக்டைக் கொண்டிருக்கும் ஒரு மாறி), கூடுதல் பண்பு சோதனை பொதுவாக தவிர்க்கப்படுகிறது.

interface Config {
  timeout: number;
}

function setupConfig(config: Config) {
  console.log(`Timeout set to: ${config.timeout}`);
}

const userProvidedConfig = {
  timeout: 5000,
  retries: 3 // இந்த 'retries' பண்பு 'Config'-இன் படி ஒரு கூடுதல் பண்பு ஆகும்
};

setupConfig(userProvidedConfig); // பிழை இல்லை!

// userProvidedConfig ஒரு கூடுதல் பண்பைக் கொண்டிருந்தாலும், சோதனை தவிர்க்கப்படுகிறது
// ஏனெனில் இது நேரடியாக அனுப்பப்படும் ஒரு ஆப்ஜெக்ட் லிட்டரல் அல்ல.
// டைப்ஸ்கிரிப்ட் userProvidedConfig-இன் வகையைச் சரிபார்க்கிறது.
// userProvidedConfig ஆனது Config வகையுடன் அறிவிக்கப்பட்டிருந்தால், ஒரு பிழை முன்பே ஏற்பட்டிருக்கும்.
// இருப்பினும், 'any' அல்லது ஒரு பரந்த வகையாக அறிவிக்கப்பட்டால், பிழை தள்ளிப்போடப்படுகிறது.

// தவிர்ப்பைக் காட்ட ஒரு துல்லியமான வழி:
let anotherConfig;

if (Math.random() > 0.5) {
  anotherConfig = {
    timeout: 1000,
    host: 'localhost' // கூடுதல் பண்பு
  };
} else {
  anotherConfig = {
    timeout: 2000,
    port: 8080 // கூடுதல் பண்பு
  };
}

setupConfig(anotherConfig as Config); // வகை உறுதிப்படுத்தல் மற்றும் தவிர்ப்பு காரணமாக பிழை இல்லை

// முக்கியமானது என்னவென்றால், setupConfig-க்கு ஒதுக்கப்படும் நேரத்தில் 'anotherConfig' ஒரு ஆப்ஜெக்ட் லிட்டரல் அல்ல.
// நம்மிடம் 'Config' என வகையிடப்பட்ட ஒரு இடைநிலை மாறி இருந்திருந்தால், ஆரம்ப ஒதுக்கீடு தோல்வியடைந்திருக்கும்.

// இடைநிலை மாறிக்கான எடுத்துக்காட்டு:
let intermediateConfig: Config;

intermediateConfig = {
  timeout: 3000,
  logging: true // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'logging' என்பது 'Config' வகையின் இல்லை.
};

முதல் `setupConfig(userProvidedConfig)` எடுத்துக்காட்டில், `userProvidedConfig` என்பது ஒரு ஆப்ஜெக்டைக் கொண்டிருக்கும் மாறி ஆகும். டைப்ஸ்கிரிப்ட் `userProvidedConfig` முழுவதுமாக `Config` வகைக்கு இணங்குகிறதா என்று சரிபார்க்கிறது. இது `userProvidedConfig`க்கு கடுமையான ஆப்ஜெக்ட் லிட்டரல் சோதனையைப் பயன்படுத்துவதில்லை. `userProvidedConfig` `Config` உடன் பொருந்தாத ஒரு வகையுடன் அறிவிக்கப்பட்டிருந்தால், அதன் அறிவிப்பு அல்லது ஒதுக்கீட்டின் போது ஒரு பிழை ஏற்படும். ஆப்ஜெக்ட் ஏற்கனவே உருவாக்கப்பட்டு, செயல்பாட்டிற்கு அனுப்பப்படுவதற்கு முன்பு ஒரு மாறிக்கு ஒதுக்கப்பட்டதால் இந்தத் தவிர்ப்பு நிகழ்கிறது.

2. வகை உறுதிப்படுத்தல்கள்

வகை உறுதிப்படுத்தல்களைப் பயன்படுத்தி கூடுதல் பண்பு சோதனைகளை நீங்கள் தவிர்க்கலாம், இருப்பினும் இது டைப்ஸ்கிரிப்டின் பாதுகாப்பு உத்தரவாதங்களை மீறுவதால் எச்சரிக்கையுடன் செய்யப்பட வேண்டும்.

interface Settings {
  theme: 'dark' | 'light';
}

const mySettings = {
  theme: 'dark',
  fontSize: 14 // கூடுதல் பண்பு
} as Settings;

// வகை உறுதிப்படுத்தல் காரணமாக இங்கே பிழை இல்லை.
// நாம் டைப்ஸ்கிரிப்டிடம் கூறுகிறோம்: "என்னை நம்பு, இந்த ஆப்ஜெக்ட் Settings-க்கு இணங்குகிறது."
console.log(mySettings.theme);
// console.log(mySettings.fontSize); // fontSize உண்மையில் அங்கு இல்லையென்றால் இது ஒரு இயக்க நேரப் பிழையை ஏற்படுத்தும்.

3. வகை வரையறைகளில் இன்டெக்ஸ் சிக்னேச்சர்கள் அல்லது ஸ்ப்ரெட் சிண்டாக்ஸைப் பயன்படுத்துதல்

உங்கள் இன்டர்ஃபேஸ் அல்லது டைப் அலியாஸ் தன்னிச்சையான பண்புகளை வெளிப்படையாக அனுமதித்தால், கூடுதல் பண்பு சோதனைகள் பொருந்தாது.

இன்டெக்ஸ் சிக்னேச்சர்களைப் பயன்படுத்துதல்:

interface FlexibleObject {
  id: number;
  [key: string]: any; // எந்தவொரு மதிப்புடன் எந்தவொரு ஸ்டிரிங் கீயையும் அனுமதிக்கிறது
}

const flexibleItem: FlexibleObject = {
  id: 1,
  name: 'Widget',
  version: '1.0.0'
};

// இன்டெக்ஸ் சிக்னேச்சரால் 'name' மற்றும் 'version' அனுமதிக்கப்படுவதால் பிழை இல்லை.
console.log(flexibleItem.name);

வகை வரையறைகளில் ஸ்ப்ரெட் சிண்டாக்ஸைப் பயன்படுத்துதல் (சோதனைகளை நேரடியாகத் தவிர்ப்பதற்கு குறைவாகப் பயன்படுத்தப்படுகிறது, இணக்கமான வகைகளை வரையறுக்க அதிகம் பயன்படுத்தப்படுகிறது):

இது ஒரு நேரடித் தவிர்ப்பு இல்லை என்றாலும், ஸ்ப்ரெட்டிங் ஏற்கனவே உள்ள பண்புகளை உள்ளடக்கிய புதிய ஆப்ஜெக்ட்களை உருவாக்க அனுமதிக்கிறது, மேலும் புதிதாக உருவாக்கப்பட்ட லிட்டரலுக்கு சோதனை பொருந்தும்.

4. இணைப்பதற்காக `Object.assign()` அல்லது ஸ்ப்ரெட் சிண்டாக்ஸைப் பயன்படுத்துதல்

நீங்கள் ஆப்ஜெக்ட்களை இணைக்க `Object.assign()` அல்லது ஸ்ப்ரெட் சிண்டாக்ஸ் (`...`) பயன்படுத்தும்போது, கூடுதல் பண்பு சோதனை வித்தியாசமாக செயல்படுகிறது. இது உருவாக்கப்படும் விளைவான ஆப்ஜெக்ட் லிட்டரலுக்குப் பொருந்தும்.

interface BaseConfig {
  host: string;
}

interface ExtendedConfig extends BaseConfig {
  port: number;
}

const defaultConfig: BaseConfig = {
  host: 'localhost'
};

const userConfig = {
  port: 8080,
  timeout: 5000 // BaseConfig-ஐப் பொறுத்து கூடுதல் பண்பு, ஆனால் இணைக்கப்பட்ட வகையால் எதிர்பார்க்கப்படுகிறது
};

// ExtendedConfig-க்கு இணங்கும் ஒரு புதிய ஆப்ஜெக்ட் லிட்டரலுக்குள் ஸ்ப்ரெட் செய்தல்
const finalConfig: ExtendedConfig = {
  ...defaultConfig,
  ...userConfig
};

// இது பொதுவாக சரி, ஏனெனில் 'finalConfig' ஆனது 'ExtendedConfig' என அறிவிக்கப்பட்டுள்ளது
// மற்றும் பண்புகள் பொருந்துகின்றன. சோதனை 'finalConfig'-இன் வகையின் மீது உள்ளது.

// இது தோல்வியடையும் ஒரு காட்சியைக் கருத்தில் கொள்வோம்:

interface SmallConfig {
  key: string;
}

const data1 = { key: 'abc', value: 123 }; // 'value' இங்கே கூடுதலாக உள்ளது
const data2 = { key: 'xyz', status: 'active' }; // 'status' இங்கே கூடுதலாக உள்ளது

// கூடுதல் பண்புகளை ஏற்காத ஒரு வகைக்கு ஒதுக்க முயற்சித்தல்

// const combined: SmallConfig = {
//   ...data1, // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'value' என்பது 'SmallConfig' வகையின் இல்லை.
//   ...data2  // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'status' என்பது 'SmallConfig' வகையின் இல்லை.
// };

// ஸ்ப்ரெட் சிண்டாக்ஸால் உருவாக்கப்பட்ட ஆப்ஜெக்ட் லிட்டரல் காரணமாக பிழை ஏற்படுகிறது
// 'SmallConfig'-ல் இல்லாத பண்புகளை ('value', 'status') கொண்டுள்ளது.

// நாம் ஒரு பரந்த வகையுடன் ஒரு இடைநிலை மாறியை உருவாக்கினால்:

const temp: any = {
  ...data1,
  ...data2
};

// பின்னர் SmallConfig-க்கு ஒதுக்கினால், ஆரம்ப லிட்டரல் உருவாக்கத்தின்போது கூடுதல் பண்பு சோதனை தவிர்க்கப்படுகிறது,
// ஆனால் temp-இன் வகை மிகவும் கண்டிப்பாக அனுமானிக்கப்பட்டால், ஒதுக்கீட்டின் மீதான வகை சோதனை இன்னும் ஏற்படலாம்.
// இருப்பினும், temp 'any' ஆக இருந்தால், 'combined'-க்கு ஒதுக்கப்படும் வரை எந்த சோதனையும் நடக்காது.

// கூடுதல் பண்பு சோதனைகளுடன் ஸ்ப்ரெட் பற்றிய புரிதலைச் செம்மைப்படுத்துவோம்:
// ஸ்ப்ரெட் சிண்டாக்ஸால் உருவாக்கப்பட்ட ஆப்ஜெக்ட் லிட்டரல் ஒதுக்கப்படும்போது சோதனை நிகழ்கிறது
// ஒரு மாறிக்கு அல்லது மிகவும் குறிப்பிட்ட வகையை எதிர்பார்க்கும் ஒரு செயல்பாட்டிற்கு அனுப்பப்படும்போது.

interface SpecificShape { 
  id: number;
}

const objA = { id: 1, extra1: 'hello' };
const objB = { id: 2, extra2: 'world' };

// SpecificShape ஆனது 'extra1' அல்லது 'extra2'-ஐ அனுமதிக்கவில்லை என்றால் இது தோல்வியடையும்:
// const merged: SpecificShape = {
//   ...objA,
//   ...objB
// };

// இது தோல்வியடைவதற்கான காரணம், ஸ்ப்ரெட் சிண்டாக்ஸ் திறம்பட ஒரு புதிய ஆப்ஜெக்ட் லிட்டரலை உருவாக்குகிறது.
// objA மற்றும் objB ஒரே கீகளை கொண்டிருந்தால், பிந்தையது வெல்லும். கம்பைலர்
// இந்த விளைவான லிட்டரலைப் பார்த்து அதை 'SpecificShape'-க்கு எதிராகச் சரிபார்க்கிறது.

// இதை வேலை செய்ய வைக்க, உங்களுக்கு ஒரு இடைநிலை படி அல்லது இன்னும் அனுமதிக்கக்கூடிய வகை தேவைப்படலாம்:

const tempObj = {
  ...objA,
  ...objB
};

// இப்போது, tempObj ஆனது SpecificShape-ல் இல்லாத பண்புகளைக் கொண்டிருந்தால், ஒதுக்கீடு தோல்வியடையும்:
// const mergedCorrected: SpecificShape = tempObj; // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும்...

// முக்கியமானது என்னவென்றால், கம்பைலர் உருவாக்கப்படும் ஆப்ஜெக்ட் லிட்டரலின் வடிவத்தை பகுப்பாய்வு செய்கிறது.
// அந்த லிட்டரல் இலக்கு வகையின் வரையறுக்கப்படாத பண்புகளைக் கொண்டிருந்தால், அது ஒரு பிழை.

// கூடுதல் பண்பு சோதனைகளுடன் ஸ்ப்ரெட் சிண்டாக்ஸிற்கான வழக்கமான பயன்பாட்டு வழக்கு:

interface UserProfile {
  userId: string;
  username: string;
}

interface AdminProfile extends UserProfile {
  adminLevel: number;
}

const baseUserData: UserProfile = {
  userId: 'user-123',
  username: 'coder'
};

const adminData = {
  adminLevel: 5,
  lastLogin: '2023-10-27'
};

// இங்குதான் கூடுதல் பண்பு சோதனை பொருத்தமானது:
// const adminProfile: AdminProfile = {
//   ...baseUserData,
//   ...adminData // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'lastLogin' என்பது 'AdminProfile' வகையின் இல்லை.
// };

// ஸ்ப்ரெட் மூலம் உருவாக்கப்பட்ட ஆப்ஜெக்ட் லிட்டரலில் 'lastLogin' உள்ளது, இது 'AdminProfile'-ல் இல்லை.
// இதை சரிசெய்ய, 'adminData' ஆனது AdminProfile-க்கு இணங்க வேண்டும் அல்லது கூடுதல் பண்பு கையாளப்பட வேண்டும்.

// சரிசெய்யப்பட்ட அணுகுமுறை:
const validAdminData = {
  adminLevel: 5
};

const adminProfileCorrect: AdminProfile = {
  ...baseUserData,
  ...validAdminData
};

console.log(adminProfileCorrect.userId);
console.log(adminProfileCorrect.adminLevel);

கூடுதல் பண்பு சோதனையானது ஸ்ப்ரெட் சிண்டாக்ஸால் உருவாக்கப்பட்ட விளைவான ஆப்ஜெக்ட் லிட்டரலுக்கு பொருந்தும். இந்த விளைவான லிட்டரல் இலக்கு வகையின் அறிவிக்கப்படாத பண்புகளைக் கொண்டிருந்தால், டைப்ஸ்கிரிப்ட் ஒரு பிழையைப் புகாரளிக்கும்.

கூடுதல் பண்புகளைக் கையாள்வதற்கான உத்திகள்

கூடுதல் பண்பு சோதனைகள் நன்மை பயக்கும் என்றாலும், நீங்கள் சேர்க்க விரும்பும் அல்லது வித்தியாசமாகக் கையாள விரும்பும் கூடுதல் பண்புகளைக் கொண்டிருக்கக்கூடிய முறையான காட்சிகள் உள்ளன. இங்கே பொதுவான உத்திகள்:

1. டைப் அலியாஸ்கள் அல்லது இன்டர்ஃபேஸ்களுடன் ரெஸ்ட் பண்புகள்

வெளிப்படையாக வரையறுக்கப்படாத மீதமுள்ள பண்புகளைப் பிடிக்க, டைப் அலியாஸ்கள் அல்லது இன்டர்ஃபேஸ்களுக்குள் ரெஸ்ட் அளவுரு சிண்டாக்ஸை (`...rest`) பயன்படுத்தலாம். இந்த கூடுதல் பண்புகளை ஏற்றுக்கொண்டு சேகரிக்க இது ஒரு நேர்த்தியான வழியாகும்.

interface UserProfile {
  id: number;
  name: string;
}

interface UserWithMetadata extends UserProfile {
  metadata: {
    [key: string]: any;
  };
}

// அல்லது பொதுவாக ஒரு டைப் அலியாஸ் மற்றும் ரெஸ்ட் சிண்டாக்ஸுடன்:
type UserProfileWithMetadata = UserProfile & {
  [key: string]: any;
};

const user1: UserProfileWithMetadata = {
  id: 1,
  name: 'Bob',
  email: 'bob@example.com',
  isAdmin: true
};

// பிழை இல்லை, ஏனெனில் 'email' மற்றும் 'isAdmin' ஆகியவை UserProfileWithMetadata-ல் உள்ள இன்டெக்ஸ் சிக்னேச்சரால் பிடிக்கப்படுகின்றன.
console.log(user1.email);
console.log(user1.isAdmin);

// ஒரு வகை வரையறையில் ரெஸ்ட் அளவுருக்களைப் பயன்படுத்தும் மற்றொரு வழி:
interface ConfigWithRest {
  apiUrl: string;
  timeout?: number;
  // மற்ற அனைத்து பண்புகளையும் 'extraConfig'-க்குள் பிடிக்கவும்
  [key: string]: any;
}

const appConfig: ConfigWithRest = {
  apiUrl: 'https://api.example.com',
  timeout: 5000,
  featureFlags: {
    newUI: true,
    betaFeatures: false
  }
};

console.log(appConfig.featureFlags);

`[key: string]: any;` அல்லது அதுபோன்ற இன்டெக்ஸ் சிக்னேச்சர்களைப் பயன்படுத்துவது, தன்னிச்சையான கூடுதல் பண்புகளைக் கையாள்வதற்கான வழக்கமான வழியாகும்.

2. ரெஸ்ட் சிண்டாக்ஸுடன் டீஸ்ட்ரக்ச்சரிங்

நீங்கள் ஒரு ஆப்ஜெக்டைப் பெற்று, குறிப்பிட்ட பண்புகளைப் பிரித்தெடுத்து மீதமுள்ளவற்றை வைத்திருக்க வேண்டியிருக்கும் போது, ரெஸ்ட் சிண்டாக்ஸுடன் டீஸ்ட்ரக்ச்சரிங் செய்வது விலைமதிப்பற்றது.

interface Employee {
  employeeId: string;
  department: string;
}

function processEmployeeData(data: Employee & { [key: string]: any }) {
  const { employeeId, department, ...otherDetails } = data;

  console.log(`Employee ID: ${employeeId}`);
  console.log(`Department: ${department}`);
  console.log('Other details:', otherDetails);
  // otherDetails வெளிப்படையாக டீஸ்ட்ரக்ச்சர் செய்யப்படாத எந்தவொரு பண்புகளையும் கொண்டிருக்கும்,
  // 'salary', 'startDate' போன்றவை.
}

const employeeInfo = {
  employeeId: 'emp-789',
  department: 'Engineering',
  salary: 90000,
  startDate: '2022-01-15'
};

processEmployeeData(employeeInfo);

// employeeInfo ஆரம்பத்தில் ஒரு கூடுதல் பண்பைக் கொண்டிருந்தாலும், கூடுதல் பண்பு சோதனை
// செயல்பாட்டின் சிக்னேச்சர் அதை ஏற்றுக்கொண்டால் (எ.கா., ஒரு இன்டெக்ஸ் சிக்னேச்சரைப் பயன்படுத்தி) தவிர்க்கப்படுகிறது.
// processEmployeeData ஆனது கண்டிப்பாக 'Employee' என வகையிடப்பட்டு, employeeInfo-வில் 'salary' இருந்திருந்தால்,
// employeeInfo நேரடியாக அனுப்பப்பட்ட ஒரு ஆப்ஜெக்ட் லிட்டரலாக இருந்தால் ஒரு பிழை ஏற்பட்டிருக்கும்.
// ஆனால் இங்கே, employeeInfo ஒரு மாறி, மற்றும் செயல்பாட்டின் வகை கூடுதல் பண்புகளைக் கையாளுகிறது.

3. அனைத்து பண்புகளையும் வெளிப்படையாக வரையறுத்தல் (தெரிந்தால்)

சாத்தியமான கூடுதல் பண்புகளை நீங்கள் அறிந்திருந்தால், அவற்றை உங்கள் இன்டர்ஃபேஸ் அல்லது டைப் அலியாஸில் சேர்ப்பது சிறந்த அணுகுமுறையாகும். இது அதிகபட்ச வகை பாதுகாப்பை வழங்குகிறது.

interface UserProfile {
  id: number;
  name: string;
  email?: string; // விருப்பத்தேர்வு email
}

const userWithEmail: UserProfile = {
  id: 2,
  name: 'Charlie',
  email: 'charlie@example.com'
};

const userWithoutEmail: UserProfile = {
  id: 3,
  name: 'David'
};

// UserProfile-ல் இல்லாத ஒரு பண்பைச் சேர்க்க முயற்சித்தால்:
// const userWithExtra: UserProfile = {
//   id: 4,
//   name: 'Eve',
//   phoneNumber: '555-1234'
// }; // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'phoneNumber' என்பது 'UserProfile' வகையின் இல்லை.

4. வகை உறுதிப்படுத்தல்களுக்கு `as`-ஐப் பயன்படுத்துதல் (எச்சரிக்கையுடன்)

முன்னர் காட்டியபடி, வகை உறுதிப்படுத்தல்கள் கூடுதல் பண்பு சோதனைகளை அடக்க முடியும். இதை மிகக் குறைவாகவும், ஆப்ஜெக்டின் வடிவம் குறித்து நீங்கள் முற்றிலும் உறுதியாக இருக்கும்போது மட்டுமே பயன்படுத்தவும்.

interface ProductConfig {
  id: string;
  version: string;
}

// இது ஒரு வெளிப்புற மூலத்திலிருந்து அல்லது குறைவான கண்டிப்பான மாட்யூலிலிருந்து வருவதாக கற்பனை செய்து கொள்ளுங்கள்
const externalConfig = {
  id: 'prod-abc',
  version: '1.2',
  debugMode: true // கூடுதல் பண்பு
};

// 'externalConfig' எப்போதுமே 'id' மற்றும் 'version'-ஐக் கொண்டிருக்கும் என்று உங்களுக்குத் தெரிந்தால், அதை ProductConfig-ஆகக் கருத விரும்பினால்:
const productConfig = externalConfig as ProductConfig;

// இந்த உறுதிப்படுத்தல் `externalConfig` மீதான கூடுதல் பண்பு சோதனையைத் தவிர்க்கிறது.
// இருப்பினும், நீங்கள் ஒரு ஆப்ஜெக்ட் லிட்டரலை நேரடியாக அனுப்பினால்:

// const productConfigLiteral: ProductConfig = {
//   id: 'prod-xyz',
//   version: '2.0',
//   debugMode: false
// }; // பிழை: ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'debugMode' என்பது 'ProductConfig' வகையின் இல்லை.

5. டைப் கார்டுகள் (Type Guards)

மிகவும் சிக்கலான காட்சிகளுக்கு, டைப் கார்டுகள் வகைகளைக் குறுக்கவும், நிபந்தனையின் அடிப்படையில் பண்புகளைக் கையாளவும் உதவும்.

interface Shape {
  kind: 'circle' | 'square';
}

interface Circle extends Shape {
  kind: 'circle';
  radius: number;
}

interface Square extends Shape {
  kind: 'square';
  sideLength: number;
}

function calculateArea(shape: Shape) {
  if (shape.kind === 'circle') {
    // டைப்ஸ்கிரிப்டிற்கு இங்கே 'shape' ஒரு Circle என்று தெரியும்
    console.log(Math.PI * shape.radius ** 2);
  } else if (shape.kind === 'square') {
    // டைப்ஸ்கிரிப்டிற்கு இங்கே 'shape' ஒரு Square என்று தெரியும்
    console.log(shape.sideLength ** 2);
  }
}

const circleData = {
  kind: 'circle' as const, // லிட்டரல் வகை அனுமானத்திற்கு 'as const' பயன்படுத்துதல்
  radius: 10,
  color: 'red' // கூடுதல் பண்பு
};

// calculateArea-க்கு அனுப்பப்படும்போது, செயல்பாட்டின் சிக்னேச்சர் 'Shape'-ஐ எதிர்பார்க்கிறது.
// செயல்பாடு தானாகவே 'kind'-ஐச் சரியாக அணுகும்.
// calculateArea நேரடியாக 'Circle'-ஐ எதிர்பார்த்து, circleData-வைப் பெற்றிருந்தால்
// ஒரு ஆப்ஜெக்ட் லிட்டரலாக, 'color' ஒரு பிரச்சனையாக இருந்திருக்கும்.

// ஒரு குறிப்பிட்ட துணை வகையை எதிர்பார்க்கும் செயல்பாட்டுடன் கூடுதல் பண்பு சோதனையை விளக்குவோம்:

function processCircle(circle: Circle) {
  console.log(`Processing circle with radius: ${circle.radius}`);
}

// processCircle(circleData); // பிழை: '{ kind: "circle"; radius: number; color: string; }' வகையின் வாதம் 'Circle' வகையின் அளவுருவிற்கு ஒதுக்கத்தக்கதல்ல.
                         // ஆப்ஜெக்ட் லிட்டரல் அறியப்பட்ட பண்புகளை மட்டுமே குறிப்பிட முடியும், மேலும் 'color' என்பது 'Circle' வகையின் இல்லை.

// இதை சரிசெய்ய, நீங்கள் டீஸ்ட்ரக்ச்சர் செய்யலாம் அல்லது circleData-க்கு இன்னும் அனுமதிக்கக்கூடிய வகையைப் பயன்படுத்தலாம்:

const { color, ...circleDataWithoutColor } = circleData;
processCircle(circleDataWithoutColor);

// அல்லது circleData-வை ஒரு பரந்த வகையை உள்ளடக்குமாறு வரையறுக்கவும்:

const circleDataWithExtras: Circle & { [key: string]: any } = {
  kind: 'circle',
  radius: 15,
  color: 'blue'
};
processCircle(circleDataWithExtras); // இப்போது இது வேலை செய்கிறது.

பொதுவான இடர்ப்பாடுகளும் அவற்றைத் தவிர்ப்பதற்கான வழிகளும்

அனுபவம் வாய்ந்த டெவலப்பர்கள் கூட சில நேரங்களில் கூடுதல் பண்பு சோதனைகளால் திணறடிக்கப்படலாம். இங்கே சில பொதுவான இடர்ப்பாடுகள்:

• ஆப்ஜெக்ட் லிட்டரல்களை மாறிகளுடன் குழப்பிக் கொள்ளுதல்: சோதனையானது ஆப்ஜெக்ட் லிட்டரல்களுக்கு மட்டுமே உரியது என்பதை உணராதது மிகவும் அடிக்கடி நிகழும் தவறாகும். நீங்கள் முதலில் ஒரு மாறிக்கு ஒதுக்கி, பின்னர் அந்த மாறியை அனுப்பினால், சோதனை பெரும்பாலும் தவிர்க்கப்படுகிறது. ஒதுக்கீட்டின் சூழலை எப்போதும் நினைவில் கொள்ளுங்கள்.
• வகை உறுதிப்படுத்தல்களை (`as`) அதிகமாகப் பயன்படுத்துதல்: பயனுள்ளதாக இருந்தாலும், வகை உறுதிப்படுத்தல்களை அதிகமாகப் பயன்படுத்துவது டைப்ஸ்கிரிப்டின் நன்மைகளை நீக்குகிறது. சோதனைகளைத் தவிர்ப்பதற்காக நீங்கள் அடிக்கடி `as`-ஐப் பயன்படுத்துவதைக் கண்டால், உங்கள் வகைகள் அல்லது நீங்கள் ஆப்ஜெக்ட்களை உருவாக்கும் விதம் செம்மைப்படுத்தப்பட வேண்டும் என்பதைக் குறிக்கலாம்.
• எதிர்பார்க்கப்படும் அனைத்து பண்புகளையும் வரையறுக்காதது: பல சாத்தியமான பண்புகளுடன் ஆப்ஜெக்ட்களைத் தரும் லைப்ரரிகள் அல்லது API-களுடன் நீங்கள் பணிபுரியும்போது, உங்கள் வகைகள் உங்களுக்குத் தேவையானவற்றைப் பிடிக்கின்றன என்பதை உறுதிசெய்து, மீதமுள்ளவற்றிற்கு இன்டெக்ஸ் சிக்னேச்சர்கள் அல்லது ரெஸ்ட் பண்புகளைப் பயன்படுத்தவும்.
• ஸ்ப்ரெட் சிண்டாக்ஸை தவறாகப் பயன்படுத்துதல்: ஸ்ப்ரெட்டிங் ஒரு புதிய ஆப்ஜெக்ட் லிட்டரலை உருவாக்குகிறது என்பதைப் புரிந்து கொள்ளுங்கள். இந்த புதிய லிட்டரல் இலக்கு வகையைப் பொறுத்து கூடுதல் பண்புகளைக் கொண்டிருந்தால், சோதனை பொருந்தும்.

உலகளாவிய கருத்தாய்வுகள் மற்றும் சிறந்த நடைமுறைகள்

உலகளாவிய, பன்முகத்தன்மை வாய்ந்த மேம்பாட்டு சூழலில் பணிபுரியும்போது, வகை பாதுகாப்பைச் சுற்றி சீரான நடைமுறைகளைக் கடைப்பிடிப்பது முக்கியமானது:

• வகை வரையறைகளைத் தரப்படுத்துங்கள்: உங்கள் குழுவிற்கு இன்டர்ஃபேஸ்கள் மற்றும் டைப் அலியாஸ்களை எவ்வாறு வரையறுப்பது என்பது பற்றிய தெளிவான புரிதல் இருப்பதை உறுதிசெய்யவும், குறிப்பாக வெளிப்புற தரவு அல்லது சிக்கலான ஆப்ஜெக்ட் கட்டமைப்புகளைக் கையாளும்போது.
• மரபுகளை ஆவணப்படுத்துங்கள்: இன்டெக்ஸ் சிக்னேச்சர்கள், ரெஸ்ட் பண்புகள் அல்லது குறிப்பிட்ட பயன்பாட்டு செயல்பாடுகள் மூலம் கூடுதல் பண்புகளைக் கையாள்வதற்கான உங்கள் குழுவின் மரபுகளை ஆவணப்படுத்துங்கள்.
• புதிய குழு உறுப்பினர்களுக்குக் கல்வி கற்பியுங்கள்: டைப்ஸ்கிரிப்ட் அல்லது உங்கள் திட்டத்திற்குப் புதிய டெவலப்பர்கள் கூடுதல் பண்பு சோதனைகளின் கருத்தையும் முக்கியத்துவத்தையும் புரிந்துகொள்வதை உறுதிசெய்யவும்.
• வாசிப்புத்திறனுக்கு முன்னுரிமை கொடுங்கள்: முடிந்தவரை வெளிப்படையான வகைகளை இலக்காகக் கொள்ளுங்கள். ஒரு ஆப்ஜெக்ட் ஒரு நிலையான பண்புகளைக் கொண்டிருக்க வேண்டும் என்றால், தரவின் தன்மை உண்மையிலேயே தேவைப்படாவிட்டால், இன்டெக்ஸ் சிக்னேச்சர்களை நம்புவதை விட அவற்றை வெளிப்படையாக வரையறுக்கவும்.
• லின்டர்கள் மற்றும் ஃபார்மெட்டர்களைப் பயன்படுத்துங்கள்: டைப்ஸ்கிரிப்ட் ESLint செருகுநிரலுடன் கூடிய ESLint போன்ற கருவிகள் குறியீட்டுத் தரங்களைச் செயல்படுத்தவும், ஆப்ஜெக்ட் வடிவங்கள் தொடர்பான சாத்தியமான சிக்கல்களைக் கண்டறியவும் உள்ளமைக்கப்படலாம்.

முடிவுரை

டைப்ஸ்கிரிப்டின் கூடுதல் பண்பு சோதனைகள், வலுவான ஆப்ஜெக்ட் வகை பாதுகாப்பை வழங்கும் அதன் திறனின் ஒரு மூலக்கல்லாகும். இந்தச் சோதனைகள் எப்போது, ஏன் நிகழ்கின்றன என்பதைப் புரிந்துகொள்வதன் மூலம், டெவலப்பர்கள் மிகவும் கணிக்கக்கூடிய, குறைவான பிழையுள்ள குறியீட்டை எழுத முடியும்.

உலகெங்கிலும் உள்ள டெவலப்பர்களுக்கு, இந்த அம்சத்தை ஏற்றுக்கொள்வது என்பது இயக்க நேரத்தில் குறைவான ஆச்சரியங்கள், எளிதான ஒத்துழைப்பு மற்றும் பராமரிக்கக்கூடிய குறியீட்டுத் தளங்கள் என்பதாகும். நீங்கள் ஒரு சிறிய பயன்பாடு அல்லது ஒரு பெரிய அளவிலான நிறுவன பயன்பாட்டை உருவாக்கினாலும், கூடுதல் பண்பு சோதனைகளில் தேர்ச்சி பெறுவது உங்கள் ஜாவாஸ்கிரிப்ட் திட்டங்களின் தரம் மற்றும் நம்பகத்தன்மையை சந்தேகத்திற்கு இடமின்றி உயர்த்தும்.

முக்கிய குறிப்புகள்:

• கூடுதல் பண்பு சோதனைகள் மாறிகளுக்கு ஒதுக்கப்படும் அல்லது குறிப்பிட்ட வகைகளைக் கொண்ட செயல்பாடுகளுக்கு அனுப்பப்படும் ஆப்ஜெக்ட் லிட்டரல்களுக்கு பொருந்தும்.
• அவை தட்டச்சுப் பிழைகளைக் கண்டறிகின்றன, API ஒப்பந்தங்களை அமல்படுத்துகின்றன, மற்றும் இயக்க நேரப் பிழைகளைக் குறைக்கின்றன.
• லிட்டரல் அல்லாத ஒதுக்கீடுகள், வகை உறுதிப்படுத்தல்கள் மற்றும் இன்டெக்ஸ் சிக்னேச்சர்களைக் கொண்ட வகைகளுக்கு சோதனைகள் தவிர்க்கப்படுகின்றன.
• முறையான கூடுதல் பண்புகளை நேர்த்தியாகக் கையாள ரெஸ்ட் பண்புகள் (`[key: string]: any;`) அல்லது டீஸ்ட்ரக்ச்சரிங்கைப் பயன்படுத்தவும்.
• இந்தச் சோதனைகளின் சீரான பயன்பாடு மற்றும் புரிதல் உலகளாவிய மேம்பாட்டுக் குழுக்களிடையே வலுவான வகை பாதுகாப்பை வளர்க்கிறது.

இந்தக் கொள்கைகளை உணர்வுபூர்வமாகப் பயன்படுத்துவதன் மூலம், உங்கள் டைப்ஸ்கிரிப்ட் குறியீட்டின் பாதுகாப்பு மற்றும் பராமரிப்புத்தன்மையை கணிசமாக மேம்படுத்தலாம், இது மிகவும் வெற்றிகரமான மென்பொருள் மேம்பாட்டு விளைவுகளுக்கு வழிவகுக்கும்.