reactjs - ما هو الغرض من `string & {}`

كنت أحاول كتابة تلميح نوع لخاصية CSS gridTemplateColumns، وفي أحد تبعيات React المسماة csstype وجدت تعريف الخاصية التالي:

  gridTemplateColumns?: Property.GridTemplateColumns<TLength> | undefined;

هذه خاصية من واجهة البرمجة التالية، حيث يتم إعلان TLength و TTime.

export interface StandardLonghandProperties<TLength = (string & {}) | 0, TTime = string & {}> {

لا أفهم ما الذي يحاول string & {} تحقيقه. كيف يختلف عن مجرد string عادي؟

الإجابة رقم 1

لأن نوع الكائن الفارغ المزعوم {} يستبعد فقط null و undefined (انظر كيف تفهم العلاقات بين الأنواع any و unknown و {} وبينها وبين الأنواع الأخرى؟)، فإن التقاطع string & {} يعادل string من حيث القيم التي يقبلها. لذلك، لأغراض معظم الاستخدامات، لا يوجد فرق بين string و string & {} وبالتالي لا يوجد سبب لاستخدام النوع الأكثر تعقيدًا.

ولكن على الرغم من أن string & {} قد يُعتبر نفس string، فإن المترجم لا يقلل الأول إلى الأخير على الفور، كما يفعل مع، على سبيل المثال، string & unknown (حيث يتم امتصاص النوع unknown بواسطة التقاطع مع string)، أو كما يفعل مع أنواع الاتحاد مثل string | "x" (حيث يتم امتصاص نوع النص الحرفي "x" بواسطة الاتحاد مع string)

إحدى استخدامات string & {} هي منع بعض هذه التخفيضات السريعة لغرض الاقتراح التلقائي/الإكمال التلقائي في IntelliSense ولأغراض التوثيق. النوع (string & {}) | "x" يسمح بالقيم نفسها مثل string، ولكنه لا يزال يحتفظ بما يكفي من "الذاكرة" لنوع "x" ليتم اقتراحه بواسطة بيئة تطوير متكاملة تدعم IntelliSense. تم ذكر هذه التقنية في microsoft/TypeScript#29729 كحل بديل لغياب الدعم الأصلي للإكمال التلقائي لاتحادات الحروف النصية مع string.

مع ذلك، في حالة (string & {}) | 0 و string & {} كما هو موضح في تعريف واجهة StandardLonghandProperties في frenic/csstype، يبدو ذلك غير مبرر. لا يوجد فرق في IntelliSense الذي سيقترح عليك بالنسبة لـ (string & {}) | 0 فقط و string | 0 (نظرًا لأن 0 هو ثابت رقمي فإنه لا يتم امتصاصه في الاتحاد)، وبالتأكيد لا يوجد فرق في اقتراحات IntelliSense بالنسبة لـ string & {} و string فقط، لأنه لا توجد أي ثوابت يمكن اقتراحها على الإطلاق.

إذا، لماذا هو هكذا؟ إذا نظرت إلى مشكلة frenic/csstype#73، يبدو أن هناك العديد من الأماكن التي تستخدم اتحاد الحروف النصية مع string، حيث عانى IntelliSense. من الواضح أن frenic/csstype لديها نظام بناء خاص بها لـ توليد ملف إعلان TypeScript. لذا كان الحل في frenic/csstype#74 هو مجرد تغيير رمز التوليد بحيث بدلاً من مجرد أنواع string و number، سيولد (string & {}) و (number & {}).

هذا يعني أنه لا يوجد حقًا سبب كبير لـ string & {} في الكود الذي تنظر إليه. إذا أراد مطورو frenic/csstype، يمكنهم تغيير الكود بحيث تُترك string و number كما هي في الأماكن التي ليست جزءًا من اتحاد مع الثوابت من نفس النوع الأساسي. بمعنى آخر، يمكنهم التأكد من أن & {} يظهر فقط في الأماكن التي يحسن فيها اقتراحات IntelliSense.

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