TypeScript Utility Types: الأدوات السرية التي تختصر عليك ٣٠٪ من وقت التطوير

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

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

Partial و Required: عندما تريد التحكم في الإلزامية دون إعادة كتابة الأنواع

لنقل أنك تعمل على نظام إدارة مستخدمين، ولديك واجهة User تحتوي على ١٠ حقول إلزامية. في سيناريو معين، مثل تحديث بيانات المستخدم، تريد السماح بتحديث بعض الحقول فقط دون الحاجة لإرسال الكائن كاملاً. هنا يأتي دور Partial<T>، الذي يحول جميع خصائص النوع T إلى اختيارية. لكن ماذا يحدث خلف الكواليس؟

TypeScript لا يولد كوداً جديداً في وقت التشغيل، بل هو مجرد أداة تحليل ثابتة. عندما تستخدم Partial<User>، فإن TypeScript يقوم بإنشاء نوع جديد داخلياً، حيث يتم وضع علامة Optional (?) على كل خاصية. هذا يعني أن الذاكرة لا تتحمل عبئاً إضافياً، لكن المحرك سيقوم بتحليل النوع الجديد في وقت التحويل (Compilation Time). المشكلة الشائعة هنا هي أن المطورين ينسون أن Partial لا يغير السلوك في وقت التشغيل، فلو أرسلت كائناً يحتوي على خاصية غير موجودة أصلاً في النوع، فلن يتم اكتشاف الخطأ إلا في وقت التشغيل.

interface User {
 id: string;
 name: string;
 email: string;
 age: number;
 isActive: boolean;
}

// قبل Partial
function updateUser(user: User): void {
 // يجب إرسال جميع الحقول
}

// بعد Partial
function updateUserPartial(user: Partial<User>): void {
 // يمكن إرسال بعض الحقول فقط
}

// مثال على الخطأ الشائع
updateUserPartial({ name: "Ahmed", nonExistentField: true }); // ❌ لا خطأ في TypeScript، لكن سينفجر في وقت التشغيل

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

interface ApiResponse {
 data?: {
 id: string;
 value?: number;
 };
 status: number;
}

// استخدام Required بشكل خاطئ
function processResponse(response: Required<ApiResponse>) {
 // ❌ قد يفشل إذا كانت data.value غير موجودة
 console.log(response.data.value.toFixed(2));
}

// الحل الأفضل: التحقق في وقت التشغيل
function processResponseSafe(response: ApiResponse) {
 if (!response.data?.value) {
 throw new Error("Missing required data");
 }
 console.log(response.data.value.toFixed(2));
}

Pick و Omit: استخراج الأنواع دون التضحية بالأداء

في المشاريع الكبيرة، غالباً ما تجد نفسك تعمل مع واجهات ضخمة تحتوي على عشرات الخصائص. مثلاً، واجهة Product في نظام التجارة الإلكترونية قد تحتوي على ٥٠ حقلاً، لكن في صفحة معينة، تحتاج فقط لثلاثة حقول: id، name، price. هنا يأتي دور Pick<T, K>، الذي يسمح لك باستخراج مجموعة فرعية من الخصائص من النوع T. لكن هل هذا مجرد اختصار كتابي، أم أنه يؤثر على الأداء؟

الحقيقة هي أن Pick لا يولد كوداً إضافياً، بل هو مجرد أداة تحليل ثابتة. عندما تستخدم Pick<Product, 'id' | 'name' | 'price'>، فإن TypeScript يقوم بإنشاء نوع جديد يحتوي فقط على الخصائص المحددة. هذا يعني أن المحرك لا يحتاج لمعالجة الخصائص الأخرى في وقت التحويل، مما قد يحسن أداء التحويل قليلاً في المشاريع الكبيرة. لكن احذر: إذا استخدمت Pick بشكل مفرط، فقد ينتهي بك الأمر إلى أنواع مكررة ومربكة، خاصة إذا تغيرت الواجهة الأصلية.

interface Product {
 id: string;
 name: string;
 price: number;
 description: string;
 category: string;
 stock: number;
 ratings: number[];
 // ... 40 حقل آخر
}

// استخدام Pick لاستخراج الحقول المطلوبة فقط
function displayProduct(product: Pick<Product, 'id' | 'name' | 'price'>) {
 console.log(`${product.name} - $${product.price}`);
}

// مثال على الفخ: تغيير الواجهة الأصلية
interface UpdatedProduct {
 id: string;
 productName: string; // تم تغيير اسم الحقل
 price: number;
 // ...
}

// ❌ خطأ لأن 'name' لم يعد موجوداً
// displayProduct({ id: "1", name: "Laptop", price: 999 });

أما Omit<T, K> فهو العكس تماماً: يستبعد الخصائص المحددة من النوع. مثلاً، إذا أردت إنشاء نوع جديد بدون الحقول الحساسة مثل password أو token. لكن هنا تكمن المشكلة: Omit لا يمنع وجود الخصائص في وقت التشغيل، بل يمنع فقط استخدامها في وقت التحويل. لو أرسلت كائناً يحتوي على الحقول المستبعدة، فلن يظهر خطأ في TypeScript، لكن قد تحدث مشاكل في المنطق. الحل هو استخدام Omit مع التحقق في وقت التشغيل، أو الأفضل، استخدام الأدوات مثل zod للتحقق من البيانات.

interface UserCredentials {
 username: string;
 password: string;
 token: string;
}

// استخدام Omit لإزالة الحقول الحساسة
function displayUser(user: Omit<UserCredentials, 'password' | 'token'>) {
 console.log(`User: ${user.username}`);
}

// ❌ لا خطأ في TypeScript، لكن قد يسبب مشاكل أمنية
const unsafeUser = {
 username: "admin",
 password: "123456", // مازال موجوداً في وقت التشغيل
};
displayUser(unsafeUser); // ✅ TypeScript لا يشتكي

Record و Map: بناء الهياكل الديناميكية بذكاء

في عالم البرمجة، غالباً ما تحتاج لبناء هياكل بيانات ديناميكية، مثل الخرائط أو القوائم المفهرسة. مثلاً، تخزين إعدادات المستخدم لكل مستخدم بناءً على الـ ID، أو بناء فهرس للبيانات بناءً على خاصية معينة. هنا يأتي دور Record<K, T>، الذي يسمح لك بإنشاء نوع يمثل كائناً يحتوي على مفاتيح من النوع K وقيم من النوع T. لكن متى يجب استخدام Record، ومتى يجب استخدام Map؟

الفرق الأساسي بين Record و Map هو أن Record هو مجرد نوع في TypeScript، بينما Map هو هيكل بيانات حقيقي في JavaScript. عندما تستخدم Record<string, number>، فإن TypeScript يتوقع أن يكون لديك كائن عادي (Object) يحتوي على مفاتيح من نوع string وقيم من نوع number. أما Map، فهو هيكل بيانات مخصص يدعم المفاتيح من أي نوع، ويحافظ على ترتيب الإدراج، ويدعم طرقاً مخصصة مثل set و get. في معظم الحالات، إذا كنت بحاجة لمفاتيح غير string أو تحتاج للتحكم في ترتيب العناصر، فاستخدم Map. أما إذا كنت تعمل مع كائنات بسيطة وتحتاج فقط للتحقق من الأنواع، فاستخدم Record.

// استخدام Record لبناء فهرس بسيط
interface User {
 id: string;
 name: string;
}

const users: Record<string, User> = {};

users["1"] = { id: "1", name: "Alice" };
users["2"] = { id: "2", name: "Bob" };

// استخدام Map لبناء فهرس مع مفاتيح غير string
const userMap = new Map<number, User>();

userMap.set(1, { id: "1", name: "Alice" });
userMap.set(2, { id: "2", name: "Bob" });

// مثال على الفخ: استخدام Record مع مفاتيح غير string
const badRecord: Record<number, User> = {};
// ❌ خطأ لأن مفاتيح الكائن يجب أن تكون string في JavaScript
badRecord[1] = { id: "1", name: "Alice" }; // في وقت التشغيل: badRecord["1"]

في مشاريع حقيقية، غالباً ما تجد نفسك تستخدم Record لبناء الفهارس البسيطة، و Map للتعامل مع البيانات الديناميكية. مثلاً، في نظام إدارة الطلبات، قد تستخدم Record<string, Order> لتخزين الطلبات بناءً على الـ ID، لكن تستخدم Map<string, Set<string>> لبناء فهرس للطلبات بناءً على حالة الطلب (مثل pending، completed). لكن احذر: إذا استخدمت Record بشكل مفرط، فقد ينتهي بك الأمر إلى كائنات ضخمة جداً، مما يؤثر على أداء التطبيق. في هذه الحالة، فكر في استخدام قواعد البيانات أو هياكل بيانات أكثر كفاءة.

Readonly و Deep Readonly: حماية البيانات من التعديل العرضي

في التطبيقات الكبيرة، غالباً ما تحتاج لمنع تعديل البيانات بعد إنشائها، خاصة في الـ State Management أو عند التعامل مع البيانات الثابتة. مثلاً، إعدادات التطبيق أو قوائم الثوابت يجب ألا تتغير بعد التحميل. هنا يأتي دور Readonly<T>، الذي يجعل جميع خصائص النوع T غير قابلة للتعديل. لكن هل هذا يكفي؟

الجواب هو لا. Readonly<T> يعمل فقط على المستوى الأول من الكائن، ولا يمنع تعديل الخصائص المتداخلة. مثلاً، إذا كان لديك كائن يحتوي على مصفوفة أو كائن آخر، فإن Readonly لن يمنع تعديل هذه الخصائص المتداخلة. هنا يأتي دور Deep Readonly، وهو ليس مدمجاً في TypeScript، لكن يمكن تحقيقه باستخدام الأدوات أو المكتبات مثل ts-essentials أو utility-types. في رأيي، Deep Readonly هو أداة ضرورية في أي مشروع جاد، خاصة إذا كنت تعمل مع Redux أو أي مكتبة لإدارة الحالة.

// استخدام Readonly لمنع التعديل
interface Config {
 apiUrl: string;
 maxRetries: number;
 endpoints: {
 users: string;
 products: string;
 };
}

const config: Readonly<Config> = {
 apiUrl: "https://api.example.com",
 maxRetries: 3,
 endpoints: {
 users: "/users",
 products: "/products",
 },
};

// ❌ خطأ في TypeScript
// config.maxRetries = 5;

// ✅ مسموح في TypeScript، لكن غير مرغوب
config.endpoints.users = "/new-users"; // لا خطأ لأن Readonly سطحي فقط

// حل Deep Readonly باستخدام مكتبة خارجية
import { DeepReadonly } from "utility-types";

const deepConfig: DeepReadonly<Config> = {
 apiUrl: "https://api.example.com",
 maxRetries: 3,
 endpoints: {
 users: "/users",
 products: "/products",
 },
};

// ❌ خطأ في TypeScript
// deepConfig.endpoints.users = "/new-users";

في مشاريع حقيقية، غالباً ما أجد نفسي أستخدم Deep Readonly مع بيانات الـ Configuration أو الـ State في تطبيقات الرياكت. مثلاً، في تطبيق يستخدم Redux، يمكنك جعل الـ State غير قابل للتعديل مباشرة، مما يقلل من الأخطاء ويجعل الكود أكثر قابلية للتنبؤ. لكن احذر: Deep Readonly قد يؤثر على أداء التطبيق إذا استخدمت مع هياكل بيانات ضخمة، لأن TypeScript سيقوم بإنشاء أنواع متداخلة لكل مستوى من الكائن. في هذه الحالة، فكر في استخدام المكتبات مثل Immer التي تسمح لك بالكتابة بطريقة غير قابلة للتعديل دون التضحية بالأداء.

الـ Utility Types المتقدمة: بناء الأنواع الديناميكية

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

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

// استخدام Mapped Types لتحويل جميع الخصائص إلى readonly
interface User {
 id: string;
 name: string;
 age: number;
}

type Read {
 readonly [K in keyof User]: User[K];
};

// استخدام Mapped Types لتحويل جميع الخصائص إلى اختيارية
interface Settings {
 theme: string;
 language: string;
 notifications: boolean;
}

type OptionalSettings = {
 [K in keyof Settings]?: Settings[K];
};

// استخدام Mapped Types لتغيير نوع الخصائص
interface Product {
 id: string;
 price: number;
 stock: number;
}

type StringifiedProduct = {
 [K in keyof Product]: string;
};

أما Conditional Types، فهي تسمح لك بإنشاء أنواع تعتمد على شروط. مثلاً، يمكنك إنشاء نوع يمثل نتيجة دالة بناءً على نوع المدخلات، أو نوعاً يمثل قيمة افتراضية بناءً على نوع الخاصية. في مشروع حقيقي، استخدمت Conditional Types لبناء نظام معالجة الأخطاء الديناميكي، حيث يعتمد نوع الخطأ المرتجع على نوع العملية التي تمت. مثلاً، إذا كانت العملية متعلقة بالشبكة، فإن نوع الخطأ سيكون NetworkError، وإذا كانت متعلقة بالتحقق من البيانات، فسيكون ValidationError.

// استخدام Conditional Types لتحديد نوع القيمة الافتراضية
interface DefaultValues {
 string: "";
 number: 0;
 boolean: false;
 object: {};
}

type GetDefaultValue<T> = T extends keyof DefaultValues ? DefaultValues[T] : never;

// استخدام Conditional Types لتحديد نوع الخطأ
interface NetworkError {
 type: "network";
 message: string;
 statusCode: number;
}

interface ValidationError {
 type: "validation";
 message: string;
 field: string;
}

type ApiError<T extends "network" | "validation"> =
 T extends "network" ? NetworkError : ValidationError;

function handleError<T extends "network" | "validation">(type: T, error: ApiError<T>): void {
 console.error(`Error: ${error.message}`);
}

handleError("network", { type: "network", message: "Failed to fetch", statusCode: 500 });
handleError("validation", { type: "validation", message: "Invalid email", field: "email" });

الخلاصة: كيف تستخدم Utility Types بذكاء في مشاريعك

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

في تجربتي، أفضل الممارسات لاستخدام Utility Types هي: استخدم Partial و Required للتحكم في الإلزامية، و Pick و Omit لاستخراج الأنواع دون التضحية بالأداء، و Record و Map لبناء الهياكل الديناميكية، و Readonly لحماية البيانات من التعديل العرضي. أما بالنسبة للأدوات المتقدمة مثل Mapped Types و Conditional Types، فاستخدمها فقط عندما تحتاج لبناء أنواع ديناميكية ومعقدة، ولا تفرط في استخدامها لأنها قد تجعل الكود صعب الفهم.

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