تحديث: إذا أعجبك هذا المنشور، قم بالمتابعة – ‘تأثير بدون تأثير-TS: التفكير الجبري في TypeScript عادي – نستأنف من حيث توقفنا ونأخذ الأفكار إلى أبعد من ذلك.’
لقد كنت أفكر في أليكسيس كينغ ‘تحليل، لا التحقق من صحة مرة أخرى. أفعل هذا بانتظام، في الواقع، عادةً بعد التحديق في قاعدة بيانات TypeScript التي كانت تتراكم بهدوء if (user.email) الشيكات مثل البرنقيل. المنشور من عام 2019، والنصيحة (أو بالأحرى المبدأ) أقدم من ذلك بكثير. ومع ذلك، فإن معظم TypeScript التي قرأتها – بما في ذلك الكثير مما كتبته، وهو أمر محرج – لا يزال يتم التحقق من صحته بدلاً من التحليل.
المدقق الذي كتبناه جميعًا
إليك نوع الكود الذي أراه (وأكتبه) باستمرار: واجهة مستخدم { بطاقة تعريف: رقم; بريد إلكتروني: خيط; عمر: رقم; }// التحقق الفعلي ساذج ومبسط، لكنك فهمت النقطة: وظيفة isValidUser(المستخدم: مستخدم): منطقية { لو (!user.email.includes(‘@’)) يعود خطأ شنيع; لو (user.age < 0 || user.age > 150) يعود خطأ شنيع; يعود حقيقي; }
ما نريده فعلا
نريد هذا: وظيفة أرسل مرحبًا (المستخدم: مستخدم صالح) { emailService.send(user.email, `مرحبا يا عمر ${user.age}`); }
الأنواع ذات العلامات التجارية، أو: الكذب على نظام النوع الهيكلي عمداً
يتم كتابة TypeScript هيكليًا، مما يعني أن هناك نوعين لهما نفس الشكل هما نفس النوع. string يكون string يكون string. لا يوجد newtype. لا يوجد type EmailAddress=String التي تنتج نوعًا متميزًا حقًا بالطريقة التي يفعلها هاسكل على سبيل المثال.
حيث يحاربك TypeScript
بعض الأشياء لا تزال صر. الأول هو ذلك as Email يلقي في الداخل parseEmail. في اللغة الاسمية الحقيقية، لا يتعين على المنشئ الذكي أن يكذب – فهو يُرجع النوع الجديد لأن النوع الجديد مختلف تمامًا. في TypeScript، العلامة التجارية خيالية، لذا عليك أن تشق طريقك لتجاوزها.
وماذا عن زود؟
زود عظيم. وكذلك الأمر بالنسبة إلى io-ts. وكذلك فاليبوت. استخدمها. إنها النسخة المريحة لكل ما كتبته للتو – خط DSL أول مخطط يمنحك محللًا ونوع TypeScript من نفس التعريف:
المبدأ الأصغر
إذا اضطررت إلى ضغط فكرة كينغ في جملة كنت سأتذكرها بالفعل في الساعة 11 مساءً قبل الإصدار: اجعل نظام الكتابة يحمل الدليل وليس ذاكرتك.