TypeScript Advanced Types: من Generic إلى Conditional Types — ما لا يخبرك به الدليل الرسمي

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

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

الـ Generics ليست مجرد وسوم، إنها دوال من الدرجة الأولى

عندما نتحدث عن الـ Generics في TypeScript، لا نتحدث عن مجرد كتابة <T> بجانب اسم الدالة. الـ Generics هي دوال تعمل على الأنواع نفسها، تماماً كما تعمل الدوال العادية على القيم. الفرق الوحيد هو أن الـ Generics تُنفذ في وقت الترجمة (compile-time)، وليس في وقت التشغيل (runtime). هذا يعني أنك تستطيع كتابة منطق معقد يعتمد على الأنواع، وسيتم تقييمه قبل أن يصل الكود إلى المتصفح أو السيرفر.

لنأخذ مثالاً واقعياً: تخيل أنك تبني مكتبة للتعامل مع الـ API Responses. كل استجابة تأتي بشكل مختلف، لكن جميعها تشترك في هيكل أساسي: { data: T, status: number, error?: string }. بدلاً من كتابة نوع جديد لكل استجابة، يمكنك كتابة Generic واحد يعالج جميع الحالات. لكن هنا يأتي السؤال: ماذا لو أردت إضافة منطق يعتمد على نوع البيانات؟ مثلاً، إذا كان الـ data مصفوفة، أريد تطبيق دالة map عليها، وإذا كان كائناً، أريد تطبيق دالة reduce. هذا هو المكان الذي تبدأ فيه الـ Generics بالتألق.

type ApiResponse<T> = {
 data: T;
 status: number;
 error?: string;
};

function processResponse<T>(response: ApiResponse<T>): T extends any[] ? T[number][] : Partial<T> {
 if (Array.isArray(response.data)) {
 return response.data.map(item => ({ ...item })) as any;
 } else {
 return { ...response.data } as any;
 }
}

// Usage
const userResponse: ApiResponse<{ id: number; name: string }> = {
 data: { id: 1, name: 'John' },
 status: 200
};

const usersResponse: ApiResponse<{ id: number; name: string }[]> = {
 data: [{ id: 1, name: 'John' }, { id: 2, name: 'Jane' }],
 status: 200
};

const processedUser = processResponse(userResponse); // Partial<{ id: number; name: string }>
const processedUsers = processResponse(usersResponse); // { id: number; name: string }[][]

لاحظ كيف استخدمنا Generic واحد فقط (T) لكننا أضفنا منطقاً يعتمد على نوعه. المشكلة هنا هي أننا اضطررنا لاستخدام as any لتجاوز نظام الأنواع، وهذا ليس حلاً مثالياً. هذا يقودنا إلى السؤال التالي: كيف يمكننا كتابة منطق يعتمد على الأنواع دون التضحية بالأمان؟ الإجابة تكمن في Conditional Types.

Conditional Types: البرمجة الوظيفية للأنواع

الـ Conditional Types في TypeScript هي أقرب شيء إلى البرمجة الوظيفية داخل نظام الأنواع. إنها تسمح لك بكتابة تعبيرات مثل: إذا كان النوع A يمتد النوع B، فاستخدم النوع C، وإلا استخدم النوع D. هذا يبدو بسيطاً، لكنه يفتح الباب أمام إمكانيات لا محدودة. فكر في الأمر كدوال if-else، لكن للعمل على الأنواع بدلاً من القيم.

لنعد إلى مثالنا السابق. بدلاً من استخدام as any، يمكننا كتابة Conditional Type يعالج الحالة بشكل آمن. هذا ليس مجرد تحسين تجميلي، بل هو تغيير جوهري في طريقة كتابة الكود. عندما تستخدم Conditional Types، فأنت لا تكتب أنواعاً فقط، بل تكتب منطقاً يتم تنفيذه في وقت الترجمة، وهذا يعني أنك تستطيع اكتشاف الأخطاء قبل أن تحدث أصلاً.

type ProcessedType<T> = T extends any[] ? T[number][] : Partial<T>;

function processResponse<T>(response: ApiResponse<T>): ProcessedType<T> {
 if (Array.isArray(response.data)) {
 return response.data.map(item => ({ ...item })) as ProcessedType<T>;
 } else {
 return { ...response.data } as ProcessedType<T>;
 }
}

// Now TypeScript knows the exact return type
const processedUser = processResponse(userResponse); // Partial<{ id: number; name: string }>
const processedUsers = processResponse(usersResponse); // { id: number; name: string }[][]

الآن، TypeScript يعرف بالضبط نوع القيمة الراجعة لكل استدعاء. هذا ليس مجرد تحسين في الأمان، بل هو تحسين في الأداء أيضاً. لأن المترجم (compiler) يستطيع الآن إجراء تحسينات إضافية بناءً على المعلومات التي قدمتها له. مثلاً، إذا كنت تستخدم هذه الدالة في حلقة تكرارية تعالج آلاف الطلبات، فإن المترجم يستطيع تحسين الوصول إلى الخصائص (property access) بناءً على النوع المعروف مسبقاً.

الـ Distributive Conditional Types: عندما تصبح الأنواع رياضية

هناك جانب آخر من Conditional Types لا يتحدث عنه الكثيرون: الـ Distributive Conditional Types. عندما تستخدم Conditional Type مع نوع union، فإن TypeScript يطبق الشرط على كل نوع في الـ union بشكل فردي، ثم يجمع النتائج. هذا يشبه كثيراً عملية الـ map في البرمجة الوظيفية، لكنه يعمل على الأنواع بدلاً من القيم.

type ToArray<T> = T extends any ? T[] : never;

type StringOrNumber = string | number;
type StringOrNumberArray = ToArray<StringOrNumber>; // string[] | number[]

// Without distributive behavior (using tuple)
type ToArrayNonDistributive<T> = [T] extends [any] ? T[] : never;
type N ToArrayNonDistributive<StringOrNumber>; // (string | number)[]

هذا السلوك التوزيعي (distributive) هو ما يجعل Conditional Types قوية جداً. يمكنك استخدامها لبناء أنواع معقدة تعتمد على تحليل الأنواع الفرعية. مثلاً، إذا كنت تريد كتابة دالة تحول جميع الخصائص من نوع معين إلى نوع آخر، يمكنك استخدام هذا السلوك لتطبيق التحويل على كل خاصية بشكل فردي.

الـ Mapped Types و Conditional Types: ثنائي لا يقهر

عندما تجمع بين Mapped Types و Conditional Types، فإنك تدخل عالماً جديداً تماماً من إمكانيات الأنواع. الـ Mapped Types تسمح لك بتحويل كل خاصية في نوع إلى خاصية أخرى، بينما تسمح لك Conditional Types بتطبيق منطق معقد على كل خاصية. معاً، يمكنك كتابة أنواع تتعامل مع الكائنات بطريقة ديناميكية تماماً.

لنأخذ مثالاً من العالم الحقيقي: تخيل أنك تبني نظاماً لإدارة المستخدمين، وكل مستخدم لديه مجموعة من الأذونات (permissions). تريد كتابة دالة تحول جميع الأذونات من boolean إلى enum محدد. بدلاً من كتابة النوع يدوياً لكل مستخدم، يمكنك كتابة Mapped Type مع Conditional Type يقوم بالتحويل تلقائياً.

type UserPermissi {
 canRead: boolean;
 canWrite: boolean;
 canDelete: boolean;
};

enum PermissionLevel {
 Denied = 0,
 Allowed = 1
}

type MapToPermissionLevel<T> = {
 [K in keyof T]: T[K] extends true ? PermissionLevel.Allowed : PermissionLevel.Denied
};

type MappedPermissions = MapToPermissionLevel<UserPermissions>;
// {
// canRead: PermissionLevel;
// canWrite: PermissionLevel;
// canDelete: PermissionLevel;
// }

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

الـ Infer: استخراج الأنواع من الأنواع

أحد أقوى الأدوات في Conditional Types هو الكلمة المفتاحية infer. تسمح لك infer باستخراج أنواع فرعية من أنواع معقدة دون الحاجة إلى معرفتها مسبقاً. هذا يشبه كثيراً عملية الـ pattern matching في لغات مثل Rust أو Scala، لكنه يعمل على الأنواع بدلاً من القيم.

type UnwrapPromise<T> = T extends Promise<infer U> ? U : T;

type PromiseResult = UnwrapPromise<Promise<string>>; // string

type ExtractArrayType<T> = T extends (infer U)[] ? U : never;

type ArrayItem = ExtractArrayType<string[]>; // string

الـ infer ليست مجرد أداة لاستخراج الأنواع، بل هي أداة لبناء أنواع ديناميكية تعتمد على تحليل الأنواع الموجودة. مثلاً، يمكنك استخدامها لاستخراج نوع القيمة الراجعة من دالة، أو لاستخراج نوع العنصر من مصفوفة، أو حتى لاستخراج الأنواع من هياكل بيانات معقدة مثل الـ tuples أو الـ mapped types. هذه الأداة هي ما يجعل Conditional Types قوية جداً، لأنها تسمح لك بكتابة منطق يعتمد على تحليل الأنواع دون الحاجة إلى معرفتها مسبقاً.

الفخاخ والمشاكل: ما لا يخبرك به الدليل الرسمي

الـ Advanced Types في TypeScript ليست وردية دائماً. هناك العديد من الفخاخ التي يقع فيها حتى المطورون المحترفون. أحد أكبر هذه الفخاخ هو الـ Circular References في الأنواع. عندما تبدأ في كتابة أنواع معقدة تعتمد على بعضها البعض، قد تجد نفسك في موقف لا يستطيع فيه المترجم حل الأنواع بسبب حلقة مرجعية. مثلاً، إذا كتبت نوعاً يعتمد على نفسه بشكل غير مباشر، قد تحصل على خطأ غامض مثل 'Type instantiation is excessively deep and possibly infinite'.

// This will cause a circular reference error
type Circular<T> = T extends any ? Circular<T> : never;

// This is a more realistic example that can cause issues
type DeeplyNested<T> = T extends object ? { [K in keyof T]: DeeplyNested<T[K]> } : T;

// If you try to use it with a circular object, TypeScript will complain
// type CircularObject = { a: CircularObject };
// type Result = DeeplyNested<CircularObject>; // Error: Type instantiation is excessively deep

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

هناك أيضاً مشكلة الـ Type Explosion. عندما تستخدم Conditional Types مع أنواع معقدة، قد ينتهي بك الأمر بأنواع ضخمة جداً لا يمكن قراءتها أو فهمها. مثلاً، إذا كتبت Conditional Type يعالج كل حالة ممكنة في نوع union كبير، قد تحصل على نوع نهائي يحتوي على مئات الأسطر من الأنواع الفرعية. هذا ليس فقط يجعل الكود صعب القراءة، بل قد يؤثر أيضاً على أداء المترجم. الحل هنا هو استخدام تقنيات مثل الـ type mapping لتقسيم الأنواع إلى أجزاء أصغر، واستخدام الـ utility types لتبسيط الأنواع المعقدة.

• •الـ Distributive Conditional Types يمكن أن تكون مفيدة، لكنها قد تؤدي أيضاً إلى نتائج غير متوقعة إذا لم تكن حذراً. مثلاً، إذا كتبت Conditional Type يعمل على نوع union، قد تحصل على نتيجة مختلفة عما تتوقع بسبب السلوك التوزيعي.
• •الـ infer يمكن أن يكون قوياً جداً، لكنه قد يؤدي أيضاً إلى أنواع غير متوقعة إذا استخدمت بشكل غير صحيح. مثلاً، إذا استخدمت infer في سياق خاطئ، قد تحصل على never بدلاً من النوع الذي تتوقعه.
• •الـ Mapped Types مع Conditional Types يمكن أن يؤدي إلى أنواع ضخمة جداً إذا لم تكن حذراً. حاول دائماً تقسيم الأنواع المعقدة إلى أجزاء أصغر وأكثر قابلية للإدارة.
• •الـ Circular References في الأنواع يمكن أن تكون مشكلة كبيرة في المشاريع الكبيرة. حاول دائماً تجنب الأنواع التي تعتمد على نفسها بشكل مباشر أو غير مباشر.

متى تستخدم Advanced Types ومتى تتجنبها؟

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

من ناحية أخرى، إذا كنت تعمل على مشروع صغير أو نموذج أولي (prototype)، فقد لا يكون استخدام Advanced Types ضرورياً. الأنواع المعقدة يمكن أن تجعل الكود صعب القراءة والفهم، خاصة للمطورين الجدد في الفريق. بالإضافة إلى ذلك، إذا كنت تعمل في بيئة حيث الأداء في وقت الترجمة ليس مشكلة (مثل المشاريع الصغيرة)، فقد لا يكون الاستثمار في كتابة أنواع معقدة مجدياً.

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

مثال واقعي: مكتبة React Query

لنأخذ مثالاً من مكتبة مشهورة: React Query. هذه المكتبة تستخدم Advanced Types بشكل مكثف لتوفير أمان مطلق في وقت الترجمة. مثلاً، عندما تستخدم useQuery، فإن TypeScript يعرف بالضبط نوع البيانات التي ستحصل عليها، حتى لو كانت البيانات تأتي من API خارجي. هذا ليس مجرد تحسين تجميلي، بل هو تغيير جوهري في طريقة كتابة الكود. بدلاً من كتابة أنواع يدوياً لكل استجابة، يمكنك الاعتماد على النظام الذكي الذي يوفر لك React Query.

// Example inspired by React Query's type system

type QueryResult<TData, TError> = {
 data: TData | undefined;
 error: TError | null;
 isLoading: boolean;
 isError: boolean;
};

function useQuery<TData, TError = Error>(
 queryKey: string,
 queryFn: () => Promise<TData>
): QueryResult<TData, TError> {
 // Implementation details...
 return {
 data: undefined,
 error: null,
 isLoading: true,
 isError: false
 };
}

// TypeScript knows the exact type of 'data'
const { data } = useQuery<{ id: number; name: string }>('user', fetchUser);
// data is { id: number; name: string } | undefined

هذا المثال يظهر كيف يمكن استخدام Advanced Types لبناء واجهات برمجة تطبيقات (APIs) قوية وآمنة. بدلاً من كتابة أنواع يدوياً لكل استدعاء، يمكنك كتابة Generic واحد يعالج جميع الحالات. هذا ليس فقط يوفر الوقت والجهد، بل يضمن أيضاً أن جميع المطورين الذين يستخدمون المكتبة سيحصلون على أفضل تجربة ممكنة مع TypeScript.

خلاصة المهندس: نصيحة لا تقدر بثمن

إذا أخذت شيئاً واحداً من هذا المقال، فليكن هذا: الـ Advanced Types في TypeScript ليست مجرد ميزة إضافية، بل هي تغيير كامل في طريقة التفكير في بناء الأنظمة. عندما تتقن الـ Generics و Conditional Types و Mapped Types، فإنك لا تكتب كوداً فقط، بل تبني لغة برمجة خاصة بك داخل TypeScript. هذه اللغة تسمح لك بالتعبير عن منطق الأعمال بطريقة لا يمكن أن تخطئ، ليس لأنها محمية بالأنواع فقط، بل لأنها مصممة بحيث لا يمكن أن تخطئ من الأساس.

ابدأ صغيراً: اكتب Generic واحد يعالج حالة بسيطة، ثم أضف Conditional Type لمعالجة حالة خاصة. بعد ذلك، جرب استخدام Mapped Type لتحويل نوع إلى نوع آخر. كلما مارست أكثر، كلما أصبحت الأنواع التي تكتبها أقوى وأكثر مرونة. لكن تذكر دائماً: الهدف ليس كتابة أنواع معقدة، بل كتابة أنواع ذكية — أنواع تجعل الكود أكثر أماناً وأسرع وأكثر قابلية للصيانة. وإذا وجدت نفسك تكتب نوعاً لا يمكنك فهمه بعد أسبوع، فربما حان الوقت لإعادة التفكير في التصميم.