في الجزء السابق من سلسلة المنشورات هذه، ناقشنا حول الإبطال الآمن.

الآن سنشرح ونحل المشكلة الثالثة والأخيرة للسلوك الافتراضي لـ TypeScript: بقايا الكتابة الديناميكية.

سوف نغطي:

• بقايا الكتابة الديناميكية
• فحوصات المساواة الفعلية
• لا توجد تحويلات ضمنية في الشروط
• تدوين مختصر للشروط
• بدون خلط بين السلاسل والأرقام

بقايا الكتابة الديناميكية

من المفترض أن يكون TypeScript "مدققًا للنوع الثابت"، على عكس JavaScript حيث تكون الكتابة ديناميكية للغاية.

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

إذن المشكلة هي: تظل بعض أجزاء نظام الكتابة الديناميكية لـ JavaScript في TypeScript. سنقوم بالتالي بشرح كيفية منع هذه السلوكيات المتبقية لتحقيق الكتابة الثابتة الكاملة .

التحقق من المساواة الفعلية

• ESLint: eqeqeq
• Biome: مشبوه.noDoubleEquals (موصى به)

أفضل مثال على المشكلة هو التحقق من المساواة. في جافا سكريبت، == ليس بالضبط اختبار مساواة، ولكنه فحص تكافؤ:

1 == "1"; // true

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

تكون عمليات التحقق من التكافؤ هذه منطقية فقط في اللغة المكتوبة ديناميكيًا مثل JavaScript. منذ اللحظة التي نقرر فيها العمل في TypeScript، يجب استخدام اختبارات المساواة الفعلية فقط (النوع والقيمة).

1 === "1"; // false

قاعدة الوبر eqeqeq تفرضها.

يجب على الأشخاص القادمين من لغات مثل Java أو C# أو Rust توخي الحذر بشكل خاص مع هذه المشكلة، حيث أن == في JavaScript أو TypeScript لا يعني نفس المعنى في هذه اللغات. في JavaScript وTypeScript، يلزم وجود = ثالث لتحقيق نفس السلوك.

لا توجد تحويلات ضمنية في الشروط

• ESLint: @typescript-eslint/strict-boolean-expressions
• البيوم: القاعدة المفقودة

هل تعتقد أن الظروف الآن آمنة؟ للأسف لا، لأن التحويلات يمكن أن تكون ضمنية:

let tax: number | undefined = 0;

if (tax) {
  console.log("Process payment");
}
if (!tax) {
  throw new Error();
}

المثال أعلاه يعادل:

let tax: number | undefined = 0;

if (tax == true) {
  console.log("Process payment");
}
if (tax == false) {
  throw new Error();
}

كما ترون، كانت هناك == ضمنية، لذلك لا تزال التحويلات تحدث: 0 لا يعادل صحيحًا، بل يعادل خطأ. لذلك سوف يحدث خطأ على الرغم من كون الضريبة قيمة صالحة.

لا تسمح قاعدة التعبيرات المنطقية الصارمة بمثل هذه الشروط الضمنية، وتفرض فحوصات فعلية:

let tax: number | undefined = 0;

if (tax !== undefined) {
  console.log("Process payment");
}
if (tax === undefined) {
  throw new Error();
}

قد تكون هذه إحدى القواعد الأكثر مملة التي يجب اتباعها للأشخاص المعتادين على الشروط السريعة في JavaScript، ولكن لوضعها في منظورها الصحيح، فهي مجرد طريقة عادية للقيام بالأشياء بلغات أخرى مثل Java أو C# أو Rust.

كما هو موضح في جزء التكوين، يعد تعطيل الخيارين الفرعيينallowNumber وallowString أمرًا مهمًا لتجنب جميع الأخطاء.

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

let movie: Movie | undefined;
if (movie) {}
if (!movie) {}

ملاحظة: عبارات التبديل آمنة بالفعل لأنها تستخدم === داخليًا.

الشروط تدوين مختصر

• ESLint: @typescript-eslint/prefer-nullish-coalescing (تم تحديد النوع الأسلوبي)
• البيوم: القاعدة المفقودة

تحرص قاعدة lint الصارمة للتعبيرات المنطقية على أن تكون عمليات التحقق من الشروط آمنة للكتابة، ولكن هناك صيغ جمل شروط أخرى غير إذا:

const movieRating = userRating || 5;

// Which is a shorter version of:
const movieRating = userRating == true ? userRating : 5;

إذا قام المستخدم بتقييم 0، فإن 0 يعادل خطأ، لذلك سيكون التقييم 5 بدلاً من 0.

يمكن تجنب ذلك باستخدام جافا سكريبت الحديثة:

const movieRating = userRating ?? 5;

// Which is a shorter version of:
const movieRating = userRating !== undefined && userRating !== null
  ? userRating
  : 5;

يمكن فرضه من خلال قاعدة الوبر المفضلة للدمج.

لاحظ أن ؟؟ لا ينبغي أن تستخدم في كل مكان: || لا تزال ذات صلة عند العمل مع القيم المنطقية.

لا توجد سلاسل وأرقام مختلطة

• إي إس لينت:
  • النموذج المفضل
  • @typescript-eslint/restrict-plus-operands (في النوع الموصى به الذي تم التحقق منه)
  • @typescript-eslint/restrict-template-expressions (في النوع الموصى به الذي تم التحقق منه)
• البيوم:
  • style.useTemplate (موصى به)
  • قواعد أخرى مفقودة

في جافا سكريبت، يمكن استخدام عامل التشغيل للجمع الرياضي للأرقام أو لتسلسل السلاسل. يؤدي إلى الخطأ.

"There is "   3   1   "Matrix movies"; // 31
"There is "   (3   1)   "Matrix movies"; // 4

يجب أن يكون العامل محجوزًا للإضافة الرياضية. أو على الأقل، يجب استخدامه فقط مع البيانات من نفس النوع، والتي تفرضها قاعدة تقييد زائد المعاملات.

يجب استخدام سلاسل القالب من جافا سكريبت الحديثة لتسلسل السلسلة، والتي تفرضها قاعدة لينت القالب المفضل:

const movie = `Everything everywhere all at once`;
`${movie} is the best movie!`;

على العكس من ذلك، يجب استخدام السلاسل فقط في سلاسل القالب، والتي تفرضها قاعدة تقييد تعبيرات القالب.

إذا كانت أنواع الخلط هي ما هو مطلوب بالفعل، فيجب أن تكون التحويلات صريحة:

const total = 3;
`There is ${total.toFixed()} Matrix movies`;

لاحظ أنه يمكن تداخل سلاسل القالب:

const total = 3;
`There is ${total.toFixed()} Matrix movie${total > 1 ? "s" : ""}`;

خاتمة

هذه نهاية سلسلة المشاركات. يمكنك متابعة حسابي (الزر الموجود أعلى يمين هذه الصفحة) لمعرفة متى يتم نشر منشورات أخرى حول TypeScript أو موضوعات أخرى مثل Angular.

هل تريد الاتصال بي؟ التعليمات متوفرة في الملخص.