टाइपप्रति। पावर कभी नहीं

जब मैंने पहली बार शब्द कभी नहीं देखा, तो मैंने सोचा कि टाइपस्क्रिप्ट में बेकार कैसे दिखाई देता है। समय के साथ, ts में गहराई से डूबते हुए, मैं यह समझने लगा कि यह शब्द कितना शक्तिशाली है। और यह शक्ति वास्तविक दुनिया के उपयोग के मामलों से पैदा हुई है जिसे मैं पाठक के साथ साझा करने का इरादा रखता हूं। कौन परवाह करता है, बिल्ली में आपका स्वागत है।

क्या कभी नहीं है

यदि हम इतिहास में डुबकी लगाते हैं, तो हम देखेंगे कि टाइपस्क्रिप्ट संस्करण २.० के भोर में कभी नहीं दिखाई दिया, बल्कि इसके उद्देश्य के बारे में मामूली विवरण के साथ। यदि आप संक्षेप में और आज़ादी से ts डेवलपर्स के संस्करण को पुनः प्राप्त करते हैं, तो प्रकार कभी भी एक आदिम प्रकार नहीं है जो उन मूल्यों के लिए एक संकेत का प्रतिनिधित्व करता है जो कभी नहीं होगा। या, फ़ंक्शंस के लिए एक संकेत जो मूल्यों को कभी नहीं लौटाएगा, या तो इसके लूप के कारण, उदाहरण के लिए, एक अनंत लूप, या इसके रुकावट के कारण। और जो कहा गया था उसका सार स्पष्ट रूप से दिखाने के लिए, मैं नीचे एक उदाहरण देखने का प्रस्ताव करता हूं:

/**    */ function error(message: string): never { throw new Error(message); } /**   */ function infiniteLoop(): never { while (true) { } } /**   */ function infiniteRec(): never { return infiniteRec(); } 

शायद इस तरह के उदाहरणों के कारण, मुझे पहली धारणा मिली कि स्पष्टता के लिए प्रकार की आवश्यकता है।

प्रकार प्रणाली

अब मैं कह सकता हूँ कि टाइपस्क्रिप्ट में समृद्ध प्रकार के सिस्टम का गुण कभी नहीं होता है। और अपने शब्दों के समर्थन में मैं lib.es5.d.ts से कई पुस्तकालय प्रकार दूंगा

 /** Exclude from T those types that are assignable to U */ type Exclude<T, U> = T extends U ? never : T; /** Extract from T those types that are assignable to U */ type Extract<T, U> = T extends U ? T : never; /** Construct a type with the properties of T except for those in type K. */ type Omit<T, K extends keyof any> = Pick<T, Exclude<keyof T, K>>; /** Exclude null and undefined from T */ type NonNullable<T> = T extends null | undefined ? never : T; /** Obtain the parameters of a function type in a tuple */ type Parameters<T extends (...args: any) => any> = T extends (...args: infer P) => any ? P : never; 

मेरे प्रकार के साथ, मैं अपना पसंदीदा नहीं दे पाऊंगा - गेटनेम, कीफ का बेहतर एनालॉग:

 /** * GetNames      * @template FromType  -   * @template KeepType   * @template Include       .   false -    KeepType */ type GetNames<FromType, KeepType = any, Include = true> = { [K in keyof FromType]: FromType[K] extends KeepType ? Include extends true ? K : never : Include extends true ? never : K }[keyof FromType]; //   class SomeClass { firstName: string; lastName: string; age: number; count: number; getData(): string { return "dummy"; } } // be: "firstName" | "lastName" type StringKeys = GetNames<SomeClass, string>; // be: "age" | "count" type NumberKeys = GetNames<SomeClass, number>; // be: "getData" type FunctionKeys = GetNames<SomeClass, Function>; // be: "firstName" | "lastName" | "age" | "count" type NonFunctionKeys = GetNames<SomeClass, Function, false>; 

भविष्य के बदलावों की निगरानी करना

जब परियोजना का जीवन क्षणभंगुर नहीं होता है, तो विकास एक विशेष चरित्र पर ले जाता है। मैं कोड में प्रमुख बिंदुओं पर नियंत्रण रखना चाहता हूं, इस बात की गारंटी देता है कि आप या आपकी टीम के सदस्य समय लगते ही कोड का एक महत्वपूर्ण टुकड़ा तय करना नहीं भूलेंगे। कोड के ऐसे खंड विशेष रूप से प्रकट होते हैं जब किसी चीज की स्थिति या गणना होती है। उदाहरण के लिए, एक इकाई पर क्रियाओं के एक सेट को सूचीबद्ध करना। मैं सुझाव देता हूं कि जो हो रहा है उसके संदर्भ को समझने के लिए एक उदाहरण देखें।

 //    -   ,     ,   ActionEngine type AdminAction = "CREATE" | "ACTIVATE"; // ,     ,   AdminAction   . class ActionEngine { doAction(action: AdminAction) { switch (action) { case "CREATE": //   return "CREATED"; case "ACTIVATE": //   return "ACTIVATED"; default: throw new Error("   "); } } } 

ऊपर दिए गए कोड को केवल एक महत्वपूर्ण बिंदु पर ध्यान केंद्रित करने के लिए जितना संभव हो उतना सरलीकृत किया गया है - AdminAction प्रकार को किसी अन्य प्रोजेक्ट में परिभाषित किया गया है और यह भी संभव है कि यह आपकी टीम के साथ नहीं है। चूंकि यह परियोजना लंबे समय तक जीवित रहेगी, इसलिए आपके एक्शनएंगइन को आपकी जानकारी के बिना AdminAction प्रकार में परिवर्तन से बचाना आवश्यक है। टाइपस्क्रिप्ट इस समस्या को हल करने के लिए कई व्यंजनों की पेशकश करता है, जिनमें से एक कभी-कभी प्रकार का उपयोग करना है। ऐसा करने के लिए, हमें एक NeverError को परिभाषित करने और doAction विधि में इसका उपयोग करने की आवश्यकता है।

 class NeverError extends Error { //         - ts   constructor(value: never) { super(`Unreachable statement: ${value}`); } } class ActionEngine { doAction(action: AdminAction) { switch (action) { case "CREATE": //   return "CREATED"; case "ACTIVATE": //   return "ACTIVATED"; default: throw new NeverError(action); // ^       switch  . } } } 

अब AdminAction में एक नया "ब्लॉक" मान जोड़ें और संकलन समय पर एक त्रुटि प्राप्त करें: प्रकार का तर्क "" ब्लॉक "टाइप 'never'ts. (2345) के पैरामीटर के लिए लागू नहीं है।

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

यदि आप NeverError वर्ग का परिचय नहीं देना चाहते हैं, तो आप कभी भी एक प्रकार का चर घोषित करके कोड को नियंत्रित कर सकते हैं। इस तरह:

 type AdminAction = "CREATE" | "ACTIVATE" | "BLOCK"; class ActionEngine { doAction(action: AdminAction) { switch (action) { case "CREATE": //   return "CREATED"; case "ACTIVATE": //   return "ACTIVATED"; default: const unknownAction: never = action; // Type '"BLOCK"' is not assignable to type 'never'.ts(2322) throw new Error(`   ${unknownAction}`); } } } 

प्रसंग सीमा: यह + कभी नहीं

निम्नलिखित चाल अक्सर थकान या लापरवाही के बीच मुझे हास्यास्पद गलतियों से बचाती है। नीचे दिए गए उदाहरण में, मैं चुने हुए दृष्टिकोण की गुणवत्ता का आकलन नहीं करूंगा। हमारे साथ, वास्तव में, ऐसा होता है। मान लीजिए कि आप किसी वर्ग में ऐसी विधि का उपयोग करते हैं जिसमें कक्षा के क्षेत्रों तक पहुँच नहीं है। हाँ, यह डरावना लगता है - यह सब gov है ... कोड।

 @SomeDecorator({...}) class SomeUiPanel { @Inject private someService: SomeService; public beforeAccessHook() { //    ,    ,     SomeUiPanel this.someService.doInit("Bla bla"); // ^       :  beforeAccessHook   ,      } } 

एक व्यापक मामले में, यह कॉलबैक या एरो फ़ंक्शंस हो सकता है, जिनके अपने निष्पादन संदर्भ हैं। और कार्य है: स्वयं को रनटाइम त्रुटियों से कैसे बचाया जाए? इसके लिए, टाइपस्क्रिप्ट में इस संदर्भ को निर्दिष्ट करने की क्षमता है।

 @SomeDecorator({...}) class SomeUiPanel { @Inject private someService: SomeService; public beforeAccessHook(this: never) { //    ,    ,     SomeUiPanel this.someService.doInit("Bla bla"); // ^ Property 'someService' does not exist on type 'never' } } 

निष्पक्षता में, मैं कहता हूं कि यह कभी भी योग्यता नहीं है। इसके बजाय, आप शून्य और {} का उपयोग कर सकते हैं। लेकिन यह वह प्रकार है जो कभी भी कोड को पढ़ने पर ध्यान आकर्षित करता है।

उम्मीदों

अपरिवर्तनशीलताओं

कभी निश्चित विचार न होने पर, मैंने सोचा कि निम्नलिखित कोड को काम करना चाहिए:

 type Maybe<T> = T | void; function invariant<Cond extends boolean>(condition: Cond, message: string): Cond extends true ? void : never { if (condition) { return; } throw new Error(message); } function f(x: Maybe<number>, c: number) { if (c > 0) { invariant(typeof x === "number", "When c is positive, x should be number"); (x + 1); // works because x has been refined to "number" } } 

लेकिन अफसोस। अभिव्यक्ति (x + 1) एक त्रुटि फेंकता है: ऑपरेटर '+' को 'शायद' और '1' प्रकारों पर लागू नहीं किया जा सकता है। उदाहरण मैं स्वयं लेख में जासूसी करता हूं जो फ्लो से टाइपस्क्रिप्ट तक कोड की 30,000 लाइनों को स्थानांतरित करता है।

लचीला बंधन

मैंने सोचा कि कभी भी मैं अनिवार्य फ़ंक्शन मापदंडों को नियंत्रित नहीं कर सकता हूं और कुछ शर्तों के तहत, अनावश्यक लोगों को अक्षम कर सकता हूं। लेकिन नहीं, यह काम नहीं करेगा:

 function variants<Type extends number | string>(x: Type, c: Type extends number ? number : never): number { if (typeof x === "number") { return x + c; } return +x; } const three = variants(1, 2); // ok // 2  - never,     string. ,   const one = variants("1"); // expected 2 arguments, but got 1.ts(2554) 

उपरोक्त समस्या को एक अलग तरीके से हल किया जाता है।

अधिक कठोर सत्यापन

मैं ts संकलक को सामान्य ज्ञान के विपरीत कुछ याद नहीं करना चाहता था।

 variants(<never> {}, <never> {}); 

निष्कर्ष

अंत में, मैं अजीब विषमताओं की एक श्रृंखला से, एक छोटे से काम की पेशकश करना चाहता हूं। कौन सी लाइन त्रुटि है?

 class never<never> { never: never; } const whats = new never<string>(); whats.never = ""; 

यही सब मैं कभी नहीं बताना चाहता था। आपका ध्यान देने के लिए आप सभी का धन्यवाद और जल्द ही आपको देखूंगा।