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

في أحد المشاريع الكبيرة الذي عملت عليه مع فريق دولي، كنا نستخدم TypeScript لبناء نظام معالجة بيانات ضخم. بعد أشهر من التطوير، بدأنا نلاحظ أن الـ Build Time زاد من ٣٠ ثانية إلى أكثر من ٥ دقائق! المشكلة؟ كنا نستخدم الـ Generics بشكل مفرط دون فهم حقيقي لكيفية تعامل الـ Type Checker معها. هذا ليس خطأ في TypeScript، بل خطأ في فهمنا لكيفية عمل النظام تحت الغطاء. اليوم، لن نتحدث عن الأساسيات — سنتجاوز ذلك لنرى كيف يمكن للـ Advanced Types أن تحول كودك من مجرد "نوع آمن" إلى كود ذكي يتكيف مع السياق دون تكرار أو تعقيد غير ضروري.

الـ Generics ليست مجرد أداة لجعل الكود "قابل لإعادة الاستخدام" — إنها آلية للتحكم في تدفق المعلومات النوعية عبر نظامك. عندما تكتب دالة مثل `function identity<T>(arg: T): T`، فأنت لا تخبر TypeScript فقط أن هناك نوعاً عاماً، بل تطلب منه إنشاء نسخة جديدة من الدالة لكل نوع يتم استخدامه معه. هذا يعني أن كل استدعاء لـ `identity<string>("hello")` يولد نسخة مخصصة في الذاكرة، بينما `identity<number>(42)` يولد نسخة أخرى. هذا السلوك، الذي يبدو بسيطاً، هو ما يجعل الـ Generics قوية وخطيرة في نفس الوقت.

الـ Generics: أكثر من مجرد متغيرات للنوع

الكثير من المطورين يستخدمون الـ Generics كمتغيرات للنوع فقط، لكن قوتها الحقيقية تكمن في القدرة على التعبير عن العلاقات بين الأنواع. خذ مثلاً دالة `pick` التي تختار خصائص معينة من كائن. النسخة البسيطة قد تبدو هكذا: `function pick<T, K extends keyof T>(obj: T, keys: K[]): Pick<T, K>`، لكن ماذا لو أردنا تحسينها لتتعامل مع الكائنات المتداخلة؟ هنا يأتي دور الـ Mapped Types والـ Conditional Types. المشكلة أن معظم الأمثلة على الإنترنت تتوقف عند المستوى السطحي، بينما في الواقع، تحتاج إلى فهم كيف يتعامل الـ Type Checker مع هذه العلاقات.

في مشروع سابق، كنا نعمل على مكتبة لإدارة الـ State في تطبيقات الويب، ووجدنا أنفسنا نكتب دوال مثل `getNestedValue` التي تستخرج قيمة من مسار متداخل داخل كائن. بدون الـ Generics، كنا سنضطر لكتابة نسخة مختلفة لكل عمق، لكن باستخدام الـ Generics مع الـ Recursive Types، استطعنا كتابة دالة واحدة تتعامل مع أي عمق. الكود كان شيئاً مثل هذا:

type NestedPath<T, K extends keyof T = keyof T> =
 K extends string
 ? T[K] extends Record<string, any>
 ? `${K}.${NestedPath<T[K]>}` | K
 : K
 : never;

function getNestedValue<T extends Record<string, any>, P extends NestedPath<T>>(
 obj: T,
 path: P
): P extends `${infer K}.${infer Rest}`
 ? K extends keyof T
 ? Rest extends NestedPath<T[K]>
 ? getNestedValue<T[K], Rest>
 : never
 : never
 : P extends keyof T
 ? T[P]
 : never;

const data = { user: { profile: { name: "Ahmed", age: 30 } } };
const name = getNestedValue(data, "user.profile.name"); // string

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

الـ Conditional Types: منطق البرمجة داخل النظام النوعي

الـ Conditional Types هي المكان الذي يتحول فيه TypeScript من مجرد أداة للتحقق من الأنواع إلى لغة برمجة كاملة داخل النظام النوعي. عندما تكتب نوعاً مثل `type IsString<T> = T extends string ? true : false`، فأنت في الواقع تكتب برنامجاً صغيراً ينفذ في وقت التحقق من الأنواع. لكن ما لا يخبرك به الدليل الرسمي هو أن هذه الأنواع لا تعمل بنفس الطريقة التي تعمل بها الشروط في وقت التشغيل. على سبيل المثال، إذا كان لديك نوع مثل:

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

فإنه يعمل بشكل رائع مع المصفوفات البسيطة، لكن ماذا لو كان لديك مصفوفة من الـ Unions؟ مثلاً: `ExtractArrayType<(string | number)[]>` سيعيد `string | number`، وهذا منطقي. لكن ماذا عن `ExtractArrayType<[string, number]>`؟ هنا، النتيجة ستكون `string | number` أيضاً، وليس `never` كما قد يتوقع البعض. السبب هو أن الـ Conditional Types في TypeScript تعمل على أساس الـ Distributive Nature — أي أنها تطبق الشرط على كل عنصر في الـ Union بشكل منفصل ثم تجمع النتائج.

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

type ApiResponse<T> = T extends { 200: infer R } ? R : never;

type UserResp ApiResponse<{
 200: { name: string };
 404: { error: string };
}>; // { name: string }

هذا يبدو جيداً، لكن عندما أضفنا حالة أخرى مثل `500`، لاحظنا أن النظام بدأ في توليد أنواع غير متوقعة. السبب؟ الـ Conditional Types كانت توزع على كل حالة من حالات الـ Status Codes، مما أدى إلى نتائج غير مرغوبة. الحل كان استخدام الـ Non-Distributive Conditional Types عن طريق لف النوع في مصفوفة: `T extends [infer R] ? R : never`. هذا منع الـ Distribution وجعل النظام يعمل كما هو متوقع.

الـ Type Inference: كيف يخمن TypeScript ما لا تخبره به

الـ Type Inference هو ما يجعل TypeScript مريحة الاستخدام، لكنه أيضاً ما يجعلها معقدة في بعض الأحيان. عندما تكتب `const x = 5`، فإن TypeScript يستنتج أن نوع `x` هو `5` وليس `number`. هذا يسمى الـ Literal Type Inference، وهو مفيد جداً في بعض الحالات، لكنه قد يسبب مشاكل في حالات أخرى. على سبيل المثال، إذا كنت تستخدم الـ Generics مع الدوال، فقد تجد أن الـ Inference لا يعمل كما تتوقع:

function map<T, U>(arr: T[], fn: (item: T) => U): U[] {
 return arr.map(fn);
}

const result = map([1, 2, 3], x => x.toString()); // string[]

هذا يعمل بشكل جيد، لكن ماذا لو أردنا تحسين الدالة لتتعامل مع الـ Promises؟ قد نكتب شيئاً مثل:

async function mapAsync<T, U>(
 arr: T[],
 fn: (item: T) => Promise<U>
): Promise<U[]> {
 return Promise.all(arr.map(fn));
}

const result = await mapAsync([1, 2, 3], async x => x.toString()); // Promise<string[]>

هنا، الـ Inference يعمل بشكل جيد، لكن المشكلة تظهر عندما تحاول استخدام هذه الدالة مع أنواع أكثر تعقيداً. على سبيل المثال، إذا كان لديك مصفوفة من الكائنات، وقد تريد تحويلها إلى مصفوفة من الـ Promises تحتوي على قيم معينة، فقد تجد أن الـ Inference يفشل في استنتاج الأنواع الصحيحة. الحل؟ استخدام الـ Explicit Types في بعض الأحيان، أو تحسين الدالة باستخدام الـ Conditional Types لجعل الـ Inference أكثر ذكاءً.

متى يفشل الـ Inference؟

الـ Inference يفشل غالباً في الحالات التي يكون فيها السياق غير واضح. على سبيل المثال، إذا كنت تستخدم الـ Generics مع الـ Function Overloads، فقد تجد أن الـ Inference لا يعمل كما تتوقع. خذ هذا المثال:

function process<T>(input: T): T extends string ? number : boolean;
function process(input: any) {
 return typeof input === "string" ? input.length : true;
}

const x = process("hello"); // number
const y = process(42); // boolean

هذا يعمل بشكل جيد، لكن إذا حاولت استخدام هذه الدالة مع نوع غير معروف مسبقاً، مثل `unknown`، ستجد أن الـ Inference يفشل. السبب هو أن الـ Conditional Types في الـ Overload لا يتم تقييمها إلا بعد اختيار الـ Signature المناسبة، وهذا قد يؤدي إلى أنواع غير متوقعة. الحل؟ تجنب الـ Overloads المعقدة واستخدم بدلاً منها الـ Function Signatures مع الـ Conditional Types مباشرة.

الـ Performance: متى تصبح الـ Advanced Types عبئاً؟

الـ Advanced Types ليست مجانية. كلما زاد تعقيد الأنواع التي تستخدمها، زاد الوقت الذي يستغرقه الـ Type Checker في تحليلها. في مشروع كبير عملت عليه، كنا نستخدم الـ Mapped Types والـ Conditional Types لبناء نظام توليد أنواع ديناميكي. بعد بضعة أشهر، لاحظنا أن وقت البناء زاد من ٤٥ ثانية إلى أكثر من ١٠ دقائق! السبب؟ كنا نستخدم الـ Recursive Types مع الـ Conditional Types بطريقة تولد عدداً هائلاً من الأنواع الوسيطة.

الـ Type Checker في TypeScript ليس مصمماً للتعامل مع الأنواع المعقدة بشكل لا نهائي. عندما تكتب نوعاً مثل:

type DeepReadonly<T> = T extends object
 ? { readonly [K in keyof T]: DeepReadonly<T[K]> }
 : T;

فإن الـ Type Checker سيحاول إنشاء نسخة readonly من كل خاصية في الكائن، بما في ذلك الكائنات المتداخلة. هذا يبدو جيداً في البداية، لكن إذا كان لديك كائن عميق جداً، مثل شجرة مكونات في React، فإن هذا النوع يمكن أن يولد آلاف الأنواع الوسيطة، مما يؤدي إلى تباطؤ كبير في الـ Build Time. الحل؟ استخدام الـ Type Aliases لتقليل التعقيد، أو تقسيم الأنواع الكبيرة إلى أجزاء أصغر.

كيف تقيس تأثير الأنواع على الأداء؟

إذا كنت تشك في أن الـ Advanced Types تؤثر على أداء الـ Build، يمكنك استخدام أداة مثل `typescript-performance-testing` لقياس الوقت الذي يستغرقه الـ Type Checker في تحليل الأنواع المختلفة. على سبيل المثال، يمكنك كتابة اختبار بسيط مثل:

import { performance } from 'perf_hooks';

const start = performance.now();
// ضع هنا النوع المعقد الذي تريد قياسه
type ComplexType = ...;
const end = performance.now();
console.log(`Time taken: ${end - start}ms`);

هذا ليس دقيقاً تماماً، لكنه يعطيك فكرة عن الأنواع التي تستغرق وقتاً أطول. في تجربتي، وجدت أن الـ Recursive Types والـ Conditional Types التي تعتمد على الـ Unions الكبيرة هي الأكثر تأثيراً على الأداء. إذا كنت تعمل على مشروع كبير، ففكر في استخدام الـ TypeScript Configuration لتقليل التعقيد، مثل ضبط `strictFunctionTypes` أو `noImplicitAny` بشكل أكثر دقة.

الـ Real-World Use Cases: أين تستخدم الـ Advanced Types فعلاً؟

الـ Advanced Types ليست مجرد أكاديمية — إنها أداة قوية تستخدم في مكتبات ومشاريع حقيقية. على سبيل المثال، مكتبة `zod` تستخدم الـ Generics والـ Conditional Types لبناء نظام تحقق من الأنواع في وقت التشغيل. المكتبة تسمح لك بكتابة كود مثل:

import { z } from 'zod';

const userSchema = z.object({
 name: z.string(),
 age: z.number().min(18),
});

type User = z.infer<typeof userSchema>; // { name: string; age: number }

هنا، `z.infer` هو نوع يستخدم الـ Conditional Types لاستنتاج النوع من الـ Schema الذي قمت بتعريفه. هذا ليس مجرد كود أنيق — إنه نظام يقلل من التكرار ويضمن أن الأنواع في وقت التشغيل تتطابق مع الأنواع في وقت التحقق. مكتبة أخرى تستخدم الـ Advanced Types بشكل مكثف هي `react-query`، التي تستخدم الـ Generics لبناء أنواع ديناميكية تعتمد على الـ API Responses.

في مشروع آخر، كنا نعمل على نظام لإدارة الـ Forms في تطبيق React كبير. كنا نستخدم مكتبة `react-hook-form`، لكننا وجدنا أن الأنواع التي توفرها ليست كافية للتعامل مع الـ Forms المعقدة التي تحتوي على حقول متداخلة وحقول شرطية. الحل؟ كتبنا مكتبة صغيرة تستخدم الـ Generics والـ Conditional Types لبناء أنواع ديناميكية تتكيف مع هيكل الـ Form. الكود كان شيئاً مثل:

type FormValues<T extends Record<string, any>> = {
 [K in keyof T]: T[K] extends Record<string, any>
 ? FormValues<T[K]>
 : T[K] extends { value: infer V; enabled: boolean }
 ? V
 : T[K];
};

const formC {
 name: "Ahmed",
 age: { value: 30, enabled: true },
 address: {
 city: "Cairo",
 street: { value: "Main St", enabled: false },
 },
};

type FormType = FormValues<typeof formConfig>;
// {
// name: string;
// age: number;
// address: {
// city: string;
// street: string;
// };
// }

هذا النوع يستخرج القيم الفعلية من الـ Form Config، مع تجاهل الحقول التي تكون `enabled: false`. النتيجة هي نوع دقيق يتطابق تماماً مع البيانات التي سترسل إلى الـ Backend. هذا النوع من الأنظمة هو ما يجعل الـ Advanced Types لا غنى عنها في المشاريع الكبيرة.

خلاصة المهندس: نصائح لا تجدها في الوثائق الرسمية

الـ Advanced Types في TypeScript هي أداة قوية، لكنها ليست حلاً سحرياً. استخدمها بحكمة، وافهم كيف تعمل خلف الكواليس لتجنب المشاكل في الإنتاج. نصيحتي الأولى: لا تستخدم الـ Recursive Types إلا إذا كنت مضطراً، واستخدم الـ Type Aliases لتقليل التعقيد. الثانية: إذا وجدت نفسك تكتب أنواعاً معقدة جداً، فاسأل نفسك إذا كان هناك طريقة أبسط لتحقيق نفس الهدف — غالباً ما تكون الإجابة نعم. الثالثة: اختبر أنواعك في بيئة قريبة من الإنتاج، لأن الـ Build Time يمكن أن يكون مشكلة حقيقية في المشاريع الكبيرة.

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