TypeScript Utility Types: أدوات تختصر عليك الوقت وتحول الكود إلى قطعة فنية

تخيل أنك تعمل على مشروع ضخم يحتوي على أكثر من ٥٠ واجهة TypeScript، وكل واجهة منها تحتاج إلى نسخة معدلة قليلاً: بعضها يحتاج إلى حقول اختيارية، وبعضها يحتاج إلى حقول للقراءة فقط، وبعضها يحتاج إلى دمج واجهتين معاً. بدون Utility Types، ستجد نفسك تكتب نفس الكود مراراً وتكراراً، مما يزيد من احتمالية الأخطاء ويجعل الكود صعب الصيانة. هنا تأتي Utility Types كمنقذ، فهي تسمح لك بتحويل الأنواع الموجودة إلى أنواع جديدة دون إعادة اختراع العجلة. ولكن كيف تعمل هذه الأدوات خلف الكواليس؟ وما هي الفخاخ التي يجب تجنبها عند استخدامها؟

في هذا المقال، سنغوص عميقاً في عالم TypeScript Utility Types، ونكشف كيف يمكن لهذه الأدوات أن تختصر عليك ساعات من العمل اليدوي، وتحول الكود الخاص بك إلى شيء أنيق وفعّال. سنتحدث عن الأداء، والذاكرة، وكيفية تجنب الأخطاء الشائعة التي يقع فيها حتى المطورون ذوو الخبرة. لن نكتفي بالأساسيات؛ سنذهب إلى ما وراء الكواليس لفهم كيف يتعامل TypeScript مع هذه الأنواع على مستوى المترجم والمعالج.

Partial وRequired: عندما تريد التحكم في الحقول الاختيارية

لنبدأ بأحد أكثر Utility Types شيوعاً: `Partial<T>`. هذا النوع يحول جميع خصائص النوع `T` إلى اختيارية. يبدو بسيطاً، لكن خلف الكواليس، يحدث شيء مثير للاهتمام. عندما تستخدم `Partial`، فإن TypeScript لا يقوم بإنشاء نوع جديد تماماً في الذاكرة، بل يقوم بإنشاء نوع مؤقت يعتمد على النوع الأصلي مع تعديل الخصائص فقط. هذا يعني أن الأداء لا يتأثر بشكل كبير، لأن TypeScript يتعامل مع هذه الأنواع كمراجع وليس كنسخ كاملة. ولكن ماذا يحدث إذا كان لديك نوع معقد يحتوي على أنواع متداخلة؟ هنا تكمن المشكلة: `Partial` لا يعمل بشكل متكرر على الأنواع المتداخلة، مما يعني أنك قد تحتاج إلى استخدام `DeepPartial` مخصص إذا كنت تريد تحويل جميع الخصائص المتداخلة إلى اختيارية.

على الجانب الآخر، لدينا `Required<T>`، الذي يقوم بعكس ما يفعله `Partial`. فهو يجعل جميع الخصائص إلزامية. في رأيي، هذا النوع مفيد جداً عند التعامل مع واجهات تحتوي على حقول اختيارية قد تسبب مشاكل في وقت التشغيل إذا لم تكن موجودة. مثلاً، إذا كنت تعمل على واجهة `User` تحتوي على حقل `email` اختياري، واستخدمت هذه الواجهة في دالة تتطلب وجود `email`، فإن `Required<User>` سيضمن لك أن جميع الحقول موجودة قبل تمريرها إلى الدالة. ولكن كن حذراً: استخدام `Required` بشكل مفرط قد يجعل الكود الخاص بك أقل مرونة، خاصة إذا كنت تتعامل مع واجهات خارجية قد لا تحتوي على جميع الحقول المطلوبة.

// مثال عملي على Partial وRequired
interface User {
 id: number;
 name: string;
 email?: string;
 age?: number;
}

// تحويل جميع الحقول إلى اختيارية
const partialUser: Partial<User> = { name: "Ahmed" };

// تحويل جميع الحقول إلى إلزامية
const requiredUser: Required<User> = {
 id: 1,
 name: "Ahmed",
 email: "ahmed@example.com",
 age: 30
};

// مشكلة مع Partial عند التعامل مع الأنواع المتداخلة
interface Profile {
 user: User;
 address?: {
 city: string;
 country: string;
 };
}

const partialProfile: Partial<Profile> = {
 user: { name: "Ahmed" } // خطأ: الحقول داخل user لا تزال إلزامية
};
// الحل: استخدام DeepPartial مخصص

Readonly وMutable: التحكم في قابلية التعديل

إذا كنت تعمل على مشروع يتطلب حماية البيانات من التعديل، فإن `Readonly<T>` هو صديقك. هذا النوع يجعل جميع خصائص النوع `T` للقراءة فقط، مما يمنع أي تعديل بعد الإنشاء. ولكن كيف يعمل هذا خلف الكواليس؟ عندما تستخدم `Readonly`، فإن TypeScript يضيف قيداً على مستوى النوع فقط، وليس على مستوى الذاكرة. هذا يعني أن الكائن الفعلي لا يزال قابلاً للتعديل في وقت التشغيل إذا تم الوصول إليه عبر طرق أخرى، مثل إلى نوع آخر. لذلك، إذا كنت تريد حماية حقيقية للبيانات، يجب عليك استخدام أدوات إضافية مثل `Object.freeze` في JavaScript.

على سبيل المثال، إذا كنت تعمل على مكتبة للتعامل مع التكوينات، وقدمت كائن `config` باستخدام `Readonly`، فإن أي محاولة لتعديل هذا الكائن ستؤدي إلى خطأ في وقت الترجمة. ولكن إذا قام مستخدم المكتبة باستخدام `as any` لتجاوز التحقق من النوع، فإن الكائن سيصبح قابلاً للتعديل في وقت التشغيل. هذا يوضح أن `Readonly` هو أداة للتحقق من النوع فقط، وليس لحماية الذاكرة الفعلية. في مشاريعي السابقة، كنت دائماً أستخدم `Readonly` مع `Object.freeze` لضمان حماية كاملة، خاصة عند التعامل مع البيانات الحساسة مثل مفاتيح API أو التكوينات الثابتة.

// استخدام Readonly لحماية البيانات
interface Config {
 apiKey: string;
 baseUrl: string;
 timeout: number;
}

const config: Readonly<Config> = {
 apiKey: "12345",
 baseUrl: "https://api.example.com",
 timeout: 5000
};

// config.apiKey = "67890"; // خطأ في وقت الترجمة

// تجاوز التحقق من النوع باستخدام as any
const unsafeC config as any;
unsafeConfig.apiKey = "67890"; // يعمل في وقت التشغيل

// الحل: استخدام Object.freeze مع Readonly
const frozenConfig: Readonly<Config> = Object.freeze({
 apiKey: "12345",
 baseUrl: "https://api.example.com",
 timeout: 5000
});
// frozenConfig.apiKey = "67890"; // خطأ في وقت التشغيل حتى مع as any

Mutable: عكس Readonly

على الرغم من أن TypeScript لا يحتوي على `Mutable<T>` مدمج، إلا أنه يمكنك إنشاء نوع مخصص يقوم بعكس ما يفعله `Readonly`. هذا النوع مفيد عندما تريد تحويل نوع للقراءة فقط إلى نوع قابل للتعديل. في مشاريعي، كنت أستخدم هذا النوع عند التعامل مع مكتبات خارجية تقدم أنواعاً للقراءة فقط، ولكنني بحاجة إلى تعديل بعض الخصائص قبل تمريرها إلى دالة أخرى. على سبيل المثال، إذا كانت مكتبة خارجية تقدم نوع `Readonly<User>`، ولكنني بحاجة إلى تعديل حقل `age` قبل حفظ المستخدم في قاعدة البيانات، فإن `Mutable` يسمح لي بذلك بسهولة.

// تعريف نوع Mutable مخصص
type Mutable<T> = {
 -readonly [P in keyof T]: T[P];
};

interface ReadonlyUser {
 readonly id: number;
 readonly name: string;
 readonly age: number;
}

const user: Read {
 id: 1,
 name: "Ahmed",
 age: 30
};

// const mutableUser: Mutable<ReadonlyUser> = user;
// mutableUser.age = 31; // يعمل الآن

Pick وOmit: عندما تريد انتقاء أو استبعاد حقول محددة

`Pick<T, K>` و`Omit<T, K>` هما من أكثر Utility Types فائدة عندما تريد التعامل مع جزء من نوع معين. `Pick` يسمح لك باختيار مجموعة من الخصائص من النوع `T`، بينما `Omit` يسمح لك باستبعاد مجموعة من الخصائص. خلف الكواليس، يعمل هذان النوعان عن طريق إنشاء نوع جديد يعتمد على النوع الأصلي، ولكن مع تعديل الخصائص المدرجة أو المستبعدة. هذا يعني أن الأداء لا يتأثر بشكل كبير، لأن TypeScript يتعامل مع هذه الأنواع كمراجع وليس كنسخ كاملة. ولكن هناك شيء يجب أن تكون حذراً منه: إذا كنت تستخدم `Pick` أو `Omit` مع أنواع تحتوي على خصائص متداخلة، فإن هذه الأدوات لن تعمل بشكل متكرر على الخصائص المتداخلة، مما قد يؤدي إلى مشاكل إذا كنت تتوقع سلوكاً مختلفاً.

في تجربتي، وجدت أن `Pick` مفيد جداً عند التعامل مع واجهات كبيرة تحتوي على العديد من الخصائص، ولكنك تحتاج فقط إلى جزء منها في دالة معينة. مثلاً، إذا كان لديك واجهة `Product` تحتوي على ٢٠ حقلاً، ولكن دالة `calculateDiscount` تحتاج فقط إلى حقول `price` و`discountRate`، فإن `Pick<Product, 'price' | 'discountRate'>` سيجعل الكود أكثر وضوحاً وأقل عرضة للأخطاء. من ناحية أخرى، `Omit` مفيد عندما تريد استبعاد حقول معينة قد تسبب مشاكل، مثل حقول `password` أو `token` عند تمرير البيانات إلى واجهة المستخدم.

// مثال على Pick وOmit
interface Product {
 id: number;
 name: string;
 price: number;
 discountRate?: number;
 description: string;
 stock: number;
 category: string;
}

// انتقاء حقول معينة باستخدام Pick
type ProductPriceInfo = Pick<Product, 'price' | 'discountRate'>;
const priceInfo: ProductPriceInfo = { price: 100, discountRate: 0.1 };

// استبعاد حقول معينة باستخدام Omit
type ProductWithoutSensitiveInfo = Omit<Product, 'stock' | 'category'>;
const publicProduct: ProductWithoutSensitiveInfo = {
 id: 1,
 name: "Laptop",
 price: 1000,
 description: "High-performance laptop"
};

// مشكلة مع Pick وOmit عند التعامل مع الأنواع المتداخلة
interface Order {
 id: number;
 product: Product;
 quantity: number;
}

type OrderWithoutProductDetails = Omit<Order, 'product'>;
const order: OrderWithoutProductDetails = {
 id: 1,
 quantity: 2
 // product لا يزال موجوداً كنوع كامل، وليس مستبعداً
};

Record وMapped Types: عندما تريد إنشاء أنواع ديناميكية

`Record<K, T>` هو أحد أقوى Utility Types في TypeScript، لأنه يسمح لك بإنشاء أنواع ديناميكية تعتمد على مفاتيح وقيم محددة. خلف الكواليس، `Record` يعمل عن طريق إنشاء نوع جديد يحتوي على جميع المفاتيح من النوع `K`، وكل مفتاح يشير إلى النوع `T`. هذا يعني أنك تستطيع إنشاء أنواع معقدة جداً باستخدام سطر واحد من الكود. على سبيل المثال، إذا كنت تريد إنشاء نوع يمثل قاموساً يحتوي على مفاتيح من نوع `string` وقيم من نوع `number`، فإن `Record<string, number>` سيفعل ذلك بسهولة. ولكن ماذا يحدث إذا كنت تريد إنشاء نوع ديناميكي يعتمد على نوع موجود بالفعل؟ هنا تأتي أهمية Mapped Types، التي تسمح لك بتحويل نوع موجود إلى نوع جديد باستخدام قواعد محددة.

في مشاريعي، كنت أستخدم `Record` بشكل مكثف عند التعامل مع البيانات القادمة من APIs، حيث تكون المفاتيح ديناميكية ولا يمكن تحديدها مسبقاً. مثلاً، إذا كنت تتعامل مع API يقدم بيانات المستخدمين في شكل قاموس، حيث المفاتيح هي معرفات المستخدمين والقيم هي بيانات المستخدمين، فإن `Record<string, User>` سيوفر لك نوعاً آمناً للتعامل مع هذه البيانات. ولكن كن حذراً: استخدام `Record` بشكل مفرط قد يؤدي إلى أنواع غير واضحة، خاصة إذا كنت تستخدم مفاتيح ديناميكية معقدة. في هذه الحالات، قد يكون من الأفضل استخدام Mapped Types المخصصة لتوفير أنواع أكثر وضوحاً.

// استخدام Record لإنشاء أنواع ديناميكية
interface User {
 id: number;
 name: string;
 email: string;
}

// إنشاء قاموس للمستخدمين
const users: Record<string, User> = {
 "user1": { id: 1, name: "Ahmed", email: "ahmed@example.com" },
 "user2": { id: 2, name: "Sara", email: "sara@example.com" }
};

// استخدام Mapped Types لتحويل نوع موجود
interface Product {
 id: number;
 name: string;
 price: number;
}

// تحويل جميع الخصائص إلى اختيارية باستخدام Mapped Types
type Opti {
 [K in keyof Product]?: Product[K];
};

const optionalProduct: OptionalProduct = { name: "Laptop" };

// تحويل جميع الخصائص إلى للقراءة فقط
 type ReadonlyProduct = {
 readonly [K in keyof Product]: Product[K];
};

Exclude وExtract وNonNullable: فلترة الأنواع بدقة

`Exclude<T, U>` و`Extract<T, U>` و`NonNullable<T>` هي Utility Types التي تسمح لك بفلترة الأنواع بناءً على شروط محددة. `Exclude` يزيل جميع الأنواع الموجودة في `U` من `T`، بينما `Extract` يحتفظ فقط بالأنواع الموجودة في `U`. أما `NonNullable` فيزيل القيم `null` و`undefined` من النوع. خلف الكواليس، تعمل هذه الأدوات عن طريق مقارنة الأنواع على مستوى المترجم، مما يعني أنها لا تؤثر على الأداء في وقت التشغيل. ولكن هناك شيء يجب أن تكون حذراً منه: هذه الأدوات تعمل على مستوى الأنواع فقط، وليس على مستوى القيم. لذلك، إذا كنت تتوقع أن يزيل `NonNullable` القيم `null` أو `undefined` من الكائن الفعلي، فأنت مخطئ. هذه الأدوات هي فقط للتحقق من النوع في وقت الترجمة.

في تجربتي، وجدت أن `Exclude` مفيد جداً عند التعامل مع أنواع الاتحاد (Union Types). مثلاً، إذا كان لديك نوع `Status` يحتوي على القيم `'active' | 'inactive' | 'pending'`، وتريد إنشاء نوع جديد يحتوي فقط على `'active' | 'inactive'`، فإن `Exclude<Status, 'pending'>` سيوفر لك ذلك بسهولة. من ناحية أخرى، `Extract` مفيد عندما تريد استخراج أنواع محددة من نوع اتحاد معقد. على سبيل المثال، إذا كان لديك نوع `Event` يحتوي على `'click' | 'hover' | 'keydown'`، وتريد إنشاء نوع جديد يحتوي فقط على الأحداث المتعلقة بالفأرة، فإن `Extract<Event, 'click' | 'hover'>` سيفعل ذلك. أما `NonNullable` فهو مفيد جداً عند التعامل مع البيانات القادمة من APIs التي قد تحتوي على قيم `null` أو `undefined`، حيث يضمن لك أن النوع لا يحتوي على هذه القيم.

// استخدام Exclude وExtract وNonNullable
 type Status = 'active' | 'inactive' | 'pending';
 type ActiveStatus = Exclude<Status, 'pending'>; // 'active' | 'inactive'

 type Event = 'click' | 'hover' | 'keydown';
 type MouseEvent = Extract<Event, 'click' | 'hover'>; // 'click' | 'hover'

 type NullableString = string | null | undefined;
 type N NonNullable<NullableString>; // string

 // مشكلة مع NonNullable
 const nullableValue: NullableString = null;
 const nonNullableValue: NonNullableString = nullableValue; // خطأ في وقت الترجمة
 // ولكن إذا تم تجاوز التحقق من النوع، فإن القيمة ستظل null في وقت التشغيل

الـ Troubleshooting والفخاخ: ما لا يخبرك به الوثائق

على الرغم من أن Utility Types توفر حلولاً أنيقة للكثير من المشاكل، إلا أنها تأتي مع مجموعة من الفخاخ التي قد تقع فيها بسهولة. أحد أكبر هذه الفخاخ هو التعامل مع الأنواع المتداخلة. كما ذكرنا سابقاً، معظم Utility Types لا تعمل بشكل متكرر على الأنواع المتداخلة، مما يعني أنك قد تحتاج إلى إنشاء أنواع مخصصة لحل هذه المشكلة. مثلاً، إذا كان لديك نوع يحتوي على كائنات متداخلة وتريد تحويل جميع الخصائص إلى اختيارية، فإن `Partial` لن يعمل كما تتوقع. في هذه الحالة، ستحتاج إلى استخدام `DeepPartial` مخصص، والذي يمكن تعريفه باستخدام Mapped Types والتكرار.

فخ آخر هو التعامل مع الأنواع الديناميكية. على سبيل المثال، إذا كنت تستخدم `Record` لإنشاء قاموس يحتوي على مفاتيح ديناميكية، فقد تواجه مشاكل عند محاولة الوصول إلى هذه المفاتيح في وقت الترجمة. TypeScript لا يمكنه معرفة المفاتيح الدقيقة في وقت الترجمة، مما يعني أنك قد تحتاج إلى استخدام نوع `keyof` أو التحقق من النوع في وقت التشغيل. بالإضافة إلى ذلك، يجب أن تكون حذراً عند استخدام `as` لتجاوز التحقق من النوع، لأن هذا قد يؤدي إلى أخطاء في وقت التشغيل إذا لم تكن متأكداً من نوع البيانات. في مشاريعي السابقة، كنت دائماً أحاول تجنب استخدام `as` قدر الإمكان، واستبداله بأنواع أكثر دقة أو التحقق من النوع في وقت التشغيل باستخدام دوال مثل `typeof` أو `instanceof`.

// DeepPartial مخصص للتعامل مع الأنواع المتداخلة
type DeepPartial<T> = {
 [P in keyof T]?: T[P] extends object ? DeepPartial<T[P]> : T[P];
};

interface Profile {
 user: {
 id: number;
 name: string;
 };
 address: {
 city: string;
 country: string;
 };
}

const partialProfile: DeepPartial<Profile> = {
 user: { name: "Ahmed" }, // يعمل الآن
 address: { city: "Cairo" }
};

// مشكلة مع الوصول إلى المفاتيح الديناميكية في Record
const dynamicData: Record<string, number> = { a: 1, b: 2 };
// console.log(dynamicData.c); // خطأ في وقت الترجمة لأن المفتاح غير معروف
// الحل: استخدام التحقق في وقت التشغيل
if ('c' in dynamicData) {
 console.log(dynamicData.c);
}

الأداء والذاكرة: هل Utility Types تؤثر على الأداء؟

سؤال شائع بين المطورين هو ما إذا كان استخدام Utility Types يؤثر على الأداء أو الذاكرة. الحقيقة هي أن Utility Types لا تؤثر على الأداء في وقت التشغيل، لأنها تعمل فقط على مستوى المترجم. عندما يقوم TypeScript بتحويل الكود إلى JavaScript، تختفي جميع الأنواع، بما في ذلك Utility Types. هذا يعني أن الكود النهائي الذي يتم تشغيله لا يحتوي على أي أثر لهذه الأنواع. ومع ذلك، هناك شيء يجب أن تكون حذراً منه: إذا كنت تستخدم Utility Types مع أنواع معقدة جداً أو متداخلة بشكل كبير، فقد يؤدي ذلك إلى زيادة وقت الترجمة، خاصة إذا كان المشروع كبيراً. في مشاريعي، لاحظت أن استخدام Utility Types بشكل مفرط مع أنواع تحتوي على مئات الخصائص قد يؤدي إلى بطء في وقت الترجمة، ولكن هذا نادراً ما يكون مشكلة في المشاريع العادية.

من ناحية الذاكرة، فإن Utility Types لا تستهلك ذاكرة إضافية في وقت التشغيل، لأنها تختفي بعد الترجمة. ومع ذلك، إذا كنت تستخدم Utility Types لإنشاء أنواع معقدة جداً، فقد يؤدي ذلك إلى زيادة حجم ملفات `.d.ts`، مما قد يؤثر على وقت تحميل المحرر أو أدوات التطوير الأخرى. ولكن هذا عادة لا يكون مشكلة كبيرة، لأن ملفات `.d.ts` يتم تحميلها مرة واحدة فقط عند بدء تشغيل المحرر. في النهاية، يمكن القول أن Utility Types هي أداة قوية وآمنة للاستخدام، ولا داعي للقلق بشأن تأثيرها على الأداء أو الذاكرة في معظم الحالات.

خلاصة المهندس: نصائح عملية لاستخدام Utility Types بفعالية

بعد سنوات من العمل مع TypeScript وUtility Types، إليك بعض النصائح العملية التي ستساعدك على استخدامها بفعالية أكبر. أولاً، لا تحاول استخدام Utility Types لكل شيء. استخدمها فقط عندما توفر لك قيمة حقيقية وتجعل الكود أكثر وضوحاً وأقل عرضة للأخطاء. ثانياً، كن حذراً عند التعامل مع الأنواع المتداخلة، واستخدم أنواعاً مخصصة مثل `DeepPartial` إذا كنت بحاجة إلى سلوك متكرر. ثالثاً، تجنب استخدام `as` لتجاوز التحقق من النوع، واستخدم بدلاً من ذلك أنواعاً أكثر دقة أو التحقق في وقت التشغيل. رابعاً، إذا كنت تعمل على مشروع كبير، حاول تقليل استخدام Utility Types مع الأنواع المعقدة جداً لتجنب بطء وقت الترجمة. وأخيراً، لا تخف من إنشاء Utility Types المخصصة الخاصة بك إذا كانت الأدوات المدمجة لا تلبي احتياجاتك.

Utility Types هي واحدة من أقوى الميزات في TypeScript، وهي ما يجعل هذه اللغة تتفوق على JavaScript في العديد من الجوانب. إذا كنت تريد كتابة كود أنيق، آمن، وسهل الصيانة، فإن تعلم كيفية استخدام هذه الأدوات بفعالية هو خطوة أساسية. ابدأ بتجربة الأمثلة التي قدمناها في هذا المقال، وحاول تطبيقها في مشاريعك الحقيقية. مع الوقت، ستجد نفسك تستخدم هذه الأدوات بشكل طبيعي، وستلاحظ الفرق الكبير الذي تحدثه في جودة الكود الخاص بك.