फ़्लक्स में async त्रुटियों को कैसे संभालें?

Question

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

सभी मामले में जहां मैं आदेश अद्यतन पर सर्वर से अपवाद को संभालने के लिए है के लिए छोड़कर ठीक काम करता है (जैसे उपयोगकर्ता उत्पाद मात्रा में से एक को बदल दिया है लेकिन वहाँ स्टॉक में पर्याप्त नहीं हैं, मैं चाहता हूँ उस विशिष्ट क्रम के लिए उस विशिष्ट उत्पाद के लिए फॉर्म दिखाने वाला घटक एक इनलाइन संदेश दिखाता है, इसलिए मुझे त्रुटि संदेश को एक बहुत ही विशिष्ट घटक में वितरित करना होगा। सूची में 50 ऑर्डर हो सकते हैं और प्रत्येक ऑर्डर 4-5 घटकों से बना होता है अद्यतन को ट्रिगर कर सकते हैं, इसलिए मेरे पास लगभग 200 घटक हो सकते हैं जो संभावित रूप से ORDER_UPDATE_FAILED कार्रवाई में रूचि रख सकते हैं।

केवल दो ओ ptions मैं के बारे में सोच सकते हैं कर रहे हैं:

1. घटक API अपडेट तुल्यकालिक फोन तो यह त्रुटि प्राप्त कर सकते हैं अगर यह हुआ (अद्यतन आदेश में एक ORDER_UPDATED कार्रवाई का पेलोड के रूप में भेज दिया जायेगा और सामान्य प्रवाह के माध्यम से उसके प्रवाह रखना सुनिश्चित करें प्रवाह: प्रेषक, स्टोर, ट्रिगर अद्यतन)। लेकिन मुझे पता है कि फ्लक्स दर्शन

2. अद्यतन को असीमित रूप से अद्यतन करें और एक ORDER_UPDATE_FAILED बनाएं, और उस ऑब्जेक्ट में त्रुटि में परिवर्तन करने के लिए तर्क रखने वाले स्टोर को ऑर्डर पार्ट घटक द्वारा पहचाना जा सकता है (इसके बारे में सोचना ऑर्डर आईडी + त्रुटि आईडी)। यह डेटा के यूनिडायरेक्शनल चक्र और क्रियाओं की असीमित चक्र रखेगा लेकिन यह बहुत जटिल और बोझिल लगता है और कुछ और मुद्दों को जोड़ता है:

   ए) यदि स्टोर में त्रुटि संग्रहीत है, तो घटक को स्टोर को सूचित करना होगा जब त्रुटि अब मान्य नहीं है, जो हमेशा करने में सक्षम नहीं हो सकती है)।

   बी) यदि उपयोगकर्ता मूल्य को बदले बिना सहेजने पर क्लिक करता है और घटक "लोडिंग स्टेटस" में आता है, भले ही कॉल सफल हो, तो आदेश भी रहता है, इसलिए "लोडिंग स्थिति" से बाहर निकलने के लिए कोई पुनः प्रस्तुत नहीं किया जाता है। ।

क्या किसी को भी इस समस्या को हल करने का एक और शानदार तरीका मिला है?

Answer 1

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

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