2015-12-10 19 views
5

मैं समझता हूँ कि मैं एक emit.change() डिस्पैचर की जरूरत है, सभी घटकों को पता है कि कुछ दुकान के अंदर बदल दिया था। लेकिन मैं समझता हूँ कि क्यों मैं सीधे कार्रवाई अंदर से दुकानों बुला के बजाय कार्यों प्रेषण करने की आवश्यकता नहीं है,प्रतिक्रिया/प्रवाह - मुझे एक एक्शन-प्रेषक की आवश्यकता क्यों है?

.i.e। इस के बजाय

var Dispatcher = require('dispatcher'); 
var MyActions = { 
    addItem: function(item){ 
     Dispatcher.dispatch({ 
       action: 'ADD_ITEM', 
       payload: item  
     }) 
    } 
} 

: मैं ऐसा क्यों करना चाहिए

var MyStore = require('mystore'); 
var MyActions = { 
    addItem: function(item){ 
     MyStore.addItem(item); 
    } 
} 

उस मामले कि कई दुकानों में एक ही घटना को सुनने, उदाहरण के लिए के लिए जब StoreA और StoreB रूप में अच्छी तरह ADD_ITEM को सुनने है?

उत्तर

9

डिस्पैचर आग कार्रवाई एक के बाद एक, जब वे कहा जाता है।

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

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

  3. दृष्टिकोण के इस प्रकार के साथ

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

+0

महान उत्तर के लिए धन्यवाद! मेरे पास उससे एक और सवाल है, यही कारण है कि मैं यहां पहली बार इस प्रश्न पर आया था। मुझे एक क्रिया से एक मूल्य (एक नव निर्मित आइटम की आईडी) वापस करने की आवश्यकता है और इसे अगली कार्रवाई में भेज दें। क्या मुझे दूसरी कार्रवाई के बाद कई कार्यों को प्रेषित करने के बजाय स्टोर के भीतर से आईडी सहित अगली कार्रवाई भेजनी चाहिए? दूसरा सवाल है [यहां] (http://stackoverflow.com/questions/33987477/react-flux-return-value-from-flux-dispatcher-store) –

+0

करने के लिए सबसे अच्छी बात एक ही कार्रवाई का उपयोग करना होगा और इसके लिए दोनों दुकानों पर सुनो, और तदनुसार परिवर्तन करें। दरअसल, ऐसा करने का हमेशा एक तरीका होता है। आपको बस थोड़ा सा कोड बदलना होगा। आप इस {data_for_store1: {...}, data_for_store2: {...}, क्रिया: 'ADD_ITEM'} के साथ प्रेषित करते हैं और दोनों स्टोर अब एक ही क्रिया का उपयोग कर सकते हैं। क्या यह मदद करता है? –

+0

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

संबंधित मुद्दे