स्रोत कोड पार्स करके अपने जावास्क्रिप्ट ज्ञान में सुधार करें

जब आप अपना प्रोग्रामिंग करियर शुरू करते हैं, तो ओपन लाइब्रेरी और फ्रेमवर्क के सोर्स कोड में खुदाई करना थोड़ा डरावना लग सकता है। इस लेख में, कार्ल मुंगाज़ी ने अपने अनुभव को साझा किया कि कैसे उन्होंने अपने डर को दूर किया और ज्ञान प्राप्त करने और कौशल विकसित करने के लिए स्रोत कोड का उपयोग करना शुरू किया। वह यह दिखाने के लिए भी Redux का उपयोग करता है कि वह कैसे पुस्तकालय को "पार्स" करता है।

क्या आपको याद है जब आपने पहली बार अपने आप को एक पुस्तकालय या ढांचे के कोड में डुबोया था जिसे आप अक्सर उपयोग करते हैं? मेरे जीवन में, यह क्षण तीन साल पहले फ्रंट-एंड डेवलपर के रूप में मेरी पहली नौकरी में आया।

हम सिर्फ एक पुराने स्वामित्व वाले ढांचे को फिर से लिखते हैं जिसका उपयोग इंटरैक्टिव प्रशिक्षण पाठ्यक्रम बनाने के लिए किया गया था। पुनर्लेखन के कार्य की शुरुआत में, हमने कुछ टर्नकी समाधानों को देखा, जिनमें मिथ्रिल, इनफर्नो, कोणीय, अभिक्रिया, ऑरेलिया, व्यू और पॉलिमर शामिल हैं। चूँकि मैं अभी भी एक युवा पडावन था (जो पत्रकारिता से वेब विकास में बदल गया था), मैं प्रत्येक ढांचे की जटिलता और वे कैसे काम करते हैं, इसकी समझ की कमी से बहुत डरते थे।

समझना तब शुरू हुआ जब मैंने मिथ्रिल फ्रेमवर्क को ध्यान से देखना शुरू किया। तब से, जावास्क्रिप्ट का मेरा ज्ञान - और सामान्य रूप से प्रोग्रामिंग - लाइब्रेरी इंटर्नल्स में खुदाई में बिताए गए घंटों के लिए बहुत मजबूत हो गया है, जो कि मैं काम पर और अपनी परियोजनाओं में दैनिक उपयोग करता था। इस लेख में मैं आपको बताऊंगा कि आप अपने पसंदीदा पुस्तकालय को एक ट्यूटोरियल के रूप में कैसे उपयोग कर सकते हैं


मैंने मिथाइल से हाइपरस्क्रिप्ट फ़ंक्शन के साथ स्रोत कोड पढ़ना शुरू किया

पार्सिंग सोर्स कोड के पेशेवरों

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

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

एक और प्लस एक अच्छा अनुप्रयोग वास्तुकला की समझ का विकास है। इस तथ्य के बावजूद कि अधिकांश ओपन-सोर्स प्रोजेक्ट आम तौर पर अपनी रिपॉजिटरी की संरचना में कम या ज्यादा समान हैं, फिर भी उनके बीच मतभेद हैं। मिथ्रिल की संरचना बहुत सपाट है और यदि आप इसके एपीआई में पारंगत हैं, तो आप रेंडर, राउटर और अनुरोध फ़ोल्डर में कोड के बारे में काफी यथार्थवादी धारणा बना सकते हैं। दूसरी ओर, रिएक्ट की संरचना इसकी नई वास्तुकला को दर्शाती है। डेवलपर्स ने DOM तत्वों (रिएक्शन-डोम) को रेंडर करने के लिए जिम्मेदार मॉड्यूल से UI (रिएक्शन-रिसीलर) को अपडेट करने के लिए जिम्मेदार मॉड्यूल को अलग कर दिया।

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


स्रोत कोड को जल्द ही पार्स करने से आप जावास्क्रिप्ट स्पेक्स पढ़ सकते हैं।

एक और प्लस, जो मेरे लिए एक बड़ा आश्चर्य था, यह है कि यह आपके लिए आधिकारिक जावास्क्रिप्ट विनिर्देश पढ़ना आसान बनाता है। पहली बार जब मैंने उससे पूछा कि मैं यह पता लगाने की कोशिश कर रहा हूं कि थ्रो एरर और थ्रो नई एरर (स्पॉइलर - नथिंग ) में क्या अंतर है। मैंने यह सवाल इसलिए पूछा क्योंकि मीथ्रिल ने एम फंक्शन के कार्यान्वयन में थ्रो एरर का इस्तेमाल किया था और मुझे आश्चर्य हुआ कि यह थ्रो नई त्रुटि से बेहतर क्यों था। तब मुझे यह भी पता चला कि ऑपरेटर्स && और || आवश्यक रूप से बूलियन मूल्यों को वापस नहीं करते हैं , मैंने उन नियमों को पाया जिनके द्वारा गैर-सख्त तुलना के ऑपरेटर == "मानों को हल करता है" और इसका कारण Object.prototyp.toString.call ({}) रिटर्न '[ऑब्जेक्ट ऑब्जेक्ट]' है।

सोर्स कोड को पार्स कैसे करें

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

हाल ही में, मैंने इस तरह से ReactDOM.render को पार्स किया और रिएक्ट फाइबर और इसे लागू करने में आने वाली कुछ कठिनाइयों के बारे में बहुत कुछ सीखा। सौभाग्य से, रिएक्ट बहुत लोकप्रिय है और अन्य डेवलपर्स से एक ही विषय पर बड़ी संख्या में लेखों की उपस्थिति ने प्रक्रिया को तेज किया।

कोड में इस गोता ने मुझे सहकारी अनुसूची , window.requestIdleCallback विधि की अवधारणा से भी परिचित कराया , और एक लिंक की गई सूची का लाइव उदाहरण (उन्हें कतार में भेजकर अद्यतन संसाधित करता है, जो कि अद्यतनों की प्राथमिकता वाली सूची है)। इस प्रक्रिया में, लाइब्रेरी का उपयोग करके एक साधारण एप्लिकेशन बनाना अच्छा होगा। इससे आपको डीबग करना आसान हो जाता है क्योंकि आपको अन्य पुस्तकालयों के स्टैक ट्रेस से निपटना नहीं पड़ता है।

अगर मैं एक विस्तृत समीक्षा नहीं करता हूं, तो मैं जिस प्रोजेक्ट पर काम कर रहा हूं, उसमें नोड_मॉडल्स फ़ोल्डर खोलूंगा या गीथहब पर एक नज़र डालूंगा। मैं हमेशा ऐसा करता हूं जब मैं एक बग या एक दिलचस्प विशेषता के साथ आता हूं। GitHub पर कोड पढ़ते समय, सुनिश्चित करें कि यह नवीनतम संस्करण है। नवीनतम संस्करण का कोड शाखाओं को बदलने और "टैग" का चयन करने के लिए बटन पर क्लिक करके देखा जा सकता है। पुस्तकालयों और चौखटे में परिवर्तन जारी है, इसलिए आप कुछ ऐसा नहीं चाहते हैं जो अगले संस्करण में न हो।

सीखने के स्रोत कोड का एक अधिक सतही संस्करण है जिसे मैं "त्वरित रूप" कहता हूं। किसी तरह मैंने express.js स्थापित किया, नोड_मॉडल्स फ़ोल्डर खोला और निर्भरता के माध्यम से चला गया। यदि README ने मुझे संतोषजनक स्पष्टीकरण नहीं दिया, तो मैंने स्रोत को पढ़ा। यह मुझे दिलचस्प खोजों की ओर ले गया:

• एक्सप्रेस ऑब्जेक्ट्स को मर्ज करने के लिए दो मॉड्यूल का उपयोग करता है, और इन मॉड्यूल का संचालन बहुत अलग है। मर्ज-डिस्क्रिप्टर केवल स्रोत ऑब्जेक्ट में पाए गए गुणों को जोड़ता है, और गैर-एन्यूमरेबल गुणों को भी जोड़ता है, जबकि बर्तन-मर्ज ऑब्जेक्ट के एन्यूमरेटेड गुणों और इसकी संपूर्ण प्रोटोटाइप श्रृंखला पर जाता है। मर्ज-डिस्क्रिप्टर Object.getOwnPropertyNames () और Object.getOwnPropertyDescriptor () का उपयोग करता है, और utils- मर्ज for..in का उपयोग करता है;
• सेटप्रोटाइप्टोफ़ मॉड्यूल निर्मित (तत्काल) ऑब्जेक्ट के प्रोटोटाइप को निर्दिष्ट करने के लिए एक क्रॉस-प्लेटफ़ॉर्म विकल्प प्रदान करता है;
• एस्केप-html एक 78-लाइन स्ट्रिंग भागने वाला मॉड्यूल है, जिसके बाद सामग्री को HTML में डाला जा सकता है;

हालाँकि ये खोजें अभी बहुत उपयोगी नहीं हैं, लेकिन आपके पुस्तकालय या ढांचे की निर्भरता की एक सामान्य समझ बहुत उपयोगी है।

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


एक उपयोगी अनुप्रयोग के रूप में डीबगर का उपयोग करें। एक धारणा बनाएं और फिर उसका परीक्षण करें।

केस स्टडी: Redux में कनेक्ट फंक्शन

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

कनेक्ट एक प्रतिक्रिया-रिडक्स फ़ंक्शन है जो प्रतिक्रिया घटक और एक एप्लिकेशन के रिड्यूक्स स्टोर को जोड़ता है। कैसे? प्रलेखन के अनुसार , वह निम्नलिखित कार्य करती है:

"मैं एक नया, संबंधित घटक वर्ग लौटाता हूं, जो उसके पास दिए गए घटक का आवरण है।"

इसे पढ़ने के बाद, मैं निम्नलिखित प्रश्न पूछता हूं:

• क्या मुझे ऐसे पैटर्न या अवधारणाएं पता हैं, जहां फ़ंक्शंस अतिरिक्त कार्यक्षमता के साथ लिपटे इनपुट मापदंडों को वापस करते हैं?
• यदि हां, तो मैं प्रलेखन से विवरण के आधार पर इसका उपयोग कैसे करूं?

आमतौर पर अगला चरण कनेक्ट फ़ंक्शन का उपयोग करके एक आदिम एप्लिकेशन बनाना है। फिर भी, इस स्थिति में, मैंने रिएक्ट पर एक नए एप्लिकेशन का उपयोग किया, जिस पर हमने काम किया, क्योंकि मैं एक एप्लिकेशन के संदर्भ में कनेक्ट को समझना चाहता था जो कि जल्द ही उत्पादन के लिए मिलेगा।

जिस घटक पर मैंने ध्यान केंद्रित किया वह कुछ इस तरह है:

class MarketContainer extends Component { // code omitted for brevity } const mapDispatchToProps = dispatch => { return { updateSummary: (summary, start, today) => dispatch(updateSummary(summary, start, today)) } } export default connect(null, mapDispatchToProps)(MarketContainer); 

यह एक कंटेनर घटक है जो चार छोटे संबंधित घटकों के लिए एक आवरण के रूप में कार्य करता है। फ़ाइल से कनेक्ट होने वाली पहली चीज़ों में से एक है जो निर्यात कनेक्ट करती है टिप्पणी "कनेक्ट कनेक्ट के लिए मुखौटा है"। पहले से ही इस स्तर पर हम कुछ सीख सकते हैं: हमारे पास कार्रवाई में "मुखौटा" पैटर्न का निरीक्षण करने का अवसर है। फ़ाइल के अंत में, हम कनेक्ट कॉल को क्रिएट कॉन्टेक्ट फंक्शन में निर्यात करते देखते हैं। इसके पैरामीटर डिफ़ॉल्ट मानों का एक समूह हैं जो निम्नानुसार विनाशकारी हैं:

 export function createConnect({ connectHOC = connectAdvanced, mapStateToPropsFactories = defaultMapStateToPropsFactories, mapDispatchToPropsFactories = defaultMapDispatchToPropsFactories, mergePropsFactories = defaultMergePropsFactories, selectorFactory = defaultSelectorFactory } = {}) 

और हमारे पास एक और शिक्षाप्रद पल है: जिसे फंक्शन का एक्सपोर्ट कहा जाता है और डिफॉल्ट द्वारा फंक्शन के डिस्ट्रक्टर्स को नष्ट करना। पुनर्गठन हमारे लिए शिक्षाप्रद है क्योंकि कोड इस तरह लिखा जा सकता है:

 export function createConnect({ connectHOC = connectAdvanced, mapStateToPropsFactories = defaultMapStateToPropsFactories, mapDispatchToPropsFactories = defaultMapDispatchToPropsFactories, mergePropsFactories = defaultMergePropsFactories, selectorFactory = defaultSelectorFactory }) 

नतीजतन, हमें एक त्रुटि मिलेगी - अनकैप्ड टाइपर्रर: 'अपरिभाषित' या 'अशक्त' की विनाशकारी संपत्ति को 'कनेक्टहॉक' नहीं किया जा सकता। ऐसा इसलिए होगा क्योंकि फ़ंक्शन का कोई डिफ़ॉल्ट तर्क मान नहीं है।

नोट: तर्कों के पुनर्गठन को बेहतर ढंग से समझने के लिए, आप डेविड वॉल्श के लेख को पढ़ सकते हैं। भाषा के आपके ज्ञान के आधार पर कुछ बिंदु तुच्छ लग सकते हैं - फिर आप उन बिंदुओं पर ध्यान केंद्रित कर सकते हैं जिनसे आप परिचित नहीं हैं।

CreateConnect फ़ंक्शन ही कुछ नहीं करता है। यह सिर्फ मेरे द्वारा उपयोग किए गए कनेक्ट फ़ंक्शन को लौटाता है:

 export default connect(null, mapDispatchToProps)(MarketContainer) 

यह चार वैकल्पिक तर्क देता है और उनमें से पहले तीन मैच फ़ंक्शन से गुजरते हैं, जो उनके व्यवहार को निर्धारित करने में मदद करता है जिसके आधार पर तर्क पारित किए जाते हैं, साथ ही साथ उनके प्रकार भी। यह पता चला है कि चूंकि मैच के लिए दिया गया दूसरा तर्क कनेक्ट में आयात किए गए तीन कार्यों में से एक है, मुझे यह चुनने की आवश्यकता है कि आगे कहां जाना है।

प्रॉक्सी फ़ंक्शन से कनेक्ट करने के लिए उपयोग की जाने वाली कुछ चीज़ों को भी कनेक्ट करने के लिए पहले तर्क को लपेटना है, अगर ये तर्क कार्य हैं; सादे वस्तुओं की जांच करने के लिए या चेतावनी मॉड्यूल से उपयोग की जाने वाली isPlainObject उपयोगिता से, जो दिखाता है कि आप एक डीबगर कैसे बना सकते हैं जो सभी त्रुटियों पर टूट जाएगा। मैच फ़ंक्शन के बाद, हम कनेक्टएचओसी पर जाते हैं, फ़ंक्शन जो हमारी प्रतिक्रिया घटक लेता है और इसे रिडक्स के साथ जोड़ता है। एक अन्य फ़ंक्शन कॉल है जो रैपविथकनेक्ट को लौटाता है - एक फ़ंक्शन जो वास्तव में घटक के बंधन को रिपॉजिटरी से संभालता है।

कनेक्टएचओसी कार्यान्वयन को देखते हुए, मैं अनुमान लगा सकता हूं कि कनेक्ट कार्यान्वयन का विवरण क्यों छिपाया जाना चाहिए। यह अनिवार्य रूप से प्रतिक्रिया-रिडक्स का दिल है और इसमें तर्क शामिल हैं जो कनेक्ट के माध्यम से सुलभ नहीं होने चाहिए। यहां तक ​​कि अगर हम इस पर ध्यान केंद्रित करते हैं, तो, यदि आपको गहरी खुदाई करने की आवश्यकता है, तो हमारे पास पहले से ही कोड की विस्तृत व्याख्या के साथ स्रोत सामग्री होगी।

माथुर

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

उदाहरण के लिए, मैंने पाया isPlainObject फ़ंक्शन दिलचस्प है क्योंकि यह इसका उपयोग करता है यदि (टाइपोफ़ ओब्ज! = 'ऑब्जेक्ट' || obj === null) यह सुनिश्चित करने के लिए कि तर्क पास की गई एक साधारण वस्तु है, झूठे हैं। जब मैंने पहली बार इस कोड को पढ़ा, तो मैंने सोचा, क्यों न सिर्फ Object.prototype.toString.call (opts)! == '[ऑब्जेक्ट ऑब्जेक्ट]' का उपयोग किया जाए, जिससे कोड कम हो जाए और ऑब्जेक्ट्स को अपने उपप्रकारों जैसे दिनांक से अलग कर दिया जाए। लेकिन पहले से ही अगली पंक्ति में यह स्पष्ट है कि भले ही अचानक (अचानक!) कनेक्ट का उपयोग करने वाला एक डेवलपर एक दिनांक ऑब्जेक्ट लौटाता है, उदाहरण के लिए, Object.getPrototypOf (obj) === null की जाँच कर सकता है।

इस स्थान पर isPlainObject में एक और अप्रत्याशित बिंदु है:

 while (Object.getPrototypeOf(baseProto) !== null) { baseProto = Object.getPrototypeOf(baseProto) } 

Google पर एक उत्तर खोजने से मुझे StackOverflow पर इस धागे की ओर ले जाया गया, और GitHub के Redux पर इस टिप्पणी से , जो बताता है कि यह कोड उन स्थितियों को कैसे संभालता है, उदाहरण के लिए, एक वस्तु को iFrame से स्थानांतरित किया जाता है।

-

पहले लेख का अनुवाद करने का फैसला किया। मैं स्पष्टीकरण, सलाह और सिफारिशों के लिए आभारी रहूंगा