विनाशकारी और इनलाइन प्रकारों का उपयोग करना आपके टाइपस्क्रिप्ट कोडबेस को नुकसान पहुंचा सकता है

हाल ही में मैंने जेमी काइल द्वारा विनाशकारी, डिफ़ॉल्ट पैरा और इनलाइन प्रकारों का उपयोग करने के बारे में एक ट्वीट देखा:

उस ट्वीट और कुछ रिएक्ट घटकों को जो मैंने हाल ही में अपने दिन के काम में देखा, ने मुझे यह ब्लॉग पोस्ट लिखने के लिए प्रेरित किया। मैं आपको दिखाना चाहता हूं कि कैसे विनाशकारी और इनलाइन प्रकारों का उपयोग करना आपके टाइपस्क्रिप्ट को कम पठनीय बना सकता है!

टाइपस्क्रिप्ट फ़ंक्शन परिभाषा कैसी दिखती है?

जावास्क्रिप्ट और टाइपस्क्रिप्ट में, आप function कीवर्ड या लैम्ब्डा/एरो फ़ंक्शन का उपयोग करके फ़ंक्शन को परिभाषित कर सकते हैं। दोनों तरीके मान्य हैं लेकिन उनके मतभेद हैं। आइए सरल sendMessage फ़ंक्शन पर एक नज़र डालें। कार्यान्वयन तर्क हमारे लिए प्रासंगिक नहीं है।

 // sendMessage function written using `function` keyword function sendMessage(message: string) { // function logic } // same sendMessage written as arrow function const sendMessage = (message: string) => { // function logic };

जब फ़ंक्शन की परिभाषा काफी सरल होती है, तो फ़ंक्शन एक अलग प्रकार के कुछ मापदंडों को स्वीकार करता है। यदि वे तार या संख्या जैसे आदिम हैं, तो सब कुछ पठनीय है।

मान लें कि आप अपनी संदेश सामग्री के साथ कुछ अतिरिक्त जानकारी sendMessage फ़ंक्शन में पास करना चाहते हैं।

 function sendMessage(message: { content: string; senderId: string; replyTo?: string; }) { // you can assess content using `message.content` here }

जैसा कि आप देख सकते हैं, टाइपस्क्रिप्ट आपको उस message ऑब्जेक्ट के लिए एक इनलाइन प्रकार की परिभाषा लिखने की अनुमति देता है जिसे आप type या interface कीवर्ड का उपयोग किए बिना निर्दिष्ट किए बिना पास करना चाहते हैं।

आइए विनाशकारी जोड़ें। जब आप अपने फ़ंक्शन के लिए एक बड़ा message ऑब्जेक्ट पास करते हैं, तो टाइपस्क्रिप्ट कई बार दोहराए जाने वाले message चर के कोड बॉयलरप्लेट को कम करने के लिए अलग-अलग पारित तर्कों को तोड़ने की अनुमति देता है।

 function sendMessage({ content, senderId, replyTo, }: { content: string; senderId: string; replyTo?: string; }) { // you have access to `content` directly }

मुझे क्यों लगता है कि यह एक बुरा विचार है और आप इसे कैसे बेहतर बना सकते हैं?

यह एक अच्छा विचार लग सकता है, आखिरकार, आपको कई बार message लिखने की ज़रूरत नहीं है, है ना? यह पता चला है कि यह इतना अच्छा नहीं है। आइए 5 कारणों के बारे में बात करते हैं कि मुझे क्यों लगता है कि यह एक प्रतिमान है।

1. आप सुनिश्चित नहीं हैं कि आपका डेटा कहां से आ रहा है

जब आप फ़ंक्शन बॉडी पढ़ रहे होते हैं, तो आप senderId देखते हैं, आपको यह सुनिश्चित करने के लिए दोबारा जांच करनी होगी कि वह फ़ंक्शन कहां से आता है। क्या इसे तर्क के रूप में पारित किया गया है या फ़ंक्शन में कहीं गणना की गई है?

2. प्रलेखन लिखना कठिन है

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

3. उस डेटा को आगे बढ़ाना मुश्किल है

जब आपका डेटा नष्ट हो जाता है, तो आपको इसे फिर से एक नई वस्तु में संरचित करने की आवश्यकता होती है यदि आप इसे आगे बढ़ाना चाहते हैं। यह आपके मुख्य कार्य तर्क को बनाने के लिए छोटे सहायक कार्यों को बनाने और संरचना पर निर्भर होने को हतोत्साहित करता है।

4. आप इस फ़ंक्शन के बाहर तर्क प्रकारों का पुन: उपयोग नहीं कर सकते हैं

यदि आपको अपने मुख्य फ़ंक्शन तर्क की रचना करते समय सहायक कार्यों में अपने फ़ंक्शन तर्कों का पुन: उपयोग करने की आवश्यकता है, तो आपको एक ही प्रकार के सेट को बार-बार टाइप करना होगा। इससे टाइप्स को बिल्कुल नहीं लिखना आसान हो जाता है।

5. इसमें बस बहुत सी जगह लगती है

चलो सामना करते हैं। यह कोड की बहुत सी पंक्तियाँ हैं जो बहुत अधिक स्क्रीन स्थान लेती हैं। और इसके अलावा, यह कार्यान्वयन विवरण पर ध्यान केंद्रित करता है - किसी फ़ंक्शन में आपके द्वारा पारित किए जा रहे तर्कों का आंतरिक प्रकार, जो उस फ़ंक्शन को देखते समय अधिकांश समय प्रासंगिक नहीं होता है।

बस इसके लिए एक प्रकार बनाएं

प्रकार को निकालना और इसे फ़ंक्शन के ठीक ऊपर रखना इसे और अधिक पठनीय बनाता है। दस्तावेज़ीकरण टिप्पणियों के लिए एक जगह है, आप उस प्रकार को किसी अन्य सहायक फ़ंक्शन में पुन: उपयोग कर सकते हैं और यदि आवश्यक हो तो टाइप परिभाषा को एक स्थान पर बदल सकते हैं।

 /** * Message to send using XYZ API */ export type MessageToSend = { /** * Markdown string of the user's message */ content: string; /** * Id of the sender user */ senderId: string; /** * Other message ID if this is a reply */ replyTo?: string; }; function sendMessage(message: MessageToSend) { // function logic } function getUserIdsToNotify(message: MessaageToSend) { // function logic }

साधन

इस ब्लॉग पोस्ट पर शोध करते समय मेरे द्वारा उपयोग किए गए संसाधनों की एक सूची प्राप्त करें:

• https://www.typescriptlang.org/docs/handbook/variable-declarations.html#object-destructuring