M

MLOG

فارسی

بررسی خصوصیات اضافی تایپ‌اسکریپت را برای جلوگیری از خطاهای زمان اجرا و تقویت ایمنی نوعی اشیاء، جهت ساخت برنامه‌های جاوااسکریپت قوی و قابل پیش‌بینی، فرا بگیرید.

بررسی خصوصیات اضافی در تایپ‌اسکریپت: تقویت ایمنی نوعی اشیاء

در حوزه توسعه نرم‌افزار مدرن، به ویژه با جاوااسکریپت، تضمین یکپارچگی و قابل پیش‌بینی بودن کد شما از اهمیت بالایی برخوردار است. در حالی که جاوااسکریپت انعطاف‌پذیری فوق‌العاده‌ای ارائه می‌دهد، گاهی اوقات می‌تواند به دلیل ساختارهای داده‌ای غیرمنتظره یا عدم تطابق خصوصیات، منجر به خطاهای زمان اجرا شود. اینجاست که تایپ‌اسکریپت می‌درخشد و با ارائه قابلیت‌های تایپ استاتیک، بسیاری از خطاهای رایج را قبل از بروز در محیط پروداکشن شناسایی می‌کند. یکی از قدرتمندترین و در عین حال گاهی اوقات اشتباه درک شده‌ترین ویژگی‌های تایپ‌اسکریپت، بررسی خصوصیات اضافی (excess property check) آن است.

این پست به طور عمیق به بررسی خصوصیات اضافی تایپ‌اسکریپت می‌پردازد و توضیح می‌دهد که آن‌ها چه هستند، چرا برای ایمنی نوعی اشیاء حیاتی‌اند، و چگونه می‌توان از آن‌ها به طور مؤثر برای ساخت برنامه‌های قوی‌تر و قابل پیش‌بینی‌تر استفاده کرد. ما سناریوهای مختلف، مشکلات رایج و بهترین شیوه‌ها را بررسی خواهیم کرد تا به توسعه‌دهندگان در سراسر جهان، صرف نظر از پیشینه‌شان، کمک کنیم تا از این مکانیسم حیاتی تایپ‌اسکریپت بهره ببرند.

درک مفهوم اصلی: بررسی خصوصیات اضافی چیست؟

در اصل، بررسی خصوصیات اضافی تایپ‌اسکریپت یک مکانیسم کامپایلر است که شما را از اختصاص دادن یک object literal به متغیری که نوع آن به صراحت آن خصوصیات اضافی را مجاز نمی‌داند، باز می‌دارد. به زبان ساده‌تر، اگر شما یک object literal تعریف کنید و سعی کنید آن را به متغیری با تعریف نوع خاص (مانند یک اینترفیس یا type alias) اختصاص دهید، و آن literal حاوی خصوصیاتی باشد که در نوع تعریف شده اعلام نشده‌اند، تایپ‌اسکریپت آن را به عنوان یک خطا در حین کامپایل علامت‌گذاری می‌کند.

بیایید با یک مثال ساده این موضوع را روشن کنیم:


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

const newUser: User = {
  name: 'Alice',
  age: 30,
  email: 'alice@example.com' // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'email' در نوع 'User' وجود ندارد.
};

در این قطعه کد، ما یک `interface` به نام `User` با دو خصوصیت `name` و `age` تعریف کرده‌ایم. وقتی تلاش می‌کنیم یک object literal با یک خصوصیت اضافی به نام `email` ایجاد کنیم و آن را به متغیری با نوع `User` اختصاص دهیم، تایپ‌اسکریپت فوراً این عدم تطابق را تشخیص می‌دهد. خصوصیت `email` یک خصوصیت 'اضافی' است زیرا در اینترفیس `User` تعریف نشده است. این بررسی به طور خاص زمانی انجام می‌شود که شما از یک object literal برای تخصیص استفاده می‌کنید.

چرا بررسی خصوصیات اضافی مهم است؟

اهمیت بررسی خصوصیات اضافی در توانایی آن‌ها برای اعمال یک قرارداد بین داده‌های شما و ساختار مورد انتظار آن‌ها نهفته است. آن‌ها به چندین روش حیاتی به ایمنی نوعی اشیاء کمک می‌کنند:

بررسی خصوصیات اضافی چه زمانی اعمال می‌شود؟

درک شرایط خاصی که تایپ‌اسکریپت این بررسی‌ها را انجام می‌دهد، بسیار مهم است. آن‌ها عمدتاً به object literals زمانی که به یک متغیر اختصاص داده می‌شوند یا به عنوان آرگومان به یک تابع ارسال می‌شوند، اعمال می‌شوند.

سناریو ۱: تخصیص Object Literals به متغیرها

همانطور که در مثال `User` در بالا مشاهده شد، تخصیص مستقیم یک object literal با خصوصیات اضافی به یک متغیر تایپ‌شده، این بررسی را فعال می‌کند.

سناریو ۲: ارسال Object Literals به توابع

هنگامی که یک تابع انتظار یک آرگومان از نوع خاصی را دارد و شما یک object literal که حاوی خصوصیات اضافی است را ارسال می‌کنید، تایپ‌اسکریپت آن را به عنوان خطا علامت‌گذاری می‌کند.


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' نیست.
             // Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'price' در نوع 'Product' وجود ندارد.
});

در اینجا، خصوصیت `price` در object literal ارسال شده به `displayProduct` یک خصوصیت اضافی است، زیرا اینترفیس `Product` آن را تعریف نکرده است.

بررسی خصوصیات اضافی چه زمانی اعمال *نمی‌شود*؟

درک زمان‌هایی که این بررسی‌ها دور زده می‌شوند به همان اندازه مهم است تا از سردرگمی جلوگیری شود و بدانید چه زمانی ممکن است به استراتژی‌های جایگزین نیاز داشته باشید.

۱. زمانی که از Object Literals برای تخصیص استفاده نمی‌شود

اگر شما شیئی را تخصیص دهید که یک object literal نیست (مثلاً متغیری که از قبل یک شیء را در خود نگه داشته است)، بررسی خصوصیات اضافی معمولاً دور زده می‌شود.


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 یک خصوصیت اضافی دارد، بررسی نادیده گرفته می‌شود
// زیرا این یک object literal نیست که مستقیماً ارسال می‌شود.
// تایپ‌اسکریپت نوع خود 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); // بدون خطا به دلیل type assertion و دور زدن

// نکته کلیدی این است که 'anotherConfig' در نقطه تخصیص به setupConfig یک object literal نیست.
// اگر یک متغیر واسط با نوع 'Config' داشتیم، تخصیص اولیه با شکست مواجه می‌شد.

// مثال از متغیر واسط:
let intermediateConfig: Config;

intermediateConfig = {
  timeout: 3000,
  logging: true // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'logging' در نوع 'Config' وجود ندارد.
};

در اولین مثال `setupConfig(userProvidedConfig)`، `userProvidedConfig` متغیری است که یک شیء را نگه می‌دارد. تایپ‌اسکریپت بررسی می‌کند که آیا `userProvidedConfig` به طور کلی با نوع `Config` مطابقت دارد یا خیر. این بررسی سختگیرانه object literal را روی خود `userProvidedConfig` اعمال نمی‌کند. اگر `userProvidedConfig` با نوعی تعریف شده بود که با `Config` مطابقت نداشت، خطا در هنگام تعریف یا تخصیص آن رخ می‌داد. دور زدن اتفاق می‌افتد زیرا شیء قبلاً ایجاد شده و به یک متغیر اختصاص داده شده است قبل از اینکه به تابع ارسال شود.

۲. تصریح نوع (Type Assertions)

شما می‌توانید با استفاده از تصریح نوع، بررسی خصوصیات اضافی را دور بزنید، هرچند این کار باید با احتیاط انجام شود زیرا تضمین‌های ایمنی تایپ‌اسکریپت را نادیده می‌گیرد.


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

const mySettings = {
  theme: 'dark',
  fontSize: 14 // خصوصیت اضافی
} as Settings;

// به دلیل تصریح نوع، اینجا خطایی وجود ندارد.
// ما به تایپ‌اسکریپت می‌گوییم: "به من اعتماد کن، این شیء با Settings مطابقت دارد."
console.log(mySettings.theme);
// console.log(mySettings.fontSize); // اگر fontSize واقعاً وجود نداشت، این باعث خطای زمان اجرا می‌شد.

۳. استفاده از امضای ایندکس (Index Signatures) یا سینتکس Spread در تعاریف نوع

اگر اینترفیس یا type alias شما به صراحت به خصوصیات دلخواه اجازه دهد، بررسی خصوصیات اضافی اعمال نخواهد شد.

استفاده از امضای ایندکس:


interface FlexibleObject {
  id: number;
  [key: string]: any; // به هر کلید رشته‌ای با هر مقداری اجازه می‌دهد
}

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

// بدون خطا زیرا 'name' و 'version' توسط امضای ایندکس مجاز هستند.
console.log(flexibleItem.name);

استفاده از سینتکس Spread در تعاریف نوع (کمتر رایج برای دور زدن مستقیم بررسی‌ها، بیشتر برای تعریف انواع سازگار):

در حالی که این یک دور زدن مستقیم نیست، spread اجازه ایجاد اشیاء جدیدی را می‌دهد که خصوصیات موجود را در بر می‌گیرند، و بررسی به literal جدید تشکیل شده اعمال می‌شود.

۴. استفاده از `Object.assign()` یا سینتکس Spread برای ادغام

هنگامی که از `Object.assign()` یا سینتکس spread (`...`) برای ادغام اشیاء استفاده می‌کنید، بررسی خصوصیات اضافی به طور متفاوتی عمل می‌کند. این بررسی به object literal حاصل که در حال تشکیل است، اعمال می‌شود.


interface BaseConfig {
  host: string;
}

interface ExtendedConfig extends BaseConfig {
  port: number;
}

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

const userConfig = {
  port: 8080,
  timeout: 5000 // خصوصیت اضافی نسبت به BaseConfig، اما توسط نوع ادغام شده انتظار می‌رود
};

// Spreading به یک object literal جدید که با 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, // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'value' در نوع 'SmallConfig' وجود ندارد.
//   ...data2  // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'status' در نوع 'SmallConfig' وجود ندارد.
// };

// خطا رخ می‌دهد زیرا object literal تشکیل شده توسط سینتکس spread
// حاوی خصوصیات ('value', 'status') است که در 'SmallConfig' وجود ندارند.

// اگر یک متغیر واسط با نوع گسترده‌تر ایجاد کنیم:

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

// سپس با تخصیص به SmallConfig، بررسی خصوصیات اضافی در ایجاد literal اولیه دور زده می‌شود،
// اما بررسی نوع در تخصیص ممکن است همچنان رخ دهد اگر نوع temp به طور دقیق‌تری استنتاج شود.
// اما اگر temp از نوع 'any' باشد، هیچ بررسی تا زمان تخصیص به 'combined' اتفاق نمی‌افتد.

// بیایید درک spread با بررسی خصوصیات اضافی را دقیق‌تر کنیم:
// بررسی زمانی اتفاق می‌افتد که object literal ایجاد شده توسط سینتکس spread
// به یک متغیر تخصیص داده می‌شود یا به تابعی ارسال می‌شود که انتظار نوع خاص‌تری را دارد.

interface SpecificShape { 
  id: number;
}

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

// این با شکست مواجه خواهد شد اگر SpecificShape به 'extra1' یا 'extra2' اجازه ندهد:
// const merged: SpecificShape = {
//   ...objA,
//   ...objB
// };

// دلیل شکست این است که سینتکس spread به طور مؤثری یک object literal جدید ایجاد می‌کند.
// اگر objA و objB کلیدهای مشترکی داشتند، کلید دوم برنده می‌شد. کامپایلر
// این literal حاصل را می‌بیند و آن را با 'SpecificShape' بررسی می‌کند.

// برای اینکه کار کند، ممکن است به یک مرحله واسط یا یک نوع مجازتر نیاز داشته باشید:

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

// اکنون، اگر tempObj خصوصیاتی داشته باشد که در SpecificShape نیستند، تخصیص با شکست مواجه می‌شود:
// const mergedCorrected: SpecificShape = tempObj; // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند...

// نکته کلیدی این است که کامپایلر شکل object literal در حال تشکیل را تحلیل می‌کند.
// اگر آن literal حاوی خصوصیاتی باشد که در نوع هدف تعریف نشده‌اند، این یک خطا است.

// مورد استفاده معمول برای سینتکس spread با بررسی خصوصیات اضافی:

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 // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'lastLogin' در نوع 'AdminProfile' وجود ندارد.
// };

// object literal ایجاد شده توسط spread دارای 'lastLogin' است که در 'AdminProfile' نیست.
// برای رفع این مشکل، 'adminData' باید به طور ایده‌آل با AdminProfile مطابقت داشته باشد یا خصوصیت اضافی باید مدیریت شود.

// رویکرد اصلاح شده:
const validAdminData = {
  adminLevel: 5
};

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

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

بررسی خصوصیات اضافی به object literal حاصل که توسط سینتکس spread ایجاد شده است، اعمال می‌شود. اگر این literal حاصل حاوی خصوصیاتی باشد که در نوع هدف اعلام نشده‌اند، تایپ‌اسکریپت یک خطا گزارش می‌دهد.

استراتژی‌هایی برای مدیریت خصوصیات اضافی

در حالی که بررسی خصوصیات اضافی مفید است، سناریوهای مشروعی وجود دارد که ممکن است خصوصیات اضافی داشته باشید که می‌خواهید آن‌ها را شامل کنید یا به طور متفاوتی پردازش کنید. در اینجا استراتژی‌های رایج آورده شده است:

۱. خصوصیات Rest با Type Aliases یا Interfaces

شما می‌توانید از سینتکس پارامتر rest (`...rest`) در type aliases یا interfaces برای گرفتن هرگونه خصوصیات باقیمانده که به صراحت تعریف نشده‌اند، استفاده کنید. این یک روش تمیز برای شناسایی و جمع‌آوری این خصوصیات اضافی است.


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

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

// یا به طور رایج‌تر با یک type alias و سینتکس rest:
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);

// روش دیگر با استفاده از پارامترهای rest در تعریف نوع:
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;` یا امضاهای ایندکس مشابه، روش اصطلاحی برای مدیریت خصوصیات اضافی دلخواه است.

۲. Destructuring با سینتکس Rest

هنگامی که یک شیء دریافت می‌کنید و نیاز به استخراج خصوصیات خاصی دارید در حالی که بقیه را نگه می‌دارید، destructuring با سینتکس rest بسیار ارزشمند است.


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 حاوی هر خصوصیتی خواهد بود که به صراحت destructure نشده است،
  // مانند 'salary'، 'startDate'، و غیره.
}

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

processEmployeeData(employeeInfo);

// حتی اگر employeeInfo در ابتدا یک خصوصیت اضافی داشت، بررسی خصوصیت اضافی
// دور زده می‌شود اگر امضای تابع آن را بپذیرد (مثلاً با استفاده از امضای ایندکس).
// اگر processEmployeeData به طور دقیق به عنوان 'Employee' تایپ می‌شد، و employeeInfo دارای 'salary' بود،
// خطا رخ می‌داد اگر employeeInfo یک object literal بود که مستقیماً ارسال می‌شد.
// اما در اینجا، employeeInfo یک متغیر است و نوع تابع موارد اضافی را مدیریت می‌کند.

۳. تعریف صریح تمام خصوصیات (در صورت شناخته بودن)

اگر خصوصیات اضافی بالقوه را می‌شناسید، بهترین رویکرد اضافه کردن آن‌ها به اینترفیس یا type alias شماست. این کار بیشترین ایمنی نوعی را فراهم می‌کند.


interface UserProfile {
  id: number;
  name: string;
  email?: string; // ایمیل اختیاری
}

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'
// }; // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'phoneNumber' در نوع 'UserProfile' وجود ندارد.

۴. استفاده از `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` دور می‌زند.
// اما اگر بخواهید یک object literal را مستقیماً ارسال کنید:

// const productConfigLiteral: ProductConfig = {
//   id: 'prod-xyz',
//   version: '2.0',
//   debugMode: false
// }; // خطا: Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'debugMode' در نوع 'ProductConfig' وجود ندارد.

۵. محافظ‌های نوع (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' برای استنتاج نوع literal
  radius: 10,
  color: 'red' // خصوصیت اضافی
};

// هنگام ارسال به calculateArea، امضای تابع انتظار 'Shape' را دارد.
// خود تابع به درستی به 'kind' دسترسی خواهد داشت.
// اگر calculateArea مستقیماً انتظار 'Circle' را داشت و circleData
// را به عنوان یک object literal دریافت می‌کرد، 'color' یک مشکل بود.

// بیایید بررسی خصوصیت اضافی را با تابعی که انتظار یک زیرنوع خاص را دارد، نشان دهیم:

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

// processCircle(circleData); // خطا: آرگومان از نوع '{ kind: "circle"; radius: number; color: string; }' قابل تخصیص به پارامتر از نوع 'Circle' نیست.
                         // Object literal فقط می‌تواند خصوصیات شناخته‌شده را مشخص کند، و 'color' در نوع 'Circle' وجود ندارد.

// برای رفع این مشکل، می‌توانید destructure کنید یا از یک نوع مجازتر برای circleData استفاده کنید:

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

// یا circleData را طوری تعریف کنید که شامل یک نوع گسترده‌تر باشد:

const circleDataWithExtras: Circle & { [key: string]: any } = {
  kind: 'circle',
  radius: 15,
  color: 'blue'
};
processCircle(circleDataWithExtras); // اکنون کار می‌کند.

مشکلات رایج و نحوه اجتناب از آن‌ها

حتی توسعه‌دهندگان باتجربه نیز گاهی اوقات ممکن است توسط بررسی خصوصیات اضافی غافلگیر شوند. در اینجا مشکلات رایج آورده شده است:

ملاحظات جهانی و بهترین شیوه‌ها

هنگام کار در یک محیط توسعه جهانی و متنوع، پایبندی به شیوه‌های ثابت در مورد ایمنی نوع بسیار مهم است:

نتیجه‌گیری

بررسی خصوصیات اضافی تایپ‌اسکریپت سنگ بنای توانایی آن در ارائه ایمنی نوعی قوی برای اشیاء است. با درک اینکه این بررسی‌ها چه زمانی و چرا رخ می‌دهند، توسعه‌دهندگان می‌توانند کدی قابل پیش‌بینی‌تر و با خطای کمتر بنویسند.

برای توسعه‌دهندگان در سراسر جهان، پذیرش این ویژگی به معنای غافلگیری کمتر در زمان اجرا، همکاری آسان‌تر و پایگاه‌های کد قابل نگهداری‌تر است. چه در حال ساخت یک ابزار کوچک باشید یا یک برنامه کاربردی در مقیاس بزرگ، تسلط بر بررسی خصوصیات اضافی بدون شک کیفیت و قابلیت اطمینان پروژه‌های جاوااسکریپت شما را ارتقا خواهد داد.

نکات کلیدی:

با به کارگیری آگاهانه این اصول، می‌توانید ایمنی و قابلیت نگهداری کد تایپ‌اسکریپت خود را به طور قابل توجهی افزایش دهید و به نتایج موفق‌تری در توسعه نرم‌افزار دست یابید.