दृश्यपटल वास्तुकार # 1 द्वारा ध्यान दें। आप Redux को केवल प्राप्त और उपयोग नहीं कर सकते।

त्याग

प्रिय पाठक! यदि आपके पास कोई विचार नहीं है कि क्या प्रतिक्रिया और Redux हैं, तो आगे पढ़ने से कोई मतलब नहीं है, आगे की तकनीकी बकवास। मैं गंभीरता से समझता हूं कि यह नोट क्या है, इन पुस्तकालयों के साथ काम करने की आवश्यकता है - इस तथ्य के बावजूद कि मैं स्पष्ट रूप से लिखने की कोशिश करूंगा, यह लेख एक प्रवेश-स्तर का नहीं है। और यह अभ्यास के आधार पर व्यक्तिगत अनुभव और राय है।

Redux का उपयोग करने में क्या गलत है?

तब मैंने लिखने का फैसला किया, लेकिन वास्तव में मेरी परियोजना और हजारों अन्य लोगों में रिडक्स का उपयोग करने में क्या गलत है? मैं अप्रैल 2016 (तीन वर्ष) से ​​प्रतिक्रिया / रिडक्स एप्लिकेशन लिख रहा हूं। पहले से ही कुछ दिलचस्प चीजों की खोज करने का समय है ... और फिर व्याख्यान और रिपोर्टें थीं, विशेष रूप से शुरुआती लोगों के उद्देश्य से, लेकिन कोई भी वयस्क वापस नहीं आया और कोई पूर्वव्यापी नहीं था। इस बीच, कोई व्यक्ति उन पैकेजों में तारांकन करता है जो चेक करते हैं कि "क्या आप 13 घंटे नहीं हैं," मैं प्रचलित रूढ़ियों की दीवार को तोड़ दूंगा।

लेकिन redux की जरूरत नहीं है!

आप कहते हैं, और कुछ मायनों में आप सही होंगे। 2018 से आप इसका उपयोग नहीं कर सकते हैं - इंटरनेट पर इस विषय पर एक टन लेख हैं, लेकिन अभी तक "गैर-उपयोग" के साथ आपको एक सामूहिक खेत मिलता है, यह नीचे स्पष्ट हो जाएगा कि क्यों। और विकल्पों की संख्या ऑफ-स्केल है और इससे भी अधिक।

हम Redux का उपयोग करते हैं, क्योंकि यह एक स्वीकृत मानक (कम से कम प्रतिक्रिया के लिए) है, Redux के लिए हमारे पास जो पूर्वानुमान और विश्वसनीयता महत्वपूर्ण है। लेकिन हम इसे गंभीरता से याद करते हैं, वास्तव में इसमें

दावा

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

सत्य का एकमात्र स्रोत ...

यहां हमारे पास एक घात है। बेशक, यह कहता है कि 1 कहानी हो सकती है, रेडक्स इस तरह से फ्लक्स आर्किटेक्चर से अपने अंतर की घोषणा करता है। लेकिन अगर आप अधिक व्यापक रूप से देखते हैं: क्या नियम एक वास्तविक परियोजना में मनाया जाता है? आप कहेंगे: काफी। मैं घोषित करता हूं (घोषित) 1 पक्ष, मैं इसे प्रदाता को हस्तांतरित करता हूं और फिर ...

तकनीकी रूप से, प्रक्रिया सही ढंग से वर्णित है। लेकिन मैं कह सकता हूं कि लोग धारणा, तर्क की विकृतियों के अधीन हैं, और चूंकि प्रोग्रामर अभी भी लोग हैं ... खैर, आप समझते हैं कि मैं क्या कर रहा हूं (यदि आप नहीं समझे: प्रोग्रामर धारणा, तर्क, आदि की विकृतियों से ग्रस्त हैं।
यहां मुख्य विकृति यह है कि मैं, मेरे कई सहयोगियों की तरह, इस तथ्य के लिए उपयोग किया जाता है कि यदि हम "स्टोर" शब्द का उपयोग Redux के अलावा किसी अन्य चीज के संबंध में नहीं करते हैं, तो कोई अन्य नहीं है।

और यहाँ प्रतिक्रिया आती है

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

समझें कि सार इस तथ्य से नहीं बदलता है कि आप आइटम का नाम बदलते हैं। सोमवार को एक स्लेजहैमर है, यह इसे सप्ताह का दिन नहीं बनाता है। हां, दोनों सोमवार कठिन हैं, अन्य दिन और स्लेजहैमर आसान हैं। लेकिन इसके नाम से, स्लेजहेमर एक टक्कर उपकरण होने के लिए संघर्ष नहीं करता है।

Redux और State React घटक का पैमाना अलग-अलग है, लेकिन सार, जब आज उपयोग किया जाता है, तो एक है।

मैं इसे इस तरह समझाऊंगा: ज्यादातर मामलों में घटक की आंतरिक स्थिति से डेटा प्रॉपर के माध्यम से बच्चे के पास जाता है, लेकिन, कोई फर्क नहीं पड़ता कि यह कितना स्पष्ट है, redux डेटा, जब प्रतिक्रिया के साथ एकीकृत किया जाता है, भी प्रॉपर के माध्यम से घटकों में मिलता है। घटक के दृष्टिकोण से जो प्रॉप्स को स्वीकार करता है, इससे कोई फर्क नहीं पड़ता कि बाहर क्या है। वह, अंतिम उपयोगकर्ता के लिए - वह Redux स्टोर, वह आंतरिक स्थिति - समान है।

इसके अलावा, यह आंतरिक स्थिति उस घटक के सहारा पर निर्भर नहीं हो सकती है जिसमें यह घोषित किया गया है। फिर हम अलगाव प्राप्त करते हैं जो इस तरह की आंतरिक स्थिति की कल्पना से भी अधिक बड़ा स्टोर बनाता है।

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

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

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

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

समस्याएं (कोई डीएनए प्रमाण नहीं होगा):

1. प्रतिक्रिया के माध्यम से आंतरिक स्थिति को बदलने के लिए devtools कभी-कभी अपडेट या वांछित परिणाम नहीं देते हैं - मैं redux के साथ एकीकरण पर पाप करता हूं।
2. आंतरिक स्थिति रेडक्रॉस डिवोल्ट्स में समयरेखा को तोड़ती है। Redux आर्किटेक्चर के माध्यम से उपलब्ध समय यात्रा के साथ सुपर फीचर आंतरिक राज्य वास्तुकला पर प्रतिक्रिया करने के लिए धन्यवाद काम नहीं करता है। आंतरिक स्थिति ने सिर्फ redux में बदलाव की परवाह नहीं की, इसका अपना राज्य है। टाइमटेवल सिर्फ काम नहीं करता है। कुछ तत्व बस अद्यतन नहीं होते हैं, आंशिक रूप से अपडेट किए जाते हैं, आदि यह सब महाकाव्य नाली के नीचे अतुल्यकालिक कोड सिंक्रनाइज़ेशन के साथ है।

एक उदाहरण, बेशक, अभ्यास से चूसा

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

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

कुछ रूपक

यह खराब भोजन की तरह दिखता है - यह स्वादिष्ट और सस्ता लगता है, लेकिन एक या 3 साल बाद - जठरांत्र संबंधी मार्ग अपने स्वयं के जीवन को मानना ​​और जीना बंद कर देता है। आप अपने पूर्व स्वास्थ्य को पुनः प्राप्त करने के लिए बहुत समय और पैसा खर्च करते हैं और हमेशा इसमें सफल नहीं होते हैं।

Redux और React Internal State प्रतिस्पर्धी हैं , एक जगह पर बड़े और छोटे व्यवसाय। मुख्य उत्पाद डेटा और प्रभाव है। सॉफ्टवेयर उनके उत्पादों का उपभोक्ता है। कई उपमाएँ हैं, लेकिन सार एक ही रहता है - जब हम सॉफ्टवेयर विकसित करते हैं - हमें प्रतिस्पर्धा की आवश्यकता नहीं होती है।

हम प्रोग्राम कोड के "तानाशाह" हैं और किसी भी प्रतियोगिता को दबा दिया जाना चाहिए, मुक्त बाजार को निषिद्ध किया जाना चाहिए, और उपभोक्ता पर नियोजित अर्थव्यवस्था और राज्य का एकाधिकार हावी होना चाहिए।

अहम, कुछ मुझे बोर करता है। सब कुछ योजना के अनुसार जाना चाहिए, सामान्य तौर पर। हमारे पास स्प्रिंट, रिलीज़, और बहुत कुछ है, और सॉफ़्टवेयर की एक परिमित लागत और एक जीवन भर / बाजार में प्रवेश है। यह बहुत महत्वपूर्ण है, और हम जहाज पर दंगों, पुस्तकालयों के विद्रोह की अनुमति नहीं दे सकते।

निष्कर्ष सरल है।

Redux के साथ अन्य रिपॉजिटरी का उपयोग न करें। अपवाद केवल बहुत पृथक मामले बना सकते हैं। उदाहरण के लिए, सिद्धांत रूप में घटक जो कि संबंधित परत के बिना Redux द्वारा नियंत्रित नहीं होते हैं और इसे प्रभावित नहीं करते हैं।

उदाहरण

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


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

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

और इसलिए मॉड्यूल का अपना भंडारण, सर्वर से अपना कनेक्शन है।

यही है, Redux मॉड्यूल को बिल्कुल भी प्रभावित नहीं करता है, व्यावहारिक रूप से इस भंडारण को प्रभावित नहीं कर सकता है (सदस्यता में केवल तीन फ़ील्ड हैं), लेकिन मॉड्यूल और PubSub किसी भी तरह से Redux को प्रभावित नहीं करते हैं। यह अलगाव प्रतिस्पर्धा को बाहर करता है।

सवाल "डेटा कहाँ संग्रहीत करें?" मॉड्यूल विकसित करते समय, मैंने कभी इसका सामना नहीं किया। लेकिन जब यह आंतरिक स्थिति बनाम फिर से शुरू करने की बात आती है - कई के लिए यह सवाल लगभग लगातार उठता है। मैंने एक बार और सभी के लिए इस सवाल का जवाब देने का फैसला किया।

मेरी वास्तु राय है:

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

शायद यह एक पुस्तकालय को जोड़ने के लायक है जो विकास से आंतरिक स्थिति को पूरी तरह से बाहर करता है? या उदाहरण के लिए, Redux से चयन के साथ आंतरिक स्थिति को बदलता है? मैंने एक साल पहले ऐसा लिखना शुरू किया था, 90 प्रतिशत पूरा किया, और 1 रिपोर्ट का आयोजन भी किया। आप क्या कहते हैं? उन की जरूरत है?

मुझे आशा है कि आपको यह नोट अच्छा लगा होगा :)