Tslint: इंटरफ़ेस-ओवर-टाइप-शाब्दिक अनुशंसा नहीं की जानी चाहिए

क्षमा करें, मुझे आपका मतलब समझ में नहीं आया। क्या यह सुविधा अनुरोध या बग रिपोर्ट है?

अनुशंसित.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 को परिभाषित कर रहा हूं अवयव।

मैं इस बिंदु पर कम से कम ओओपी कोड लिख रहा हूं कि मैं इसे अपने वर्तमान प्रोजेक्ट में बिल्कुल भी उपयोग नहीं कर रहा हूं।
मैं नहीं चाहता कि शुरुआती लोग इसके प्रति आकर्षित हों।

@dandrei और मैं केवल इंटरफेस का उपयोग करता हूं, जब मैं कार्यों का वर्णन करना चाहता हूं (मैं भी ओओपी का उपयोग नहीं करता)।

हाँ, यह निश्चित रूप से गलत है और आईएमओ अनुशंसित का हिस्सा नहीं होना चाहिए, या कम से कम ऑटो-फिक्स नहीं होना चाहिए ताकि हम इसे हमारे प्रकारों को पकड़ने से पहले अक्षम कर सकें।

सिफारिश वास्तव में कोड तोड़ती है। विचार करना:

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'.

आईएमओ, कोड तोड़ने वाला कोई भी नियम अनुशंसा नहीं होना चाहिए। बिल्ली, यह एक नियम भी नहीं होना चाहिए यदि इसमें कोड तोड़ने की क्षमता है।

इतना ही नहीं, बल्कि यह "इंटरफ़ेस को 'I' से शुरू होना चाहिए" नियम का भी कारण बनता है।

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

इसलिए मुझे टाइप का उपयोग करना होगा।

यदि आपके ऐप्स का बहुत अधिक type उपयोग होता है, तो यह SOLID सिद्धांतों के उल्लंघन का एक अच्छा संकेतक है।

Type: Breaking Change लेबल प्रति #4811 को हटाया जा रहा है। अब पीआर स्वीकार कर रहे हैं!

तो इसे टाइपस्क्रिप्ट क्यों कहा जाता है, जब इसे इंटरफेसस्क्रिप्ट नाम दिया जाना चाहिए ?! मैं