इस प्रवाह क्रिया और इस फ़ंक्शन कॉल के बीच क्या अंतर है?

Question

मैं एक इस तरह एक प्रवाह कार्रवाई हो सकता है:

{type: 'KILL', payload: {target: 'ogre'}} 

लेकिन मैं नहीं दिखाई दे रहा क्या फर्क एक वर्ग के लोग (दुकान लपेटकर) इस तरह पर एक विधि के बीच है,

People.kill('ogre') 

अगर लोग कार्रवाई का एकमात्र रिसीवर हैं?

मुझे लगता है कि प्रवाह डिस्पैचर देता है मुझे दो फायदे (संभवतः)

1. "मारने" विधि कई अज्ञात रिसीवर को प्रसारित किया जा सकता (अच्छा!)
2. डिस्पैचर मेरे लिए एक सुविधाजनक स्थान देता है सभी एक्शन ट्रैफिक लॉग करें (भी अच्छा!)

ये अच्छी चीजें सुनिश्चित हो सकती हैं, लेकिन क्या कोई अन्य कारण है जो मुझे याद आ रही है?

जो मुझे नहीं दिखाई देता है वह है कि JSON ऑब्जेक्ट्स के रूप में क्रियाओं को कैसे डाला जाता है, अचानक "1-तरफा" संचार प्रवाह के साथ लागू होता है या मदद करता है, जो कि मैंने हर जगह पढ़ा है, वह कार्य करने का बड़ा लाभ है, और प्रवाह का

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

मुझे क्या याद आ रहा है?

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

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

Answer 1

प्रवाह शैली की वास्तुकला की प्रमुख विशेषताएं मोटे तौर पर निम्नलिखित हैं:

1. दुकान आवेदन राज्य के लिए सच्चाई का एकल स्रोत है
2. केवल कार्यों की दुकान के राज्य
3. के उत्परिवर्तन ट्रिगर कर सकते हैं स्टोर स्थिति को ऑब्जेक्ट वैल्यू असाइन करने के माध्यम से, यानी क्लोनिंग/विनाशकारी के माध्यम से नई वस्तुओं को बनाकर,

आहार की तरह, वें का उपयोग करके आर्किटेक्चर का प्रकार वास्तव में काम नहीं करता है अगर आप पर्ची करते हैं और पुराने तरीके से वापस जाते हैं।

आपके उदाहरण पर लौटें। यहां कार्रवाई का उपयोग करने का लाभ पहलुओं को प्रसारित या लॉगिंग नहीं कर रहा है, लेकिन केवल यह तथ्य कि People कक्षा केवल स्टोर से डेटा उपभोग करने में सक्षम होनी चाहिए और कार्यों के साथ कहा गया स्टोर की स्थिति को बदलने के लिए अपनी इच्छाओं को व्यक्त करना चाहिए।उदाहरण के लिए कल्पना करें कि Elves ओग्रे में गाना चाहते हैं और इस प्रकार यह जानने में रुचि है कि कहा गया ओग्रे अभी भी जीवित है। उसी समय People विनम्र होना चाहते हैं और इसे अपरिवर्तित होने पर ogre को मारना नहीं चाहते हैं। प्रवाह शैली की वास्तुकला के लाभ स्पष्ट कर रहे हैं: वर्ग People दुकान रैप करने के लिए थे

class People { 
    kill(creature) { 
    if (creatureStore.getSerenadedCreature() !== creature) 
     store.dispatch({ type: 'KILL', payload: { target: creature } }) 
    return `The ${creature} is being serenaded by those damn elves, let's wait until they've finished.` 
    } 
} 

class Elves { 
    singTo(creature) { 
    if (!creatureStore.getCreatures().includes(creature)) 
     return store.dispatch({ type: 'SING_TO', payload: { target: creature } }) 
    return `Oh no, the ${creature} has been killed... I guess there will be no serenading tonight..` 
    } 
} 

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

प्रवाह शैली की वास्तुकला के साथ, उन सभी वर्गों केवल creatureStore और प्रेषण कार्रवाई है कि राज्य के आधार पर से डेटा की खपत होगी। दुकान राज्य के साथ विभिन्न कार्यों को सुलझाने में संभालती है ताकि उसके सभी ग्राहकों के पास सही समय पर सही डेटा हो।

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

आशा इस दीवार-ओ-पाठ को स्पष्ट करने में मदद की!

Answer 2

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

फेसबुक फ्लक्स ने ईवेंट संचालित जीयूआई सिस्टम से विचार लिया। यहां तक ​​कि यदि आप अपना माउस ले जाते हैं तो आपको संदेश मिलते हैं। इसे तब संदेश लूप कहा जाता था, और अब हमारे पास कार्य प्रेषण है।

इसके अलावा, हम दुकानों के अंदर ग्राहकों की सूची है।

और यह वास्तव में रेडक्स में एक ही सिद्धांत है जहां आपके पास एक स्टोर है, जबकि फ्लक्स में आपके पास कई स्टोर हो सकते हैं।

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

सिर्फ तीन घटकों के साथ हम भी बहुत कुछ संभव चेन की है।

और यहां तक ​​कि अधिक घटकों यह जटिल हो जाता है के साथ।तो संभव घटकों की अंतःक्रियात्मकता की घातीय जटिलता को दबाने के लिए हमारे पास यह फ्लक्स पैटर्न है जो IDispatch, IObservable से अधिक कुछ भी नहीं है यदि आपने कुछ अन्य प्रोग्रामिंग भाषाओं से इन इंटरफेस के साथ काम किया है। एक कार्य को थूकने के लिए होगा, और दूसरा दुकान के अंदर मौजूद श्रोता की श्रृंखला में प्रवेश करने के लिए होगा।

इस पैटर्न के साथ, आपका प्रतिक्रिया कोड सामान्य प्रतिक्रिया दृष्टिकोण से अलग तरीके से व्यवस्थित किया जाएगा। आपको अब React.Component राज्य का उपयोग नहीं करना पड़ेगा। इसके बजाए, आप स्टोर (ओं) का उपयोग करेंगे जो एप्लिकेशन स्थिति रखेंगे।

आपका घटक केवल क्रिया को प्रेषित करके आवेदन स्थिति को बदलने की इच्छा दिखा सकता है। उदाहरण के लिए: onClick काउंटर बढ़ाने के लिए कार्रवाई भेज सकता है। क्रियाएं type: की संपत्ति होती हैं जो आम तौर पर एक स्ट्रिंग होती है, और आमतौर पर ऊपरी मामले में होती है, लेकिन एक्शन ऑब्जेक्ट में कई अन्य प्रोप जैसे आईडी, वैल्यू, ...

चूंकि घटक प्रतिपादन के लिए ज़िम्मेदार हैं आवेदन स्थिति पर हमें उन्हें आवेदन स्थिति देने के लिए किसी भी तरह की आवश्यकता है। यह props = store.getState() के माध्यम से हो सकता है या हम context का उपयोग कर सकते हैं। लेकिन this भी देखें।

अंत में, यह भी वर्जित नहीं है कि घटक आंतरिक स्थिति (this.state) का उपयोग करता है यदि इसका आवेदन पर कोई प्रभाव नहीं पड़ता है। आपको इन मामलों को पहचानना चाहिए।