Redux: @Connect का उपयोग किए बिना कार्यों को कैसे कॉल करें?

मुझे यकीन नहीं है कि यह एक "सही" तरीका है या नहीं, लेकिन आप संदर्भ के माध्यम से स्टोर तक पहुंच सकते हैं। उदाहरण के लिए Connector घटक देखें:
https://github.com/gaearon/react-redux/blob/master/src/components/createConnector.js

मैं तुम्हारा पीछा नहीं करता। मैं @connect का उपयोग करके स्टोर तक पूरी तरह से ठीक हूं। मैं @connect का उपयोग किए बिना एक घटक में कार्यों को बांधने / कॉल करने का एक तरीका ढूंढ रहा हूं।

dispatch फ़ंक्शन स्टोर की एक विधि है। यदि आपको अपने घटक में इसकी आवश्यकता है, लेकिन @connect का उपयोग नहीं करना चाहते हैं, तो आप स्टोर को संदर्भ के माध्यम से एक्सेस कर सकते हैं और इसकी प्रेषण विधि का उपयोग कर सकते हैं:

class MyComponent extends Compoenent {
    static contextTypes = {
        store: React.PropTypes.object.isRequired,
    }

    render() {
         const { dispatch } = this.context.store
         const actions = bindActionCreators(headerActions, dispatch)
    }
}

आपको प्रेषण मूल घटक से नीचे भेजना चाहिए, या एक्शन पहले से ही प्रेषण के लिए बाध्य होना चाहिए। मेरा मानना ​​है कि _the_ way मेरा मानना ​​है कि संदर्भ भी काम करता है, यद्यपि यह एक वर्कअराउंड है

यह समझाने के लिए धन्यवाद! मुझे ये अब मिला।

आप मैन्युअल रूप से एक प्रोप के रूप में उस घटक के लिए dispatch नीचे पारित कर सकते हैं।

मैं इस मुद्दे से थोड़ा हैरान भी हूँ।

अगर मैं सही ढंग से समझूं, तो हमें या तो dispatch का एक घटक के समूह के माध्यम से उपलब्ध होना चाहिए (उस घटक से कार्यों को भेजने में सक्षम होने के लिए) या कार्रवाई रचनाकारों को पहले से ही dispatch से बाध्य करने के लिए, एक से मूल घटक। लेकिन दोनों समाधानों के लिए एक मूल घटक की आवश्यकता होती है जो connect ed हो ताकि प्रैस अपने प्रॉप्स के माध्यम से इसे उपलब्ध करा सके।

इसलिए अंत में हम सिर्फ मूल घटक पर dispatch की हमारी निर्भरता स्थानांतरित कर रहे हैं। और आप ऐसा कैसे करेंगे अगर ऐसा कोई connect एड पैरेंट न हो?

उदाहरण के लिए, अगर हम घटकों के गहन पदानुक्रम में थे:

Provider
  Router
    AppContainer
     ...
       ...
         ...
           TheComponentThatNeedDispatch

और अगर माता-पिता में से किसी को भी Redux राज्य से कनेक्ट करने की आवश्यकता नहीं है?

connect का उपयोग करने के साइड-इफ़ेक्ट के रूप में एक घटक को उपलब्ध कराए गए प्रेषण ने हमें ऐसी स्थिति में डाल दिया है, जिसमें पूर्व-आवश्यकता है कि उसके माता-पिता का connect होना dispatch एक कार्रवाई करने में सक्षम। यह अजीब लगता है क्योंकि किसी घटक की dispatch एक कार्रवाई की क्षमता और रिडक्स राज्य से पढ़ने के लिए connect का उपयोग करने की आवश्यकता के बीच कोई संबंध नहीं होना चाहिए।

मुझे पता है कि हम अभी भी घटक संदर्भ से dispatch उपयोग कर सकते हैं ( store.dispatch माध्यम से) लेकिन चूंकि यह अनुशंसित तरीका नहीं है ...

आपने इस बारे में क्या सोचा?

धन्यवाद!

यह अजीब लगता है क्योंकि किसी कार्रवाई को भेजने के लिए एक घटक की क्षमता और रिडक्स राज्य से पढ़ने के लिए कनेक्ट का उपयोग करने की आवश्यकता के बीच कोई संबंध नहीं होना चाहिए।

क्यों अजीब है? connect को "Redux से कनेक्ट करें" के रूप में सोचें, न कि केवल "Redux राज्य के एक हिस्से से कनेक्ट करें"। तब यह समझ में आता है: dispatch या तो घटक के रूप में सक्षम होने के लिए, या इसके कुछ माता-पिता को Redux में connect() होने की आवश्यकता है।

वर्तमान रिएक्ट Redux एपीआई के साथ राज्य का चयन किए बिना Redux से कनेक्ट करना सुविधाजनक नहीं है। आपको connect(state => ({}))(MyComponent) (खाली वस्तु लौटना) जैसा कुछ लिखना होगा। यही कारण है कि हम इसके लिए वैकल्पिक एपीआई की खोज कर रहे थे जो dispatch प्रथम श्रेणी का नागरिक बनाता है और "सिर्फ dispatch " हथियाने के लिए एक एपीआई जोड़ने की योजना है।

इसका कोई मतलब भी है क्या?

कनेक्ट को "Redux से कनेक्ट करें" के रूप में सोचें, न कि केवल "Redux राज्य के एक हिस्से से कनेक्ट करें"।

पूरी तरह से समझ में आता है अब :)।

नए API का उपयोग करने के लिए इंतजार नहीं कर सकता।

बहुत बहुत धन्यवाद, Redux का उपयोग करना एक आनंद है!

यह https://github.com/gaearon/react-redux/releases/tag/v0.5.0 पर उपलब्ध है

यह बहुत अच्छा लग रहा है!

@gaearon हे डैन क्या आप मुझे नेस्टेड घटकों के साथ bindActionCreators का उपयोग करने के बारे में एक टिप दे सकते हैं:

"AddProduct" - Redux से जुड़ा है (नीचे देखें)
__ "प्रोडक्टलिस्ट"
____ "ProductView"।

मैं चाहता हूं कि ProductView डिस्पैच करने में सक्षम हो, लेकिन केवल मास्टर "उत्पाद जोड़ें" में है:

function appState(state) {
    return {...};
}

export default connect(appState)(AddProduct)

आप या तो connect() नेस्टेड घटक भी ले सकते हैं, या आप इसे प्रोप के रूप में dispatch पास कर सकते हैं।

धन्यवाद डैन, वास्तव में आपकी मदद की सराहना करते हैं। सच में प्यार भी redux!

एक और सवाल अगर मैं कर सकता हूँ:
क्या मैं सर्वर API पोस्ट रिड्यूसर के अंदर से ही अनुरोध कर सकता हूँ?
जब मैं डेटाबेस (mongodb) के लिए POST करता हूं, तो आइटम को "_id" मिलता है, जिसे मैं अपने लाल राज्य में रखना चाहता हूं। प्रेषण को POST अनुरोध के लिए कॉलबैक के रूप में रखा जाना चाहिए?

धन्यवाद

क्या मैं सर्वर API पोस्ट रिड्यूसर के अंदर से ही अनुरोध कर सकता हूँ?

निश्चित रूप से नहीं, reducers किसी भी दुष्प्रभाव से मुक्त शुद्ध कार्य होना चाहिए।

जब मैं डेटाबेस (mongodb) के लिए POST करता हूं, तो आइटम को "_id" मिलता है, जिसे मैं अपने लाल राज्य में रखना चाहता हूं। प्रेषण को POST अनुरोध के लिए कॉलबैक के रूप में रखा जाना चाहिए?

हाँ।

कृपया इस गाइड को देखें: http://rackt.github.io/redux/docs/advanced/AsyncActions.html

धन्यवाद Dan, महान काम करता है (y)

यदि im सर्वर के उपयोग के लिए वर्तमान उपयोगकर्ता को लॉग इन करने की अनुमति देता है,
क्या मैं स्टोर से async लाने को छोड़ सकता हूँ, और सर्वर पर कर सकता हूँ?

अगर im सर्वर के रेंडरिंग का उपयोग करते हुए यह कहता है कि वर्तमान उपयोगकर्ता लॉग इन कर रहा है, तो क्या मैं स्टोर से एसिंक्स लाने को छोड़ सकता हूं, और सर्वर पर कर सकता हूं?

आप सर्वर पर स्टोर बना सकते हैं, समाप्त होने के लिए async कार्रवाइयों की प्रतीक्षा कर सकते हैं और फिर रेंडर कर सकते हैं।
Http://rackt.github.io/redux/docs/recipes/ServerRendering.html भी देखें

मैं शायद कुछ महत्वपूर्ण याद कर रहा हूँ, लेकिन क्यों नहीं सभी आंशिक रूप से अनुप्रयोग प्रारंभ के दौरान सभी एक्शन-रचनाकारों पर प्रेषण? फिर आप प्रेषण के संदर्भ के बारे में चिंता किए बिना कहीं से भी कॉल कर सकते थे।

@mpoisot : क्योंकि आपको ऐप स्टार्टअप पर _every_ संभावित एक्शन क्रिएटर को जानना, आयात करना, बाँधना और वितरित करना होगा। अन्य बातों के अलावा, यह कोड विभाजन जैसी स्थितियों के साथ मदद नहीं करता है।

@markerson मुझे पहले से ही रिड्यूसर को जानना है, इसलिए मैं createStore कॉल कर सकता हूं। मैं अगली पंक्ति में bindAllActionCreators(store.dispatch) कॉल करने की कल्पना कर रहा हूं।

सच है, आप वास्तव में उपयोग की तुलना में थोड़ा अधिक कोड में खींच सकते हैं। लेकिन अगर यह चिंता है तो इसे इस तरह से मत करो। या अपने reducer- सेट (reducer + एक्शन क्रिएटर्स + चयनकर्ताओं) को छोटे, अधिक केंद्रित बंडलों में तोड़ दें। या केवल कुछ एक्शन क्रिएटर्स को बांधें।

क्या ऐसा करने के लिए कुछ भयानक प्रदर्शन जुर्माना है? या यह किसी तरह नरक कोडिंग के लिए एक भयानक रास्ता नीचे ले जाता है?

@mpoisot : वास्तव में कोई भी

प्रकाश निर्भरता इंजेक्शन दृष्टिकोण में connect परिणामों का उचित उपयोग। एक "सादे" घटक केवल यह जानता है कि इसे एक प्रोपे के रूप में कुछ फ़ंक्शन दिया जा रहा है, और इसे उस फ़ंक्शन को आवश्यकतानुसार कॉल करना चाहिए। यह वास्तव में परवाह नहीं करता है अगर यह एक कॉलबैक है जिसे सीधे कुछ मूल घटक, या पूर्व-बाध्य एक्शन निर्माता द्वारा पारित किया गया था। इसका मतलब है कि घटक को एक सीधा तरीके से पुन: उपयोग किया जा सकता है, और यह बहुत आसान परीक्षण भी करता है। दूसरी ओर, ऐसा कुछ करने से स्टोर का आयात सीधे उस विशिष्ट स्टोर इंस्टेंस और कार्यान्वयन के लिए घटक को बांधने में होता है, यही वजह है कि यह हतोत्साहित किया जाता है (प्रतिदीप्ति FAQ के अनुसार: http://redux.js.org/docs/faq/ StoreSetup.html # store-setup-multiple-stores)। अगर मैं समझता हूं कि आप सही तरीके से क्या पूछ रहे हैं, तो यह मूल रूप से स्टोर को सीधे आयात करने और संदर्भित करने के समान स्थिति है।

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

जो मुझे लगता है, निश्चित रूप से आप एक स्टोर सिंगलटन ऑब्जेक्ट बना सकते हैं, जिसके स्टोर को परीक्षण के लिए विभिन्न स्टोरों के साथ अपडेट किया जा सकता है? सीधे स्टोर को स्वयं निर्यात करने के बजाय, इसे StoreSingleton.getStore() माध्यम से लौटाएं, और StoreSingleton.setStore() माध्यम से वर्तमान स्टोर को बदलें। इसलिए परीक्षण के संदर्भ में आप किसी स्टोर के एकल उदाहरण से बंधे नहीं होंगे। हालाँकि, मैं देख सकता हूँ कि यह थ्रेडेड सर्वर वातावरण में काम क्यों नहीं करेगा।

@mpoisot आपने अभी बताया कि प्रदाता / कनेक्ट क्या करते हैं। ;)

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

लेकिन मैंने आश्चर्यचकित होने के लिए इस परिदृश्य को पर्याप्त बार मारा है। और यह प्रतीत होता है कि उत्तर "किसी दिन आप सर्वर साइड रेंडरिंग कर सकते हैं"। (मुझे सही जवाब दो अगर मैं गलत हूँ)।

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

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

मैं इसके दोनों किनारों पर रहा हूँ -

मेरे प्राथमिक अनुप्रयोग में हम स्टोर को एक सिंगलटन के रूप में मानते हैं और विश्व स्तर पर उपलब्ध getStore() फ़ंक्शन का उपयोग करते हैं। हम सर्वर-साइड रेंडरिंग का उपयोग नहीं करते हैं। हम अभी भी Provider और connect mapStateToProps ।

दूसरी ओर, मैंने एक प्रयोगात्मक एप बनाया है, जहां मैं घटक पदानुक्रम के भीतर विभिन्न स्थानों में स्टोर (जैसे @jimbolla और @markerikson का उल्लेख करता लपेटता हूं , और दोनों dispatch और getState कर सकते हैं पूरे ऐप में बदलाव करें, जिसका अर्थ है कि वे _ha__ पूरे ऐप में वायर्ड किए जाएंगे (या तो context या props ) और एकल नहीं हो सकते।

आप जो हासिल करना चाहते हैं, उसके आधार पर, मुझे लगता है कि सिंगलटन स्टोर का सामान व्यवहार्य है, लेकिन व्यक्तिगत रूप से मैं धीरे-धीरे इससे दूर जा रहा हूं।

हाँ। आप निश्चित रूप से _can_ स्टोर को एक सुलभ सिंगलटन के रूप में मानते हैं, लेकिन यह आपको सीमित करता है, यह मुहावरेदार नहीं माना जाता है, और मुझे ऐसा करने का कोई वास्तविक लाभ नहीं दिखता है।

धन्यवाद, शानदार प्रतिक्रिया। क्या कोई स्टोर-रैपिंग दिखाने वाला लिंक पोस्ट कर सकता है?

@mpoisot

यहाँ दान की टिप्पणियों में से एक है जो दिखाता है कि कैसे dispatch लपेटना उपयोगी हो सकता है:

https://github.com/reactjs/redux/issues/822#issuecomment -145271384

प्रेरणा क्या है, इसे बेहतर ढंग से समझने के लिए आपको पूरे सूत्र को पढ़ना पड़ सकता है।

विशेष रूप से, ध्यान दें कि कैसे dispatch लिपटा है (मैंने इसे हाइलाइट किया है):

इस पुराने पोस्ट को हाईजैक करने के लिए क्षमा करें क्योंकि इसी तरह के भ्रम का सामना करना पड़ रहा है, बिना कनेक्ट किए कार्रवाई को भेजने की इच्छा है।

export default class App extends Component {
...
  componentDidMount() {
    //registering event listener
    BackgroundGeolocation.on('location', this.onLocation, this.onError);
  }

  onLocation(location) {
   //wishing to dispatch an action to update variable in store
  }

  render() {
    return (
      <Provider store={store}>
        <AlertProvider>
          <MainNavigator screenProps={{ isConnected: this.state.isConnected }} />
        </AlertProvider>
      </Provider>
    );
  }
}

जैसा कि मैं समझता हूं, मैं संभवतः इस घटक में स्टोर करने के लिए कनेक्ट नहीं कर सकता हूं क्योंकि हम अभी कॉन्फ़िगर कर रहे हैं और स्टोर को Provider में पास कर रहे हैं। मैं अपने onLocation घटना में संभवतः एक प्रेषण कैसे करूंगा?

@ आइस्कैलम : ठीक है, उस विशिष्ट मामले में, आप _do_ में स्टोर का संदर्भ है, इसलिए आप सीधे store.dispatch(someAction) कॉल कर सकते हैं।

अन्य विकल्प आपके घटक संरचना का पुनर्गठन करना होगा ताकि कुछ घटक _inside_ <Provider> पृष्ठभूमि जियोलोकेशन व्यवहार करता है, और इसे कनेक्ट भी किया जा सकता है।