नोट के रूप में: मैंने Redux (बाओबाब, भी) के लिए डॉक्स पढ़े हैं, और मैंने Googling & परीक्षण का उचित हिस्सा किया है।
यह इतनी दृढ़ता से क्यों सुझाया गया है कि Redux ऐप में केवल एक स्टोर है?
मैं एक एकल-स्टोर सेटअप बनाम बनाम कई स्टोर सेटअप के पेशेवरों / विपक्ष को समझता हूं ( इस विषय पर SO पर बहुत सारे प्रश्नोत्तर हैं )।
IMO, यह वास्तु निर्णय उनकी परियोजनाओं की जरूरतों के आधार पर ऐप डेवलपर्स के लिए है। तो Redux के लिए इतना दृढ़ता से सुझाव क्यों दिया जाता है, लगभग अनिवार्य लगने के बिंदु तक ( हालांकि कुछ भी हमें कई स्टोर बनाने से नहीं रोक रहा है )?
EDIT: एकल-स्टोर में परिवर्तित होने के बाद प्रतिक्रिया
कुछ महीनों के बाद Redux के साथ काम करने पर जो एक जटिल एसपीए पर विचार करेगा, मैं कह सकता हूं कि एकल स्टोर संरचना के साथ काम करने के लिए एक शुद्ध खुशी है।
कुछ बिंदु जो दूसरों को यह समझने में मदद कर सकते हैं कि एकल स्टोर बनाम कई स्टोर क्यों कई, कई उपयोग-मामलों में एक लूट का सवाल है:
- यह विश्वसनीय है : हम चयनकर्ताओं का उपयोग ऐप स्टेट के माध्यम से खुदाई करने और संदर्भ-प्रासंगिक जानकारी प्राप्त करने के लिए करते हैं। हम जानते हैं कि सभी आवश्यक डेटा एक ही स्टोर में हैं। यह सभी सवालों को टाल देता है क्योंकि राज्य के मुद्दे कहां हो सकते हैं।
- यह तेजी से है : हमारे स्टोर में वर्तमान में 100 रेड्यूसर हैं, यदि अधिक नहीं हैं। उस गणना में भी, केवल कुछ मुट्ठी भर किसी भी प्रेषण पर डेटा को संसाधित करता है, अन्य केवल पिछली स्थिति को वापस करते हैं। यह तर्क कि एक विशाल / जटिल स्टोर ( reducers का nbr ) धीमा है, बहुत अधिक लूट है। कम से कम हमने वहाँ से आने वाले प्रदर्शन के मुद्दों को नहीं देखा है।
- डिबगिंग फ्रेंडली : जबकि एक पूरे के रूप में रिडक्स का उपयोग करने के लिए यह सबसे ठोस तर्क है, यह एकल स्टोर बनाम मल्टीपल स्टोर के लिए भी जाता है। एप्लिकेशन बनाते समय आप इस प्रक्रिया ( प्रोग्रामर गलतियों ) में राज्य त्रुटियों के लिए बाध्य हैं , यह सामान्य है। PITA तब है जब उन त्रुटियों को डीबग करने में घंटों लग जाते हैं। एकल स्टोर ( और रिड्यूस-लॉगर ) के लिए धन्यवाद, हमने कभी भी किसी भी दिए गए राज्य के मुद्दे पर कुछ मिनटों से अधिक खर्च नहीं किया है।
कुछ संकेत
अपने Redux स्टोर के निर्माण में सच्ची चुनौती यह तय करना है कि इसे कैसे तैयार किया जाए। सबसे पहले, क्योंकि सड़क के नीचे संरचना को बदलना सिर्फ एक बड़ी पीड़ा है। दूसरे, क्योंकि यह काफी हद तक निर्धारित करता है कि आप किसी भी प्रक्रिया के लिए अपने ऐप डेटा का उपयोग कैसे कर रहे हैं, और क्वेरी कर रहे हैं। स्टोर की संरचना कैसे करें, इस पर कई सुझाव हैं। हमारे मामले में हमने निम्नलिखित को आदर्श माना:
{
apis: { // data from various services
api1: {},
api2: {},
...
},
components: {} // UI state data for each widget, component, you name it
session: {} // session-specific information
}उम्मीद है कि यह प्रतिक्रिया दूसरों की मदद करेगी।
EDIT 2 - सहायक स्टोर टूल
आप में से उन लोगों के लिए जो सोच रहे हैं कि कैसे "आसानी से" एक एकल स्टोर का प्रबंधन करें , जो जल्दी से जटिल हो सकता है। ऐसे उपकरण हैं जो आपके स्टोर के संरचनात्मक निर्भरता / तर्क को अलग करने में मदद करते हैं।
नोर्मिज़्र है जो स्कीमा के आधार पर आपके डेटा को सामान्य करता है। यह तब आपके डेटा के साथ काम करने और आपके डेटा के अन्य हिस्सों को idएक शब्दकोश की तरह लाने के लिए एक इंटरफ़ेस प्रदान करता है ।
उस समय नॉर्मिज़्रर को नहीं जानते हुए, मैंने उसी तर्ज पर कुछ बनाया। रिलेशनल-जसन एक स्कीमा लेता है, और एक टेबल-आधारित इंटरफ़ेस ( एक डेटाबेस की तरह थोड़ा ) देता है। रिलेशनल-ज्सन का लाभ यह है कि आपकी डेटा संरचना आपके डेटा के अन्य हिस्सों को गतिशील रूप से संदर्भित करती है ( अनिवार्य रूप से, आप सामान्य जेएस ऑब्जेक्ट्स की तरह, अपने डेटा को किसी भी दिशा में पार कर सकते हैं )। यह Normalizr के रूप में परिपक्व नहीं है, लेकिन मैं इसे कुछ महीनों के लिए उत्पादन में सफलतापूर्वक उपयोग कर रहा हूं।