हाल ही में मैंने जेमी काइल द्वारा विनाशकारी, डिफ़ॉल्ट पैरा और इनलाइन प्रकारों का उपयोग करने के बारे में एक ट्वीट देखा:   https://twitter.com/buildsghost/status/1577030375158607872?s=20&t=0qa78fG7TzsSdxrsM1sCvg?embedable=true  उस ट्वीट और कुछ रिएक्ट घटकों को जो मैंने हाल ही में अपने दिन के काम में देखा, ने मुझे यह ब्लॉग पोस्ट लिखने के लिए प्रेरित किया। मैं आपको दिखाना चाहता हूं कि कैसे विनाशकारी और इनलाइन प्रकारों का उपयोग करना आपके टाइपस्क्रिप्ट को कम पठनीय बना सकता है!  टाइपस्क्रिप्ट फ़ंक्शन परिभाषा कैसी दिखती है?  जावास्क्रिप्ट और टाइपस्क्रिप्ट में, आप   कीवर्ड या लैम्ब्डा/एरो फ़ंक्शन का उपयोग करके फ़ंक्शन को परिभाषित कर सकते हैं। दोनों तरीके मान्य हैं लेकिन उनके मतभेद हैं। आइए सरल   फ़ंक्शन पर एक नज़र डालें। कार्यान्वयन तर्क हमारे लिए प्रासंगिक नहीं है। 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 }  मुझे क्यों लगता है कि यह एक बुरा विचार है और आप इसे कैसे बेहतर बना सकते हैं?  यह एक अच्छा विचार लग सकता है, आखिरकार, आपको कई बार   लिखने की ज़रूरत नहीं है, है ना? यह पता चला है कि यह इतना अच्छा नहीं है। आइए 5 कारणों के बारे में बात करते हैं कि मुझे क्यों लगता है कि यह एक प्रतिमान है। message  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

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

Alongside

Twitter

Read My Stories

यह ऑडियो कहानी की मूल भाषा में निर्मित है!

बहुत लंबा; पढ़ने के लिए

Make resilience your competitive advantage

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

About Author

टिप्पणियाँ

लेबल

इस लेख में चित्रित किया गया था

Related Stories

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon एक बहुभाषी प्लेटफ़ॉर्म है: सभी शीर्ष कहानियाँ अब 13 भाषाओं में उपलब्ध हैं

क्लाउड सॉनेट 3.5 सिस्टम प्रॉम्प्ट लीक: एक फोरेंसिक विश्लेषण

टेलीग्राम: क्रिप्टो द्वीप का मुख्य भूमि से पुल

10 Reasons Why Publishing on HackerNoon Will Skyrocket Your Reach and Impact

HackerNoon एक बहुभाषी प्लेटफ़ॉर्म है: सभी शीर्ष कहानियाँ अब 13 भाषाओं में उपलब्ध हैं

क्लाउड सॉनेट 3.5 सिस्टम प्रॉम्प्ट लीक: एक फोरेंसिक विश्लेषण

टेलीग्राम: क्रिप्टो द्वीप का मुख्य भूमि से पुल

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps