TypeScript — أرخص توثيق ستشتريه

ما هي TypeScript؟

لا تتحقق JavaScript من نوع ما يحمله المتغير. فإن توقعت دالة كائن عميل وتلقّت النص "undefined"، فستمضي JavaScript مرتاحة وتفشل بعد ثلاث دوال، في مكان غير ذي صلة، في الثانية فجرًا. وهذا أشيع صنف من أخطاء الإنتاج في برمجيات الويب.

يضيف TypeScript وصفًا لما يفترض أن يكون كل شيء، ويتحقق منه أثناء الكتابة، ثم يُترجم إلى JavaScript عادية. ولا يُرسل شيء إضافي إلى المتصفح. فالأنواع موجودة للناس وللأدوات، لا لزمن التشغيل.

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

متى نختار TypeScript

دائمًا. لا يوجد حجم مشروع نوصي عنده بـ JavaScript عادية، وهذا ليس تعصبًا — بل لأن كلفة TypeScript بضع ساعات إعداد، وكلفة غيابه تُدفع في الإنتاج، مرارًا، على يد من يرث الكود.

ويهم أكثر ما يهم في المشاريع التي تهم العملاء أكثر: أي شيء فيه دفع، أو فحص صلاحية، أو تبادل بيانات بين نظامين. فهذه بالضبط المواضع التي يسبب فيها تغيّر شكل حقل بهدوء خسارة حقيقية، وبالضبط المواضع التي يلتقطه فيها TypeScript على لوحة المفاتيح.

ويهم أيضًا حين نسلّم مشروعًا. فقاعدة كود بأنواع تخبر مطوّرك التالي بما هو كل شيء دون أن يقرأ كل دالة. وهذا الفارق بين تسليم ومشروع تنقيب أثري.

متى لا نستخدم TypeScript

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

والكلفة الحقيقية الأخرى فريق لم يستخدمه قط. فـ TypeScript يبطئ مطوّر JavaScript نحو أسبوعين. وإن كان فريق العميل الداخلي على JavaScript عادية ولا رغبة له في التعلم، ففرضه عليهم ينتج كودًا مليئًا بـ any، وهو أسوأ الاثنين: خطوة البناء بلا الأمان. وفي تلك الحالة نقول ذلك ونبني بـ JavaScript عادية مع تدقيق أصرم.

ما الذي نبنيه بـ TypeScript

عقود API بأنواع بين الواجهة والخلفية

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

واجهات كبيرة تبقى قابلة للتغيير

في تطبيق بمئة شاشة، السؤال ليس أبدًا «هل نستطيع بناءه» بل «هل نستطيع تغييره في السنة الثالثة». والأنواع تجعل إعادة التسمية آمنة وإعادة الهيكلة ممكنة، وهذا ما يمنع قاعدة الكود من التحجر إلى شيء لا يجرؤ أحد على مسّه.

منطق مشترك بين الويب والجوال

حين يكون للمشروع تطبيق ويب وتطبيق React Native، تُكتب قواعد التحقق ومنطق التسعير وطبقة الـ API مرة واحدة وبأنواع واحدة. فتحصل المنصتان على السلوك نفسه بحكم البناء لا بحكم تذكّر فريقين للمطابقة.

أنواع مشتركة بين الواجهة والواجهة البرمجية

تعريف واحد لشكل الطلب، يستخدمه الطرفان. أعِد تسمية حقل فيخبرك البناء بكل موضع يجب تغييره — وهذه أنفع فائدة للأنواع في مشروع حقيقي.

كيف نطلق مشاريع TypeScript

الوضع الصارم مفعّل من أول commit. فتفعيله لاحقًا يعني إصلاح مئات الأخطاء دفعة واحدة، وهو ما لا يفعله أحد، فيبقى المشروع بهدوء نصف مكتوب بأنواع إلى الأبد.

ويُعامَل any كرائحة كود في المراجعة. فهو يُطفئ مدقق الأنواع لتلك القيمة، وقاعدة كود منثور فيها any تحمل كلفة بناء TypeScript بلا أي فائدة منه.

وتُولَّد الأنواع من مصدر الحقيقة حيثما أمكن — من مخطط قاعدة البيانات، أو من تعريف الـ API — بدل كتابتها يدويًا في موضعين ينحرفان عن بعضهما.

ما تكلّفك TypeScript

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

كما لا يستطيع التحقق مما يحدث عند الحدود. فالبيانات الواصلة من API هي ما أرسله الخادم فعلًا، بغض النظر عما يقول النوع إنه ينبغي أن يكون. لذا نتحقق عند تلك الحدود في زمن التشغيل بدل الوثوق بالنوع، لأن النوع وعد والشبكة لا تفي بالوعود.

أسئلة تُطرح علينا عن TypeScript