प्रतिक्रिया मूलक - अनुप्रयोग और आलोचना

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

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

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

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

इस तथ्य के कारण कि सभी पुस्तकालय अलग-अलग समय पर लिखे गए हैं, वे एसडीके के विभिन्न संस्करणों का उपयोग करते हैं और एक अलग दृष्टिकोण की आवश्यकता होती है। कभी-कभी ऐसा होता है कि पुस्तकालय एक-दूसरे के साथ असंगत होते हैं, या पुस्तकालय का नवीनतम संस्करण प्रयोगात्मक होता है, और डेवलपर्स स्वयं को एकांत में बदलने की सलाह देते हैं। अक्सर, लिंक सभी आवश्यक निर्भरता को कॉन्फ़िगर नहीं करता है। तो, उपरोक्त फायरबेस के लिए, आपको मूल कोड में कई अतिरिक्त लाइब्रेरी जोड़ने की जरूरत है, विभिन्न बाहरी रिपॉजिटरी कनेक्ट करें, mainApplication.java को संशोधित करें (और यह केवल एंड्रॉइड के लिए है!)। फायरबेस के लिए, इन कार्यों को करने के लिए काफी समझ में आने वाला निर्देश है, लेकिन अन्य पुस्तकालयों के लिए यह हमेशा मौजूद नहीं होता है।

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

rmdir node_modules /s /q && npm cache clean - force && npm i 

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

 rmdir android/app/build /s /q 

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

 react-native start-reset-cache 

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

 react-native run-android 

कनेक्टेड डिवाइस या एमुलेटर पर एप्लिकेशन इंस्टॉल करें। अधिकांश बिल्ड त्रुटियां यहां होती हैं, और उनमें से कुछ समझ में आते हैं, लेकिन कुछ काफी तर्कहीन हैं और पूरी प्रक्रिया को फिर से शुरू करके "ठीक" कर रहे हैं।

फायरबेस को जोड़ने के बाद एक परियोजना के लिए आदेशों के अनुक्रम के साथ निर्माण प्रक्रिया की कल्पना करें (पहले से ही दायरे, रिडक्स, रिएक्शन-नेविगेशन, लगभग दस और लाइब्रेरी)।

 react-native start react-native run-android >>    debug react-native run-android >> , metro bundler  react-native start react-native run-android >>    debug react-native run-android >>  !  metro bundler ,   JS-   react-native start >>   restart         -  

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

डिबगिंग की बात कर रहे हैं। रिएक्ट नेटिव डिबगर में न केवल लॉन्च के साथ समस्याएं हैं। परीक्षण के परिणामस्वरूप पाई गई त्रुटियों का सुधार भी एक दर्दनाक प्रक्रिया है। प्रतिक्रिया-मूल में, JS कोड को मूल कोड में अनुवादित किया जाता है, लेकिन अनुवाद के दौरान इसे बाधित किया जाता है। इसलिए यदि आप "zzz.yyy ()" में अशक्त पॉइंटर अपवाद जैसी त्रुटियों को नहीं देखना चाहते हैं, तो आपको अंतर्निहित डीबगर का उपयोग करने की आवश्यकता है, आप लॉगकैट में केवल अपवाद नहीं पढ़ सकते हैं। त्रुटि होने पर, डिबगर अपने विवरण के साथ एक लाल "मौत की स्क्रीन" प्रदर्शित करता है, कम या ज्यादा सुधार के मार्ग की ओर धकेलता है। लेकिन इस हिस्से के साथ समस्याएं हैं।

खैर, जब त्रुटि इस तरह दिखती है:

यह वास्तव में स्पष्ट है कि यहाँ क्या हो रहा है - अपेक्षित सरणी वस्तु के बजाय, यह .state.noteArray.map चर में अपरिभाषित है, जो कुख्यात टाइप-इयरर का कारण बनता है। आप इसे app.js: 14 पर जाकर उपयोग करने से पहले इस चर में मूल्य की जांच करके इसे ठीक कर सकते हैं।

जब इस तरह त्रुटि दिखती है तो इससे भी बदतर:

इसलिए:

या तो:

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

इससे भी बदतर, जब एक त्रुटि डीबग में पुन: पेश नहीं की जाती है। एंड्रॉइड के लिए x64- आर्किटेक्चर के समर्थन के साथ रिएक्ट के नए संस्करण के साथ एक एप्लिकेशन बनाने की कोशिश करते समय हमें इस स्थिति का सामना करना पड़ा। डिबगर के साथ एप्लिकेशन इंस्टॉल करते समय, सब कुछ ठीक काम करता है। लेकिन जैसे ही हम फोन पर टेस्टर का निर्माण करते हैं, सब कुछ काम करना बंद कर देता है और जैसे ही यह डेटाबेस के साथ बातचीत करने के लिए आता है, टूट जाता है। जल्दबाजी में गैर-डीबगिंग को डीबग करने के लिए, हम कंसोल संदेशों का उपयोग करते हैं, जो इस मामले में प्रतिक्रिया टोस्टएंड्रॉइड घटक थे। यह घटक कोड की एक निश्चित सीमा तक पहुंचने पर एक छोटा पाठ प्रदर्शित करता है। विधिपूर्वक, अधिमानतः कोड को आधे में विभाजित करना, हम उस फ़ंक्शन को स्थानीय बनाते हैं जिसमें त्रुटि होती है और पता चलता है कि Object.assign ({}, आइटम) विधि प्रतिक्रिया के नए संस्करण में काम नहीं करती है। यह भाग्यशाली था कि आप अनुप्रयोग की कार्यक्षमता को बनाए रखते हुए इस फ़ंक्शन को एक छोटे {... आइटम} के साथ बदल सकते हैं, लेकिन इस त्रुटि की खोज में लगभग एक दर्जन घंटे काम करते हैं।

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

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

यह पाठ हमारे आवेदन पर भी लागू नहीं होता है, इसे लाल रंग में भी चिह्नित नहीं किया गया था। लेकिन हम इसे प्राप्त करने और मंचों पर जाने के बाद, हमने पाया कि रिएक्ट नेटिव का नया संस्करण टूट गया है। और पिछला वाला टूट गया था। आधिकारिक इश्यू ट्रैकर पर, त्रुटि "एंड्रॉइड क्रैश: सिग्नल 11 (SIGSEGV)" दो महीने के लिए अस्तित्व में थी, और हमारे भाग्य में दो दिन पहले हम वहां गए थे (!) एक प्रयोगात्मक समाधान प्रस्तावित किया गया था जिसने त्रुटि को ठीक किया।

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

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