#1 इसे {समूह(Set)} की तरह सोचना
#2 घोषित type और narrowed type को समझना
#3 optional field की जगह discriminated union का उपयोग
#4 type assertion से बचने के लिए type predicate का उपयोग
#5 union type distribution को नियंत्रित करना
#6 exhaustive checking के जरिए compile समय पर unhandled cases की जाँच
#7 interface की बजाय type का उपयोग
#8 सही परिस्थिति में array की बजाय tuple का उपयोग
#9 inferred type को अधिक general या specific बनाने पर नियंत्रण
#10 अतिरिक्त generic type parameter बनाने के लिए infer का उपयोग
#11 type manipulation में रचनात्मकता दिखाकर DRY बनाए रखना
समापन
6 टिप्पणियां
मुझे लगता है कि 7वां बिंदु React के नज़रिए से लिखा गया है।
मैं Type की बजाय Interface को पसंद करता हूँ। यह दूसरे भाषाओं में भी मौजूद एक syntax है।
मैं भी। मुझे याद है कि पहले TypeScript handbook में भी जहाँ तक संभव हो interface को प्राथमिकता से इस्तेमाल करने की सलाह दी गई थी।
यही वह सामग्री है।
बाकी सब ठीक है, लेकिन 7 में
interfaceकी बजायtypeइस्तेमाल करने वाली बात क्या सच में ज़रूरी है? उसे टिप कहना मुश्किल है। कुछ मामलों मेंinterfaceकी अभिव्यक्त क्षमता बेहतर होती है, उदाहरण के लिएinterface Foo {(b: number): A; (): B}मैं Type का समर्थन नहीं कर रहा हूँ, लेकिन ज़्यादा expressive उदाहरण ठीक से समझ नहीं आ रहा है। क्या वही उदाहरण Types के साथ भी उसी तरह व्यक्त नहीं किया जा सकता?
interface Foo {(b: number): A; (): B}
type Foo = {(b: number): A; (): B}
Effective TypeScriptकिताब में type और interface में से किसे इस्तेमाल करना चाहिए, इस पर एक हिस्सा है, उसे उद्धृत कर रहा हूँ.अगर project की style अभी स्थापित नहीं हुई है, तो यह सोचना चाहिए कि भविष्य में augmentation की संभावना है या नहीं। अगर आपको किसी API के लिए type declaration लिखना है, तो interface का उपयोग करना बेहतर है। क्योंकि API बदलने पर user interface के माध्यम से नए fields को merge कर सकते हैं, जो उपयोगी होता है। लेकिन project के अंदरूनी उपयोग वाले types में declaration merging होना गलत design है। इसलिए ऐसे मामलों में type का उपयोग करना चाहिए.