Tslint: لا ينبغي التوصية بالواجهة فوق النوع الحرفي

آسف ، لا أفهم ما تعنيه. هل هذا طلب ميزة أم تقرير خطأ؟

القيمة الافتراضية للواجهة فوق النوع الحرفي في recommended.ts صحيحة. أعتقد أنه يجب أن يكون خطأ. لست متأكدًا مما إذا كان ذلك يمثل طلب ميزة أم خطأ :-)

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

على أي حال ، فإن تعطيل القاعدة سيكون بمثابة تغيير جذري. لذلك لا تتوقع أي تغيير قبل الإصدار الرئيسي التالي.

للتوضيح: interface-over-type-literal يشكو فقط من تعريفات الاسم المستعار.

type Foo = {foo: number}; // The rule disallows this
interface Foo {foo: number} // and fixes it to this

let obj: {foo: number}; // This is still allowed

نظرًا لأنه يمكن استخدام الاسم المستعار للنوع والواجهة (تقريبًا) بالتبادل ، لا أرى سبب تفضيلك للاسم المستعار للنوع.

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

أعلم أنه يمكنني تجاوزها ، لكنني أشعر بقوة أن التوصية غير صحيحة.

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

سيكون من الأنظف في رأيي أن أستخدم اسمًا مستعارًا لنوع الاسم المستعار وواجهة للواجهة ، بدلاً من استبدال أحدهما بالآخر في بعض الحالات لمجرد أن الواجهات لديها بعض الإمكانيات الإضافية (التي لست بحاجة إليها إذا كان كل ما تريد هو اسم مستعار من النوع).

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

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

هذا أحد الأشياء التي أخطأت فيها الكتابة المطبوعة في رأيي ، وهذا مربك لمفهوم الواجهة ، التي تعني دلالاتها في جميع اللغات الآمنة الأخرى التي استخدمتها ، "مجموعة من الأساليب / الوظائف / الأشياء القابلة للاستدعاء" ، مع توقيع الكائن / نوع البطة. يجب أن يكون استخدام الواجهة أكثر تقييدًا ، وسأرحب حقًا بقاعدة TSLint "واجهة - يجب - تعلن - وظائف فقط" ، أو "واجهة - يجب - إعلان - على الأقل - وظيفة واحدة" أقل تقييدًا

يجب التصريح عن الهياكل النقية باستخدام عامل تشغيل النوع وتمديدها باستخدام عامل التشغيل &. ويجب أن يبدأ الاسم بـ "T" :-)

navels أوافق على ملاحظاتك ، أعتقد أن tslint:recommended يجب أن يزيل تكوين القاعدة المفرط في الرأي كتغيير جذري في الإصدار الرئيسي التالي

كيف يمكنني تجاوز هذا الخيار؟

sibelius في tslint.json ، أقل "rules" ، ضع علامة عليه كـ false :

{
    "extends": ["tslint:recommended"],
    "rules": {
        "interface-over-type-literal": false
    }
}

لاحظ أن هذه المشكلة تتعقب تعطيل القاعدة في مجموعة القواعد الموصى بها. إذا كانت لديك أسئلة عامة حول TSLint ، فيرجى استخدام StackOverflow أو Gitter.

هنا يتحدث شخص ما عن هذا الموضوع https://medium.com/@martin_hotell/interface -vs-type-alias-in-typescript-2-7-2a8f1777af4c

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

لقد كنت أكتب كود OOP أقل وأقل لدرجة أنني لا أستخدمه على الإطلاق في مشروعي الحالي.
لا أريد أن يتم دفع المبتدئين نحو ذلك.

dandrei وأنا أستخدم Interfaces فقط ، عندما أريد وصف الوظائف (لا أستخدم OOP أيضًا).

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

التوصية تكسر الشفرة بالفعل. انصح:

type Foo = {
  foo: string
}

interface IndexedObject {
  [key: string]: string
}

function useIndexedObject(object: IndexedObject) {}

const foo: Foo = {foo: "foo"}
useIndexedObject(foo)

يعمل الرمز أعلاه. حتى يتم تطبيق tslint --fix وتغيير type Foo إلى interface Foo ، يظهر السطر الأخير الخطأ:

Argument of type 'Foo' is not assignable to parameter of type 'IndexedObject'.
  Index signature is missing in type 'Foo'.

IMO ، أي قاعدة تكسر الكود لا ينبغي أن تكون توصية. هيك ، لا ينبغي أن تكون قاعدة إذا كان لديها القدرة على كسر الكود.

ليس ذلك فحسب ، بل يتسبب أيضًا في أن الواجهات يجب أن تبدأ بقاعدة "أنا".

error TS2344: ...
Index Signature is missing in type 'SOME INTERFACE'.

لذلك لا بد لي من استخدام الكتابة .

إذا كانت تطبيقاتك تستخدم الكثير من type ، فهذا مؤشر جيد على انتهاكات مبادئ SOLID.

إزالة التصنيف Type: Breaking Change لكل # 4811. تقبل الآن العلاقات العامة!

فلماذا يطلق عليه TypeScript ، عندما يجب أن يسمى InterfaceScript ؟! 🤣