प्रतिक्रिया आधारित अनुप्रयोग का उपयोग करने में रेडक्स और रिफ्लक्स का मुख्य अंतर क्या है?

Question

हाल ही में मैंने ई-कॉमर्स साइट विकसित करने पर प्रारंभिक अध्ययन किया और पाया कि redux और reflux दोनों फेसबुक में flux architecture से आते हैं और दोनों लोकप्रिय हैं। मैं दोनों के बीच के अंतर के बारे में उलझन में हूँ।

मुझे रेडक्स बनाम रिफ्लक्स का उपयोग कब करना चाहिए, और ई-कॉमर्स वेब एप्लिकेशन के विकास चरण के दौरान कौन सा लचीला है?

Answer 1

मैं भाटा और Redux के बीच विशिष्ट अंतर पर ध्यान केंद्रित कर एक और उत्तर लिखना चाहते थे:

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

फ्लक्स (त्वरित अवलोकन)

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

क्योंकि मैं फ्लक्स की तुलना संदर्भित करने के लिए की आवश्यकता होगी, मैं सिर्फ नीचे चित्र के साथ एक quick overview way Flux works दिखाना चाहते हैं:

भाटा

भाटा में, वहाँ कोई डिस्पैचर है, और व्यू घटक सीधे कार्यों के माध्यम से घटकों के माध्यम से संवाद करते हैं।

+---------+  +--------+  +-----------------+ 
¦ Actions ¦------>¦ Stores ¦------>¦ View Components ¦ 
+---------+  +--------+  +-----------------+ 
    ^         ¦ 
    +--------------------------------------+ 

फ़्लक्स से खुद को अलग करने के तरीके के संदर्भ में, बहुत अधिक नहीं है। आप अभी भी अपने स्वयं के कार्यों को बनाते हैं और अपना खुद का स्टोर बनाते हैं, और आपके पास अभी भी आपके स्टोर कार्यवाही सुनते हैं। मेरा मानना ​​है कि सबसे बड़ा अंतर यह है कि व्यू घटक एक प्रेषक के माध्यम से सीधे स्टोर पर कार्रवाई सबमिट करने के लिए, घटक के पास एक स्टोर संपत्ति होती है जो React.Component के बजाय Reflux.Component से विस्तार करने से आता है ताकि इसका सीधे मार्ग हो सके एक दुकान में हुक। यानी इस उदाहरण

class MyComponent extends Reflux.Component 
{ 
    constructor(props) 
    { 
     super(props); 
     this.state = {}; // our store will add its own state to the component's 
     this.store = StatusStore; // <- just assign the store class itself 
    } 

    render() 
    { 
     var flag = this.state.flag; // <- flag is mixed in from the StatusStore 
     return <div>User is {flag}</div> 
    } 
} 

आप एक से अधिक दुकानों में हुक करने की क्षमता है (वहाँ एक प्रोप मैं stores जो मामले में एक सरणी और क्षमता संपादित mapStoreToState साथ भाटा भी जहाजों लेता है कहा जाता है विश्वास है आप कैसे विशेष रूप से नियंत्रित करने के लिए चाहता था है भंडार घटकों के लिए राज्य के ऊपर से गुजरती।

स्वाभाविक रूप से, क्योंकि आप एक घटक का उपयोग कर रहे हैं कि के साथ, तो आप शायद उनके documentation on Reflux Component और घटकों कैसे ठीक करने के लिए इसे ध्यान में रखते

अंतिम बात मैं हूँ पढ़ना चाहिए भाटा जहाजों नोट ऊपर है मैं उल्लेख करता हूँ डी बड़ी समस्या वैश्विक स्थिति थी और यह कैसे संबोधित करता है। रेफ्लक्स में Reflux.GlobalState है जिसका योगदान तब तक किया जा सकता है जब तक आप अपने स्टोर पर आईडी सेट करते हैं। ऊपर दिया गया लिंक इसमें बहुत अधिक जानकारी देता है लेकिन इसके साथ, आप उन्हें Reflux.GlobalState.[StoreID].[property] के माध्यम से एक्सेस कर सकते हैं, जहां StoreID वह आईडी है जिसे आप स्टोर असाइन करते हैं और property वह राज्य का वास्तविक टुकड़ा है जिसे आप एक्सेस करना चाहते हैं।

Redux

Redux में और स्वयं का बहुत कुछ बदल जाता है और यह भी प्रेषकों के विचार को मारता है। इससे पहले कि मैं वास्तव में गहराई से जाऊं, मैं अपने दस्तावेज़ों में उल्लेख किए गए three principles को हाइलाइट करना चाहता हूं।

1. सच्चाई का एकल स्रोत
2. राज्य केवल पढ़ने के लिए है
3. परिवर्तन शुद्ध कार्यों

Redux में साथ किया जाता है, वहाँ वास्तव में केवल एक वैश्विक राज्य तुम्हारे साथ और कहा कि निपटने के लिए है आपके आवेदन के लिए वैश्विक स्थिति है (बड़ी समस्या को संबोधित करना)। जबकि आपके पास अभी भी कार्य और दुकान हैं, स्टोर्स स्वयं वैश्विक राज्य के पेड़ में अपने राज्य का ट्रैक रखने के लिए ज़िम्मेदार हैं, जिससे आप राज्य के पेड़ में बदलाव करने के लिए कार्यों को प्रेषित कर सकते हैं और आपको राज्य तक पहुंचने की इजाजत दे सकते हैं। आप अभी भी श्रोताओं को इन स्टोरों पर subscribe के माध्यम से डाल सकते हैं।

इसका एक बड़ा प्रेरणा पहले दो सिद्धांतों में जाता है।फ्लक्स या यहां तक ​​कि रेफ्लक्स में, यदि आप यह सुनिश्चित करना चाहते हैं कि राज्य को कुछ भी नहीं बदल रहा था, जब आप इसे नहीं चाहते थे (क्योंकि तकनीकी रूप से आप जब चाहें स्टोर में राज्य तक पहुंच सकते हैं और बदल सकते हैं), तो आप ImmutableJS जैसी चीज़ों पर निर्भर होंगे सुनिश्चित करें कि आप गलती से राज्य को म्यूट नहीं कर रहे थे। दूसरी ओर रेडक्स इसे बनाता है ताकि आप स्टोर/चयनकर्ताओं के माध्यम से केवल राज्य तक पहुंच सकें और केवल प्रेषण कार्यों (तीसरे सिद्धांत) के माध्यम से परिवर्तन कर सकें।

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

Redux के data flow लिंक मैं उपर्युक्त में के बारे में वास्तव में अच्छी तरह बात की, लेकिन वहाँ भी एक बहुत अच्छी इंफ़ोग्राफ़िक मैं

तो कोर मतभेद संलग्न है वास्तव में

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

उम्मीद है कि इससे उनके बीच मूल मतभेदों की अधिक जानकारी मिलती है।

Answer 2

फ्लक्स, रेफ्लक्स और रेडक्स (और कई अन्य समान पुस्तकालय) ट्रांसवर्सल डेटा प्रबंधन को संभालने के सभी अलग-अलग तरीके हैं।

मूल प्रतिक्रिया घटक पिता-बच्चों के रिश्तों के साथ ठीक काम करते हैं, लेकिन जब आपको ऐप के विभिन्न हिस्सों से डेटा प्रदान करना और अपडेट करना होता है जो सीधे कनेक्ट नहीं होते हैं तो यह जल्दी से गन्दा हो सकता है। ऐसे पुस्तकालय ऐसे डेटा को बनाए रखने और अद्यतन करने के लिए स्टोर और क्रियाएं (और अन्य तंत्र) प्रदान करते हैं।

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

रेडक्स एक और समाधान है, जो अब तक का सबसे लोकप्रिय बन गया है। इसका लाभ यह है कि यह अपरिवर्तनीय सामग्री के साथ घोंसला वाले स्टोर प्रदान करता है ताकि आप आसानी से पिछली/अगली सुविधा को कार्यान्वित कर सकें और ट्रांसवर्सल क्रियाएं कर सकें जो स्टोर के कई हिस्सों पर प्रभाव डालती हैं। रेडक्स के नुकसान यह है कि यह काफी वर्बोज़ है और फ्लक्स या रेफ्लक्स की तुलना में कई और अवधारणाएं हैं। समान बुनियादी कार्यों के लिए इसे और अधिक कोड की आवश्यकता होगी, और एसिंक कार्यान्वयन सबसे साफ नहीं है। यह निश्चित रूप से शक्तिशाली और स्केलेबल है। http://jamesknelson.com/which-flux-implementation-should-i-use-with-react/